Chainlink: شبكة أوراكل اللامركزية
摘要
在本白皮书中，我们阐述了 Chainlink 的演变愿景，超越了原始 Chainlink 白皮书中的最初构想。 我们预见 oracle 网络的作用日益扩大，通过提供快速、可靠和可靠的服务来补充和增强现有和新的 blockchain 保密性通用连接和链外计算 smart contracts。 我们计划的基础是我们所说的去中心化预言机网络，或者 简称 DONs。 DON 是由 Chainlink 委员会维护的网络 节点。 它支持任何无限范围的 oracle 函数选择 由委员会部署。因此 DON 充当强大的抽象层， 为 smart contract 提供广泛的链下资源和高度的接口 DON 本身内高效且去中心化的链外计算资源。 以 DONs 作为跳板，Chainlink 计划重点关注七个方面的进展 关键领域： • 混合smart contracts：提供一个强大的通用框架，通过安全地在链上组合来增强现有的smart contract功能 和链下计算资源进入我们所说的混合smart contract。 • 抽象化复杂性：向开发人员和用户提供简单的 功能消除了熟悉复杂底层的需要 协议和系统边界。 • 扩展：确保oracle 服务实现延迟和吞吐量 高性能去中心化系统的需求。 • 保密性：支持结合blockchains’的下一代系统 与生俱来的透明度，为敏感信息提供强大的新保密保护 数据。 • 交易的顺序公平性：以多种方式支持交易排序 这对最终用户来说是公平的，并防止抢先交易和其他攻击 机器人和剥削性矿工。 • 信任最小化：创建高度值得信赖的支持层 smart contracts 和其他 oracle 依赖系统，通过去中心化、强锚定于高安全性 blockchains、加密 技术和加密经济保证。 • 基于激励的（加密经济）安全性：严格设计和稳健部署机制，确保 DON 中的节点具有强大的经济激励，即使面对资源充足的对手，也能可靠、正确地行事。 我们展示 Chainlink 社区的初步和持续创新 在每个领域，提供了一幅不断扩大和日益增长的图景 为 Chainlink 网络规划的强大功能。
خلاصة
في هذا المستند التقني، نوضح رؤية لتطور Chainlink بما يتجاوز تصوره الأولي في المستند التقني Chainlink الأصلي. نحن نتوقع دور متزايد التوسع لشبكات oracle، وهو الدور الذي تكمل فيه وتعزز شبكات blockchain الحالية والجديدة من خلال توفير خدمات سريعة وموثوقة ومفيدة السرية - الحفاظ على الاتصال العالمي والحساب خارج السلسلة لـ smart contracts. أساس خطتنا هو ما نسميه شبكات أوراكل اللامركزية، أو DONs للاختصار. DON هي شبكة تتم صيانتها بواسطة لجنة مكونة من Chainlink العقد. وهو يدعم أي نطاق غير محدود من وظائف oracle المختارة النشر من قبل اللجنة. وبالتالي فإن DON بمثابة طبقة تجريد قوية، تقديم واجهات لـ smart contracts لموارد واسعة النطاق خارج السلسلة وبدرجة عالية موارد حوسبة فعالة وغير مركزية خارج السلسلة داخل DON نفسها. باستخدام DONs كنقطة انطلاق، تخطط Chainlink للتركيز على التقدم في سبعة المجالات الرئيسية: • smart contracts المختلط: تقديم إطار عام قوي لزيادة إمكانات smart contract الحالية من خلال الإنشاء الآمن على السلسلة وموارد الحوسبة خارج السلسلة إلى ما نسميه smart contracts الهجين. • التخلص من التعقيد: تقديم معلومات بسيطة للمطورين والمستخدمين تلغي الوظيفة الحاجة إلى الإلمام بالأساسيات المعقدة البروتوكولات وحدود النظام. • القياس: التأكد من أن خدمات oracle تحقق زمن الاستجابة والإنتاجية التي تتطلبها الأنظمة اللامركزية عالية الأداء. • السرية: تمكين أنظمة الجيل التالي التي تجمع بين blockchains' الشفافية الفطرية مع حماية قوية جديدة لسرية الأشخاص الحساسين data. • عدالة ترتيب المعاملات: دعم تسلسل المعاملات بطرق مختلفة التي تكون عادلة للمستخدمين النهائيين وتمنع الهجمات الأمامية والهجمات الأخرى الروبوتات وعمال المناجم الاستغلاليين. • تقليل الثقة: إنشاء طبقة دعم جديرة بالثقة للغاية smart contracts والأنظمة الأخرى التي تعتمد على oracle عن طريق اللامركزية، والتثبيت القوي في blockchains عالية الأمان، والتشفير التقنيات والضمانات الاقتصادية المشفرة. • الأمن القائم على الحوافز (الاقتصاد المشفر): التصميم الصارم والنشر القوي للآليات التي تضمن أن العقد في DON لديها حوافز اقتصادية قوية للتصرف بشكل موثوق وصحيح، حتى في مواجهة الخصوم ذوي الموارد الجيدة. نقدم ابتكارات أولية ومستمرة من قبل مجتمع Chainlink في كل من هذه المجالات، مما يوفر صورة للتوسع وبشكل متزايد الإمكانات القوية المخطط لها لشبكة Chainlink.
介绍
如今，区块链 oracle 通常被视为具有一个目标的去中心化服务： 将数据从链下资源转发到 blockchains。虽然这只是一小步， 从转发数据到计算、存储或双向传输。这一观察结果证实了 oracles 功能的更广泛概念。也是如此 满足 smart contract 不断增长的服务需求并且日益多元化 依赖 oracle 网络的技术。简而言之，oracle 可以而且需要 成为链上和链下系统之间的通用、双向、支持计算的接口。预言机在 blockchain 生态系统中的作用是增强 smart contract 的性能、功能和互操作性，以便它们能够 为多个行业带来新的信任模式和透明度。这种转变将通过扩大混合 smart contract 的使用来实现，它融合了 blockchains 的特殊属性以及链下系统的独特功能，例如 oracle 网络，从而实现比链上系统更大的覆盖范围和能力 处于孤立状态。 在本白皮书中，我们阐述了 Chainlink 2.0 的愿景，这是 Chainlink 的演变，超越了原始 Chainlink 白皮书 [98] 中的最初构想。我们预见 oracle 网络的作用将日益扩大，其中 它们通过为混合动力提供快速、可靠且保密的通用连接和计算来补充和增强现有和新的 blockchain smart contracts。我们相信 oracle 网络甚至会发展成为公用事业 用于将高完整性 blockchain 级数据导出到 blockchain 之外的系统 生态系统。 如今，由不同实体集运行的 Chainlink 节点聚集在 oracle 网络中，将数据转发到 smart contract，即所谓的报告。我们可以查看这样的 oracle 节点作为类似于经典共识 blockchain [72] 中的委员会， 但目标是支持现有的 blockchain，而不是提供独立的功能。具有可验证的随机函数（VRF）和链外报告 (OCR)，Chainlink 已经向通用框架和基础设施发展，以提供 smart contracts 所需的计算资源 先进的功能。 我们的 Chainlink 2.0 计划的基础是我们所说的去中心化预言机 网络，简称 DONs。由于我们在 中引入了术语“oracle 网络” 原始 Chainlink 白皮书 [98]、oracle 开发了更丰富的功能和 应用范围。在本文中，我们根据 我们对 Chainlink 生态系统的未来愿景。在此视图中，DON 是一个网络 由 Chainlink 节点委员会维护。植根于共识协议，它 支持任何无限范围的 oracle 选择用于部署的功能 委员会。因此，DON 充当 blockchain 抽象层，提供接口 smart contract 和其他系统的链外资源。它还提供 访问高效且去中心化的链下计算资源。一般来说， a DON 支持主链上的操作。其目标是实现安全和灵活ble Hybrid smart contracts，将链上和链外计算与 与外部资源的连接。 我们强调，即使在 DONs 中使用委员会，Chainlink 本身 本质上仍然是未经许可的。 DONs 充当无需许可的基础 框架，其中节点可以聚集在一起实现自定义 oracle 网络 他们自己的节点包含制度，可能是经过许可的，也可能是未经许可的。 以 DONs 为基础，我们计划在 Chainlink 2.0 中重点关注七个方面的进展 关键领域：混合 smart contracts、抽象复杂性、扩展性、保密性、交易秩序公平性、信任最小化和基于激励的（加密经济）安全性。在本文的介绍中，我们概述了去中心化 第 1.1 节介绍了 Oracle 网络，然后第 1.2 节介绍了我们的七个关键创新领域。我们在 1.3 节中描述了本文其余部分的组织。 1.1 去中心化预言机网络 去中心化预言机网络旨在增强和扩展功能 目标 blockchain 或主链上的 smart contract 通过以下函数 本地不可用。他们通过提供以下三种基本资源来做到这一点： 计算系统：网络、存储和计算。 DON 旨在提供 这些资源具有很强的保密性、完整性和可用性，1 以及问责制。 DON 由 oracle 节点组成的委员会组成，这些节点合作完成特定的任务 工作或选择建立长期关系以提供持久的服务 给客户。 DON 以与 blockchain 无关的方式设计。他们承诺将作为 一个强大而灵活的工具，供应用程序开发人员创建链下支持 他们在任何受支持的主链上的 smart contract。 有两种类型的功能实现 DON 的功能：可执行文件和 适配器。可执行文件是在 DON 上以分散方式连续运行的程序。虽然它们不直接存储主链资产，但它们具有重要的好处，包括高性能和执行机密的能力 计算。可执行文件在 DON 上自主运行并执行确定性 操作。它们与将 DON 连接到外部资源的适配器协同工作 并且可以由可执行文件调用。正如我们为 DON 设想的那样，适配器是一个 今天 Chainlink 中外部适配器的通用化。虽然现有适配器 通常仅从数据源获取数据，适配器可以双向操作；在 DONs，它们还可以利用 DON 节点的联合计算来实现 附加功能，例如加密报告以保护隐私 一个可执行文件。 为了让您了解 DON 的基本操作，图 1 从概念上展示了 DON 是如何 DON 可用于将报告发送到 blockchain，从而实现传统的现有 oracle 功能。然而，DONs 可以提供许多附加功能 1信息安全的“中央情报局三合会”[123，第 14 页] 26，第 2.3.5 节]。Chainlink 的现有网络。例如，在图1的总体结构中， 可执行文件可以在 DON 上记录获取的资产价格数据，使用这些数据 计算例如其报告的追踪平均值。 图 1：概念图，以示例显示去中心化预言机网络如何实现基本的 oracle 功能，即将链外数据中继到合约。安 可执行文件使用适配器来获取链外数据，并对其进行计算，发送输出 通过另一个适配器连接到目标 blockchain。 （适配器由以下代码启动 DON，用小蓝框表示；箭头表示数据流的方向 特定示例。）可执行文件还可以读取和写入本地 DON 用于保持状态和/或与其他可执行文件通信的存储。 DONs 中灵活的网络、计算和存储，全部都在这里展示，使许多新颖的 应用程序。 DON 的一个主要好处是它们能够引导新的 blockchain 服务。 DONs 是现有oracle网络可以快速建立服务应用程序的工具 今天，这需要创建专门的网络。我们给出了一些 第 4 节中此类应用的示例。 在第 3 节中，我们提供了有关 DON 的更多详细信息，描述了它们的功能 他们向开发人员和用户呈现的界面术语。 1.2 七个关键设计目标 在这里，我们简要回顾一下上面列举的七个关键点： Chainlink，即：混合 smart contracts： 我们 Chainlink 愿景的核心是安全的理念 在 smart contracts 中组合链上和链下组件。我们参考合同 通过混合 smart contract 或混合合约来实现这一想法。2 区块链现在并将继续在去中心化服务中发挥两个关键作用 生态系统：它们都是代表加密货币所有权的场所 以及去中心化服务的强大锚点。因此，智能合约必须在链上表示或执行，但其链上功能受到严重限制。纯粹地 链上合约代码缓慢、昂贵且孤立，无法从现实世界中受益 数据和各种在链上本质上无法实现的功能，包括各种形式的机密计算、（伪）随机性安全的生成 反对矿工/validator操纵等。 因此，为了让smart contracts充分发挥其潜力，需要smart contracts 由两部分组成：链上部分（我们通常用 SC 表示） 以及链下部分，即在 DON 上运行的可执行文件（我们通常用 执行）。目标是实现链上功能的安全组合 DONs 旨在提供多种链下服务。两部分放在一起 制定混合合同。我们在图 2 中概念性地提出了这个想法。今天， Chainlink 服务3（例如数据馈送和 VRF）正在实现原本无法实现的目标 smart contract 应用程序，范围从 DeFi 到公平生成的 NFT 到去中心化保险，作为迈向更通用框架的第一步。作为 Chainlink 服务 根据我们在本白皮书中的愿景，扩大并提高绩效，也是如此 smart contract 系统在所有 blockchain 上的能力。 我们在本白皮书中的其他六个重点可能被视为服务中的行为 第一个是混合合同的总体内容。这些焦点涉及消除可见的 混合合约的复杂性，创建额外的链下服务，使 构建能力更强的混合合约，并且在信任最小化的情况下，增强混合合约所实现的安全属性。我们留下想法 混合合约隐含在本文的大部分内容中，但任何组合 具有 DON 的主链逻辑可以被视为混合合约。 抽象掉复杂性： DONs 旨在利用去中心化的 通过抽象出通常复杂的机制，为开发人员和用户提供方便的系统 DONs 强大而灵活的一系列服务的背后。 现有 Chainlink 服务 已经有这个功能了。 例如，Chainlink 中的数据馈送现在提供了链上接口，这些接口不需要开发人员关心协议级别的细节，例如 OCR 强制执行共识报告的方式。 2链上/链下合约组合的想法之前已经在各种受限环境中出现过 形式，例如，第 2 层系统、基于 TEE 的 blockchains [80] 等。我们的目标是支持和泛化 这些方法并确保它们可以包含链外数据访问和其他关键 oracle 服务。 3Chainlink 服务包括各种可通过以下方式获得的去中心化服务和功能： 网络。它们由组成各种 oracle 网络的众多节点运营商提供 整个生态系统。图 2：描述链上/链下合约构成的概念图。一个 混合 smart contract 3⃝由两个互补的组件组成：一个链上组件 组件 SC 1⃝，驻留在 blockchain 上，以及链外组件 exec 2⃝ 在 DON 上执行。 DON 也充当两个组件之间的桥梁 将混合合约与链下资源（例如网络服务、其他资源）连接起来 blockchains、去中心化存储等 分散的节点集。 DONs 更进一步，因为它们扩展了 Chainlink 可以为开发人员提供抽象层的一系列服务 伴随高级服务的简化界面。 我们在第 4 节中介绍了几个应用示例来强调这种方法。 例如，我们设想企业使用 DONs 作为一种安全中间件形式 将他们的旧系统连接到 blockchains。 （参见第 4.2 节。）DON 的这种使用抽象了一般 blockchain 动态的复杂性（费用、重组等）。它还 抽象出特定 blockchain 的功能，从而使企业能够将其现有系统连接到不断扩大的 blockchain 系统，而无需 需要这些系统或更广泛的分散系统开发方面的专业知识。 最终，我们的目标是推动 Chainlink 实现的抽象程度 到了实现我们所说的去中心化元层的程度。这样的一层 将为所有类别的开发人员抽象出链上/链下的区别 和 DApp 的用户，允许无缝创建和使用去中心化服务。为了简化开发过程，开发人员可以将元层中的 DApp 功能指定为统一机器模型中的虚拟应用程序。他们可以 然后使用去中心化元层编译器自动将 DApp 实例化为 一组互操作的分散功能，涵盖 blockchains、DONs 和 外部服务。 （这些外部服务之一可以是企业系统，使得元层对于涉及遗留企业系统的应用程序非常有用。） 编译类似于现代编译器和软件开发工具包 (SDK) 支持通才程序员充分发挥异构硬件的潜力 由通用 CPU 和 GPU 等专用硬件组成的架构， 机器学习加速器或可信飞地。图 3 在概念层面上展示了这一想法。 混合 smart contract 是实现这一愿景和我们称为元合约的概念的第一步。元合约是在去中心化平台上编码的应用程序 元层并隐式包含链上逻辑 (smart contracts)，以及各种 blockchains 和现有链下之间的链下计算和连接 服务。考虑到对语言和编译器支持、新安全模型的需求，以及 然而，不同技术的概念和技术协调 真正的去中心化元层是一个雄心勃勃的目标，我们长期以来一直渴望实现这一目标 时间范围。尽管如此，它仍然是一个在阅读时牢记的有用的理想模型 这篇论文，这里没有详细介绍，但我们计划在未来的工作中重点关注 Chainlink。 缩放比例： 在我们不断发展的设计中，一个极其重要的目标是使 Chainlink 网络，以满足 blockchain 生态系统不断增长的扩展需求。 随着网络拥塞成为现有无许可环境中反复出现的问题 blockchains [86]，新的、性能更高的 blockchain 设计正在投入使用， 例如，[103,120,203]，以及补充的第 2 层扩展技术，例如[5， 12、121、141、169、186、187]。 Oracle 服务必须实现延迟和吞吐量 满足这些系统的性能需求，同时最大限度地减少链上费用 （例如，天然气成本）对于合同运营商和普通用户来说都是如此。与 DONs、Chainlink 功能旨在更进一步，为纯粹基于网络的系统提供足够高的性能。 DONs 的大部分性能提升来自于使用快速、基于委员会或无需许可的共识协议，并将其与 blockchains 相结合 他们支持。我们期望许多具有不同配置的 DON 并行运行；不同的 DApp 和用户可以在底层共识选择中进行权衡 根据他们的应用要求。 DONs 实际上可以被视为第 2 层技术。 我们期望其中 其他服务，DONs 将支持事务执行框架 (TEF)，该框架 促进 DONs 以及 oracles 与其他高性能的有效集成 第 2 层系统——例如 rollups，将链下交易捆绑在一起以实现 性能改进。我们在第 6 节中介绍了 TEF。
图 3：概念图显示了去中心化元层的理想实现。对于 为了便于开发，开发人员指定一个 DApp（以粉色突出显示）作为虚拟的 统一机器模型中的应用。去中心化元层编译器自动生成相应的互操作功能：smart contracts（表示为 由 SC 表示）、DON 上的逻辑（由 exec 表示）、连接到目标外部服务的适配器等等，如黄色突出显示所示。 图 4 从概念上展示了 DONs 如何改进 blockchain (smart contract) 缩放 通过集中交易和oracle-报告处理在链外，而不是在链上 链。计算主要位置的这种转变减少了交易延迟并 费用，同时提高交易吞吐量。 保密性： 区块链为 smart contract 及其实现的应用程序提供了前所未有的透明度。但透明度和保密性之间存在着基本的紧张关系。例如，今天，用户的去中心化交易所交易图 4：概念图显示去中心化预言机网络如何改进 blockchain 启用的 smart contracts 的缩放。图A ⃝显示传统的oracle 架构。交易直接发送至 blockchain，oracle 报告也是如此。 因此，以黄色突出显示的 blockchain 是事务处理的主要位置。图 B⃝显示了使用 DON 来支持 blockchain 上的合约。 DON 可执行文件处理交易以及来自外部系统的数据并转发 结果（例如，由于交易影响而导致的捆绑交易或合约状态更改）发送至 blockchain。因此，以黄色突出显示的 DON 是主要的 交易处理的场所。 行为记录在链上，方便监控交易所行为，同时也 使用户的金融交易公开可见。同样，数据转发到智能 合约仍然在链上。这使得此类数据可以方便地进行审计，但充当 对于希望向 smart contracts 提供敏感或敏感信息的数据提供商来说，这是一种抑制因素 专有数据。 我们相信 oracle 网络将在催化下一代方面发挥关键作用 将 blockchains 固有的透明度与新的保密保护相结合的系统。在本文中，我们展示了他们如何使用三种主要方法来做到这一点： • 保密适配器：计划部署的两种技术 在 Chainlink 的网络中，DECO [234] 和 Town Crier [233]，启用 oracle 节点 以保护用户隐私和数据的方式从链下系统检索数据 保密性。它们将在 DON 的适配器设计中发挥关键作用。 （有关这两种技术的详细信息，请参见第 3.6.2 节。） • 机密计算：DONs 可以简单地向依赖blockchains 隐藏其计算。使用安全的多方计算和/或可信执行环境，还可以实现更强的保密性，其中 DON 节点 对他们本身不可见的数据进行计算。
• 支持机密第 2 层系统：TEF 旨在支持各种第 2 层系统，其中许多系统使用零知识证明来提供 各种形式的交易保密性。 我们在第 3 节中讨论这些方法（更多详细信息请参见第 6 节、附录 B.1 和附录 B.2）。 图 5 展示了敏感数据如何通过保密适配器从外部源流向 smart contract 的概念视图 DON 中的机密计算。 图 5：DON 上的保密操作的概念图 敏感数据（以黄色突出显示）。 网络中的敏感源数据（黑圈） 使用保密适配器（蓝色双箭头线）将服务器提取到 DON。 DON 从这些适配器接收派生数据（空心圆圈）— 将函数或秘密共享等应用到敏感源的结果 数据。 DON 上的可执行文件可以对派生数据应用机密计算 构建报告（双圆圈），通过适配器将其发送到 blockchain。 我们相信，处理机密数据的强大工具将打开一个完整的领域。 应用范围。 其中包括私人去中心化（和中心化）金融、去中心化身份、基于信用的链上借贷以及更高效、更高效的金融服务。 用户友好的了解你的客户和认证协议，正如我们在第 4 节中讨论的那样。 交易的顺序公平性： 今天的 blockchain 设计有点肮脏 公开的秘密：它们是暂时集中的。矿工和 validators 可以订购交易无论他们选择什么行动。用户也可以操纵交易顺序 他们支付的网络费用的函数（例如 Ethereum 中的汽油价格）以及某些 利用快速网络连接的优势。这种操纵可以，对于 例如，采取抢先交易的形式，其中战略参与者（例如矿工） 观察用户的交易并将其自己的可利用交易插入到较早的交易中 在同一个区块中的位置——利用对用户交易的预先了解，有效地从用户那里窃取资金。例如，机器人可能会下买单 在用户之前。然后，它可以利用由资产价格上涨引起的资产价格上涨。 用户的交易。 一些机器人抢先交易，损害普通用户——类似于高频 华尔街交易已经很普遍并且有据可查 [90]，如相关 诸如后台运行 [159] 和自动交易模仿 [195] 等攻击。最近甚至出现了将矿工的订单利用系统化的提议[110]。 rollups 等第 2 层技术并不能解决问题，而只是重新集中化 排序，将其置于创建 rollup 的实体手中。 我们的目标之一是向 Chainlink 引入一项名为“公平排序”的服务 服务 (FSS) [137]。 FSS 帮助 smart contract 设计师确保其产品的公平订购 避免对用户交易以及其他类型的交易（例如 oracle 报告传输）进行前置、后台和相关攻击。 FSS 使 DON 能够实现 [144] 中引入的严格的、暂时的秩序公平概念等想法。作为一个附带的好处，FSS 还可以降低用户的网络 费用（例如燃气费）。 简而言之，在 FSS 中，交易通过 DON，而不是直接传播到目标 smart contract。 DON 对交易进行排序，然后转发 他们签订合同。 图 6：FSS 如何发挥作用的示例。图A ⃝展示了矿工如何利用其 集中权力来排序交易，可以交换一对交易：交易1⃝ 在 2⃝ 之前到达，但矿工将其排序在 2⃝ 之后。相比之下，图B⃝显示 DON 如何在 DON 节点之间分散排序过程。如果法定人数为 诚实节点在 2⃝ 之前收到 1⃝，FSS 导致 1⃝ 在链上出现在 2⃝ 之前 — 通过附加合同可执行的序列号来防止矿工重新排序。 图 6 比较了标准挖矿与 FSS。它展示了如何在标准挖矿中，交易排序过程由矿工集中处理，因此受制于 操纵，例如对一对交易的到达进行重新排序 次。相比之下，在 FSS 中，该过程分散在 DON 节点之间。假设 诚实节点的法定数量，FSS 有助于执行策略，例如时间排序 交易，减少矿工和其他实体操纵的机会。 此外，由于用户无需根据Gas价格来争夺优先订购权， 他们可以支付相对较低的汽油价格（而来自 DON 的交易可以批量进行 以节省燃气）。 信任最小化： 我们设计 DONs 的总体目标是促进高度 对 smart contract 和其他 oracle 依赖系统的值得信赖的支持层 通过去中心化、加密工具和加密经济保证。 DON 本身是去中心化的，用户可以从任何可用的 DON 中进行选择 支持他们希望在其上操作或产生额外 DON 的主链 与他们信任的节点委员会。 然而，对于某些应用程序，特别是 smart contracts，Chainlink 用户可能会 支持将 DON 支持的主链视为更值得信赖的信任模型 比 DON 本身。对于此类用户，我们已经或计划将其纳入 Chainlink 网络的架构 一些支持合约的机制 在主链上，以加强 DONs 提供的安全保证，同时在 同时还加强保护，防止数据源损坏的可能性 例如 DON 从中获取数据的 Web 服务器。 我们在第 7 节中描述了这些机制。它们分为五个主要标题： • 数据源身份验证：支持数据提供者进行数字签名的工具 他们的数据，从而加强原产地和 依赖合同。 • DON 少数报告：由 DON 节点的少数子集发出的标志 观察到 DON 中存在多数渎职行为。 • 护栏：主链上的逻辑，用于检测异常情况并暂停 或停止合同执行（或调用其他补救措施）。 • 信任最小化治理：利用逐步发布的更新来促进社区检查，以及分散的紧急干预措施以实现快速 对系统故障的响应。 • 去中心化实体身份验证：使用公钥基础设施 (PKI) 识别 Chainlink 网络中的实体。 图 7 展示了我们的信任最小化目标的概念示意图。 基于激励（加密经济）的安全性： 跨 oracle 节点分散生成报告有助于确保安全，即使某些节点损坏也是如此。
图 7：Chainlink 信任最小化目标的概念描述，即 最大限度地减少用户对 DON 和数据源（例如网络）正确行为的需求 服务器。图中的黄色突出显示表示信任最小化位点：DON 和 单个或少数网络服务器组。粉色高亮显示系统组件 假设高度可信：blockchain 上的合同和大多数 Web 服务器的数量，即 Web 服务器的总数。 然而，同样重要的是确保节点有正确行为的经济激励。质押，即要求节点提供 LINK 押金和削减 如果出现不当行为，（没收）这些存款将在 Chainlink 中发挥关键作用。这是一个重要的激励设计，已在许多 blockchain 中使用， 例如，[81、103、120、204]。 然而，在 Chainlink 中的质押看起来与独立的 staking 有很大不同 blockchains。质押 blockchains 的目的是防止对共识的攻击。它有一个 Chainlink 中的不同目标：确保及时交付正确的 oracle 报告。用于 oracle 网络的精心设计的 staking 系统应该会引发诸如贿赂之类的攻击 即使目标是具有高值的 smart contract，对对手来说也是无利可图的 货币价值。 在本文中，我们提出了 Chainlink 中 staking 的通用方法，具有三个关键 创新点：1. 强大的对抗模型，涵盖现有技术中被忽视的攻击 接近。一个例子就是我们所说的潜在贿赂。这是一种形式 贿赂，确定哪些节点有条件地接受贿赂，例如， 提前向 staking 机制选择的节点提供有保证的贿赂 对于特定角色是随机的（例如触发报告裁决）。 2. 超线性 staking 影响，非正式地意味着要成功，对手的预算 B 美元必须大于所有 oracle 存款的总和 节点。 更准确地说，我们的意思是，作为 n 的函数， \(B(n) ≫\)dn 在 由 n 个 oracle 节点组成的网络，每个节点都有固定的存款金额 $d（更正式地说， \(B(n) is asymptotically larger in n than \)dn)。图8给出了概念图 此属性。 3. 隐性激励框架（IIF），我们设计的激励模型 除了明确存入staking之外，还包括根据经验可衡量的激励措施 资金，包括节点未来的费用机会。 IIF 扩展了以下概念： 超出明确节点存款的权益。 图 8：描述 Chainlink staking 中超线性缩放的概念图。的 对手所需的贿赂 $B(n) 在 n 中的增长速度快于存款总额的增长速度 所有 oracle 节点的 $dn。 我们展示了 IIF 和超线性 staking 共同影响如何导致我们 称之为 oracle 网络经济安全的良性循环。当新用户进入时
系统，增加运行 Chainlink 节点的未来潜在收入， 当前和未来用户的经济安全边际成本下降。在一个政权 需求弹性，成本的降低会激励更多用户使用 网络，在持续的良性循环中持续不断地采用。 注意：虽然本白皮书概述了我们对 Chainlink 发展愿景的重要元素，但它是非正式的，并且包含一些详细的技术细节。我们计划 随着其他功能和方法的发展，发布重点技术论文。 此外，必须强调的是，所提出的愿景的许多要素 这里（扩展改进、保密技术、FSS 等）可以而且将会 甚至在高级 DON 成为基本功能之前就以初步形式部署 Chainlink。 1.3 本文的组织 我们在第 2 节中介绍了我们的安全模型和符号，并概述了去中心化 Oracle Network API 在第 3 节中。在第 4 节中，我们提供了一些示例 DONs 为其提供有吸引力的部署平台的应用程序。读者可以 通过阅读到目前为止，您可以了解本文的大部分关键概念。 本文的其余部分包含更多详细信息。我们描述公平排序 第 5 节中的服务 (FSS) 和第 6 节中的事务执行框架 (TEF)。我们在第 7 节中描述了我们的信任最小化方法。我们考虑了一些 重要的 DON 部署要求，即第 8 节中的功能增量推出、动态账本成员资格和问责制。最后，在第 9 节中，我们给出 我们正在开发的激励设计方法的概述。我们在第 10 节中得出结论。 为了帮助对本文概念了解有限的读者，我们 附录 A 中提供了术语表。我们提供了有关 DON 接口的更多详细信息 和功能见附录 B，并在附录 C 中介绍一些示例适配器。 在附录 D 中，我们描述了信任最小化数据源的加密原语 身份验证称为功能签名，并引入一种称为离散功能签名的新变体。我们讨论与委员会有关的一些考虑因素 附录 F 中 DONs 的选择。
مقدمة
غالبًا ما يُنظر إلى Blockchain oracles اليوم على أنها خدمات لا مركزية ذات هدف واحد: لإعادة توجيه البيانات من الموارد خارج السلسلة إلى blockchains. إنها خطوة قصيرة، على أية حال، من إعادة توجيه البيانات إلى الحوسبة عليها أو تخزينها أو نقلها ثنائي الاتجاه. تبرر هذه الملاحظة فكرة أوسع بكثير عن وظائف oracles. كذلك أيضا تلبية متطلبات الخدمة المتزايدة لـ smart contracts والمتعددة الأوجه بشكل متزايد التقنيات التي تعتمد على شبكات oracle. باختصار، يمكن لـ oracle أن تفعل ذلك وسوف تحتاج إلى ذلك أن تكون واجهة ذات أغراض عامة وثنائية الاتجاه وممكّنة للحوسبة بين الأنظمة onchain والأنظمة خارج السلسلة. يتمثل دور Oracles في النظام البيئي blockchain في التحسين الأداء والوظائف وقابلية التشغيل التفاعلي لـ smart contracts حتى يتمكنوا من ذلك جلب نماذج ثقة جديدة وشفافية إلى العديد من الصناعات. سيأتي هذا التحول من خلال توسيع استخدام smart contracts الهجين، الذي يندمج خصائص blockchains الخاصة مع الإمكانات الفريدة للأنظمة خارج السلسلة مثل oracle الشبكات وبالتالي تحقيق وصول وقوة أكبر بكثير من الأنظمة الموجودة على السلسلة في عزلة. في هذا المستند التقني، نوضح رؤية لما نطلق عليه Chainlink 2.0، وهو تطور لـ Chainlink يتجاوز تصوره الأولي في Chainlink المستند التقني الأصلي [98]. نتوقع دورًا موسعًا بشكل متزايد لشبكات oracle، وهو دور فيه إنها تكمل وتعزز blockchains الحالية والجديدة من خلال توفير اتصال وحساب عالمي سريع وموثوق به ويحافظ على السرية للأنظمة الهجينة smart contracts. نحن نعتقد أن شبكات oracle سوف تتطور لتصبح أدوات مساعدة لتصدير بيانات عالية التكامل من فئة blockchain إلى أنظمة تتجاوز blockchain النظام البيئي. اليوم، Chainlink العقد التي تديرها مجموعة متنوعة من الكيانات تجتمع معًا في شبكات oracle لنقل البيانات إلى smart contract فيما يعرف بالتقارير. يمكننا أن نرى مثل هذا oracle العقد كلجنة مماثلة لتلك الموجودة في الإجماع الكلاسيكي blockchain [72]، ولكن بهدف دعم blockchains الموجودة، بدلاً من توفير وظائف قائمة بذاتها. مع وظائف عشوائية يمكن التحقق منها (VRF) وإعداد التقارير خارج السلسلة (OCR)، Chainlink يتطور بالفعل نحو إطار عمل وبنية تحتية للأغراض العامة لتوفير الموارد الحسابية التي تتطلبها smart contracts وظائف متقدمة. أساس خطتنا لـ Chainlink 2.0 هو ما نسميه أوراكل اللامركزية الشبكات، أو DONs للاختصار. منذ أن قدمنا مصطلح "شبكة oracle" في لقد طورت Chainlink الوثيقة البيضاء [98]، oracles وظائف ووظائف أكثر ثراءً من أي وقت مضى اتساع التطبيق. وفي هذه المقالة، نقدم تعريفًا جديدًا للمصطلح وفقًا لرؤيتنا المستقبلية للنظام البيئي Chainlink. في طريقة العرض هذه، DON عبارة عن شبكة تحتفظ بها لجنة مكونة من Chainlink العقد. متجذر في بروتوكول الإجماع، فإنه يدعم أيًا من مجموعة غير محدودة من وظائف oracle المختارة للنشر بواسطة اللجنة. وبالتالي فإن DON بمثابة طبقة تجريد blockchain، مما يوفر واجهات إلى الموارد خارج السلسلة لكل من smart contracts والأنظمة الأخرى. كما يوفر الوصول إلى موارد الحوسبة خارج السلسلة عالية الكفاءة ولكن لامركزية. بشكل عام، DON يدعم العمليات على السلسلة الرئيسية. هدفها هو تمكين آمنة ومرنةبلي هجين smart contracts، والذي يجمع بين العمليات الحسابية على السلسلة وخارج السلسلة مع الاتصال بالموارد الخارجية. نؤكد أنه حتى مع استخدام اللجان في DONs، فإن Chainlink نفسها يبقى بطبيعته غير مسموح به. DONs بمثابة أساس غير مسموح به إطار عمل يمكن أن تجتمع فيه العقد معًا لتنفيذ شبكات oracle المخصصة أنظمتهم الخاصة لإدراج العقدة، والتي قد تكون مسموحة أو غير مسموح بها. مع DONs كأساس، نخطط للتركيز في Chainlink 2.0 على التقدم في سبعة المجالات الرئيسية: smart contracts الهجين، وتجريد التعقيد، والتوسع، والسرية، وعدالة ترتيب المعاملات، وتقليل الثقة، والأمن القائم على الحوافز (الاقتصاد المشفر). في هذه المقدمة، نقدم لمحة عامة عن اللامركزية شبكات Oracle في القسم 1.1 ثم مجالات الابتكار السبعة الرئيسية لدينا في القسم 1.2. وصفنا تنظيم بقية هذه الورقة في القسم 1.3. 1.1 شبكات أوراكل اللامركزية تم تصميم شبكات أوراكل اللامركزية لتعزيز القدرات وتوسيعها من smart contracts على الهدف blockchain أو السلسلة الرئيسية من خلال الوظائف التي غير متوفر محليا. يفعلون ذلك من خلال توفير الموارد الأساسية الثلاثة الموجودة في أنظمة الحوسبة: الشبكات والتخزين والحساب. يهدف DON إلى العرض تتمتع هذه الموارد بخصائص قوية تتعلق بالسرية والنزاهة والتوافر،1 كما فضلا عن المساءلة. يتم تشكيل DONs من قبل لجان مكونة من oracle العقد التي تتعاون لتحقيق هدف محدد وظيفة أو اختيار إقامة علاقة طويلة الأمد من أجل تقديم خدمات مستمرة للعملاء. تم تصميم DONs بطريقة blockchain بطريقة ملحدة. يعدون بالعمل أداة قوية ومرنة لمطوري التطبيقات لإنشاء دعم خارج السلسلة لـ smart contracts الخاصة بهم على أي سلسلة رئيسية مدعومة. هناك نوعان من الوظائف يدركان قدرات DON: الملفات التنفيذية و محولات. الملفات التنفيذية هي برامج يتم تشغيلها بشكل مستمر وبطريقة لا مركزية على DON. على الرغم من أنها لا تقوم بتخزين أصول السلسلة الرئيسية بشكل مباشر، إلا أنها تتمتع بفوائد مهمة، بما في ذلك الأداء العالي والقدرة على أداء عمليات سرية حساب. تعمل الملفات التنفيذية بشكل مستقل على DON وتؤدي أداءً حتميًا العمليات. وهي تعمل جنبًا إلى جنب مع المحولات التي تربط DON بالموارد الخارجية ويمكن استدعاؤها بواسطة الملفات التنفيذية. المحولات، كما نتصورها لـ DONs، هي أ تعميم المحولات الخارجية في Chainlink اليوم. بينما المحولات الموجودة عادةً ما يتم جلب البيانات من مصادر البيانات فقط، وقد تعمل المحولات بشكل ثنائي الاتجاه؛ في DONs، يمكنهم أيضًا الاستفادة من الحساب المشترك بواسطة DON العقد لتحقيقه ميزات إضافية، مثل تشفير التقارير للاستهلاك الذي يحافظ على الخصوصية قابل للتنفيذ. لتوفير فكرة عن العملية الأساسية لـ DON، يوضح الشكل 1 من الناحية النظرية كيف يمكن لـ DON أن يمكن استخدام DON لإرسال التقارير إلى blockchain وبالتالي تحقيق وظيفة oracle التقليدية الموجودة. ومع ذلك، يمكن أن يوفر DONs العديد من الميزات الإضافية 1"ثالوث وكالة المخابرات المركزية" لأمن المعلومات [123، ص. 26، §2.3.5].شبكات Chainlink الحالية. على سبيل المثال، ضمن الهيكل العام للشكل 1، يمكن للملف القابل للتنفيذ تسجيل بيانات أسعار الأصول التي تم جلبها على DON، باستخدام هذه البيانات حساب، على سبيل المثال، متوسط زائدة لتقاريرها. الشكل 1: شكل مفاهيمي يوضح كمثال كيف يمكن لشبكة Oracle اللامركزية تحقيق وظائف oracle الأساسية، أي ترحيل البيانات خارج السلسلة إلى العقد. ان يستخدم الملف القابل للتنفيذ محولات لجلب البيانات خارج السلسلة، والتي يحسب عليها، ويرسل المخرجات عبر محول آخر إلى الهدف blockchain. (يتم بدء تشغيل المحولات بواسطة التعليمات البرمجية الموجودة في ملف DON، ممثلة بمربعات زرقاء صغيرة؛ تظهر الأسهم اتجاه تدفق البيانات لهذا الغرض مثال محدد.) يمكن للملف القابل للتنفيذ أيضًا القراءة والكتابة إلى DON المحلي تخزين للحفاظ على الحالة و/أو التواصل مع الملفات التنفيذية الأخرى. تتيح الشبكات المرنة والحسابات والتخزين في DONs، كلها ممثلة هنا، مجموعة كبيرة من الروايات التطبيقات. تتمثل إحدى المزايا الرئيسية لـ DONs في قدرتها على تشغيل خدمات blockchain الجديدة. DONs هي وسيلة يمكن من خلالها لشبكات oracle الحالية أن تدعم تطبيقات الخدمة بسرعة وهذا يتطلب اليوم إنشاء شبكات مصممة لهذا الغرض. نعطي عددا من أمثلة على هذه التطبيقات في القسم 4. في القسم 3، نقدم المزيد من التفاصيل حول DONs، مع وصف قدراتها في شروط الواجهة التي يقدمونها للمطورين والمستخدمين. 1.2 سبعة أهداف التصميم الرئيسية نحن هنا نراجع بإيجاز النقاط الرئيسية السبعة المذكورة أعلاه لتطور Chainlink، وهي:الهجين smart contracts: من الأمور المركزية في رؤيتنا لـ Chainlink هي فكرة الأمان الجمع بين المكونات الموجودة على السلسلة وخارجها في smart contracts. نشير إلى العقود تحقيق هذه الفكرة على أنها smart contracts هجينة أو عقود هجينة.2 بلوكتشين ستستمر في لعب دورين حاسمين في الخدمة اللامركزية الأنظمة البيئية: كلاهما المكان الذي يتم فيه تمثيل ملكية العملة المشفرة ومرتكزات قوية للخدمات اللامركزية. ولذلك يجب تمثيل العقود الذكية أو تنفيذها على السلسلة، ولكن قدراتها على السلسلة محدودة للغاية. بحتة رمز العقد على السلسلة بطيء ومكلف ومنعزل وغير قادر على الاستفادة من العالم الحقيقي البيانات ومجموعة متنوعة من الوظائف التي لا يمكن تحقيقها بطبيعتها على السلسلة، بما في ذلك الأشكال المختلفة للحساب السري، وتوليد العشوائية (الزائفة) الآمنة ضد التلاعب بعامل المنجم / validator وما إلى ذلك. لكي يحقق smart contracts إمكاناتهم الكاملة، يتطلب الأمر smart contracts سيتم تصميمه من جزأين: جزء متصل بالسلسلة (والذي نشير إليه عادةً بـ SC) وجزء خارج السلسلة، وهو ملف قابل للتنفيذ يعمل على DON (والذي نشير إليه عادةً بـ تنفيذي). الهدف هو تحقيق تكوين آمن للوظائف الموجودة على السلسلة باستخدام تعدد الخدمات خارج السلسلة التي تهدف DON إلى توفيرها. معا، الجزأين تكوين عقد هجين. نقدم الفكرة من الناحية المفاهيمية في الشكل 2. واليوم بالفعل، Chainlink خدمات 3 مثل خلاصات البيانات وVRFs لا يمكن تحقيقها بأي طريقة أخرى smart contract التطبيقات، التي تتراوح من DeFi إلى NFTs التي تم إنشاؤها بشكل عادل إلى التأمين اللامركزي، كخطوات أولى نحو إطار عمل أكثر عمومية. كخدمات Chainlink التوسع والنمو بشكل أكثر أداءً وفقًا لرؤيتنا الواردة في هذا المستند التقني، وكذلك الأمر بالنسبة لنا ستعمل قوة أنظمة smart contract عبر جميع blockchains. يمكن النظر إلى نقاط التركيز الرئيسية الستة الأخرى في هذا التقرير على أنها تعمل في الخدمة من الأول، وهو شامل للعقود الهجينة. تتضمن هذه التركيزات إزالة المرئية التعقيد من العقود المختلطة، مما يؤدي إلى إنشاء خدمات إضافية خارج السلسلة تمكن وبناء عقود هجينة أكثر قدرة من أي وقت مضى، وفي حالة تقليل الثقة، تعزيز الخصائص الأمنية التي تحققها العقود الهجينة. نترك الفكرة من العقود الهجينة الضمنية في جزء كبير من الورقة، ولكن أي مزيج من يمكن اعتبار منطق MAINCHAIN مع DON بمثابة عقد مختلط. تجريد التعقيد: تم تصميم DONs للاستفادة من اللامركزية أنظمة سهلة للمطورين والمستخدمين من خلال استخلاص الآلات المعقدة في كثير من الأحيان وراء مجموعة خدمات DONs القوية والمرنة. خدمات Chainlink الموجودة لديك بالفعل هذه الميزة. على سبيل المثال، تقدم خلاصات البيانات في Chainlink اليوم واجهات onchain لا تتطلب من المطورين الاهتمام بالتفاصيل على مستوى البروتوكول، مثل الوسائل التي يفرض بها التعرف الضوئي على الحروف (OCR) إعداد التقارير المتفق عليها بين 2 لقد نشأت فكرة تكوين العقود على السلسلة / خارج السلسلة سابقًا في العديد من القيود المقيدة النماذج، على سبيل المثال، أنظمة الطبقة الثانية، المستندة إلى TEE blockchains [80]، وما إلى ذلك. هدفنا هو الدعم والتعميم هذه الأساليب والتأكد من أنها يمكن أن تشمل الوصول إلى البيانات خارج السلسلة والمفاتيح الأخرى oracle الخدمات. تشتمل خدمات 3Chainlink على مجموعة متنوعة من الخدمات والوظائف اللامركزية المتاحة من خلال الشبكة. يتم تقديمها من قبل العديد من مشغلي العقد المكونة من شبكات oracle المختلفة عبر النظام البيئي.الشكل 2: شكل مفاهيمي يصور تكوين العقد على السلسلة / خارج السلسلة. أ هجين smart contract 3⃝يتكون من مكونين متكاملين: متصل بالسلسلة المكون SC 1⃝، المقيم في blockchain، والمكون خارج السلسلة exec 2⃝ذلك ينفذ على DON. يعمل DON كجسر بين المكونين أيضًا مثل ربط العقد المختلط بموارد خارج السلسلة مثل خدمات الويب وغيرها blockchains، والتخزين اللامركزي، وما إلى ذلك. مجموعة لامركزية من العقد. DONs يذهبون إلى أبعد من ذلك بمعنى أنهم يوسعون مجموعة من الخدمات التي يمكن لـ Chainlink أن يقدم للمطورين طبقة تجريد بها واجهات مبسطة مصاحبة للخدمات عالية المستوى. نقدم العديد من الأمثلة التطبيقية في القسم 4 التي تسلط الضوء على هذا النهج. نحن نتصور أن المؤسسات، على سبيل المثال، تستخدم DONs كشكل من أشكال البرامج الوسيطة الآمنة قم بتوصيل أنظمتهم القديمة بـ blockchains. (انظر القسم 4.2.) يؤدي هذا الاستخدام لملخصات DON إلى التخلص من تعقيد ديناميكيات blockchain العامة (الرسوم، وعمليات إعادة التنظيم، وما إلى ذلك). إنه أيضًا يلخص ميزات blockchains المحددة، وبالتالي تمكين المؤسسات من ربط أنظمتها الحالية بمجموعة متزايدة باستمرار من أنظمة blockchain بدون الحاجة إلى خبرة متخصصة في هذه الأنظمة، أو بشكل أعم، في تطوير الأنظمة اللامركزية. في نهاية المطاف، طموحنا هو دفع درجة التجريد التي حققها Chainlink إلى درجة تنفيذ ما نشير إليه بطبقة معدنية لامركزية. مثل هذه الطبقة من شأنه أن يزيل التمييز على السلسلة / خارج السلسلة لجميع فئات المطورين ومستخدمي التطبيقات اللامركزية، مما يسمح بإنشاء واستخدام الخدمات اللامركزية بشكل سلس.لتبسيط عملية التطوير، يمكن للمطورين تحديد وظيفة DApp في الطبقة المعدنية كتطبيق افتراضي في نموذج جهاز موحد. يمكنهم ذلك ثم استخدم مترجم طبقة ميتا لامركزية لإنشاء مثيل DApp تلقائيًا مجموعة من الوظائف اللامركزية المتداخلة التي تمتد على blockchains، DONs، و الخدمات الخارجية. (يمكن أن تكون إحدى هذه الخدمات الخارجية نظامًا مؤسسيًا، مما يجعل الطبقة المعدنية مفيدة للتطبيقات التي تتضمن أنظمة مؤسسية قديمة). يشبه التجميع كيفية قيام المترجمين الحديثين ومجموعات تطوير البرامج (SDKs) دعم المبرمجين العموميين في استخدام الإمكانات الكاملة للأجهزة غير المتجانسة معماريات تتكون من وحدة معالجة مركزية للأغراض العامة وأجهزة متخصصة مثل وحدات معالجة الرسومات، مسرعات التعلم الآلي، أو الجيوب الموثوقة. يعرض الشكل 3 هذه الفكرة على المستوى المفاهيمي. تعد العقود الهجينة smart contracts خطوة أولى على الطريق نحو هذه الرؤية وإلى مفهوم نسميه العقود الوصفية. العقود الوصفية هي تطبيقات مشفرة على اللامركزية طبقة ميتالية وتشمل ضمنيًا منطق السلسلة (smart contracts)، بالإضافة إلى حساب خارج السلسلة والاتصال بين مختلف blockchains وداخل السلسلة الحالية الخدمات. نظرا للحاجة إلى دعم اللغة والمترجم، ونماذج الأمان الجديدة، و ولكن تحقيق المواءمة المفاهيمية والتقنية للتكنولوجيات المتباينة أمر ممكن إن إنشاء طبقة معدنية لامركزية حقيقية هو هدف طموح نطمح إليه على مدى فترة طويلة الأفق الزمني. ومع ذلك فهو نموذج مثالي مفيد يجب أخذه في الاعتبار أثناء القراءة هذه الورقة، ليست مفصلة هنا، ولكنها شيء نخطط للتركيز عليه في عملنا المستقبلي Chainlink. التحجيم: أحد الأهداف ذات الأهمية البارزة في تصميماتنا المتطورة هو تمكين شبكة Chainlink لتلبية احتياجات التوسع المتزايدة للنظام البيئي blockchain. مع تحول ازدحام الشبكة إلى مشكلة متكررة في القائمة غير المسموح بها blockchains [86]، تصميمات blockchain الجديدة والأكثر أداءً تدخل حيز الاستخدام، على سبيل المثال، [103، 120، 203]، بالإضافة إلى تقنيات قياس الطبقة الثانية التكميلية، على سبيل المثال، [5، 12، 121، 141، 169، 186، 187]. يجب أن تحقق خدمات Oracle زمن الاستجابة والإنتاجية التي تلبي متطلبات أداء هذه الأنظمة مع تقليل الرسوم على السلسلة (على سبيل المثال، تكاليف الغاز) لمشغلي العقود والمستخدمين العاديين على حد سواء. مع DONs، Chainlink تهدف الوظيفة إلى المضي قدمًا وتقديم أداء عالٍ بما يكفي للأنظمة المستندة إلى الويب تمامًا. تستمد DONs الكثير من مكاسب أدائها من استخدامها لبروتوكولات الإجماع السريعة أو القائمة على اللجان أو غير المسموح بها، والتي تدمجها مع blockchains إنهم يدعمون. نتوقع تشغيل العديد من DONs ذات التكوينات المختلفة بالتوازي؛ يمكن للتطبيقات اللامركزية والمستخدمين المختلفين التنقل بين المفاضلات في خيارات الإجماع الأساسية وفقا لمتطلبات التطبيق الخاصة بهم. يمكن عرض DONs بشكل فعال كتقنيات الطبقة الثانية. نتوقع أن بين الخدمات الأخرى، DONs ستدعم إطار عمل تنفيذ المعاملات (TEF)، والذي يسهل التكامل الفعال لـ DONs وبالتالي oracles مع غيرها من الأداء العالي أنظمة الطبقة الثانية - على سبيل المثال، rollups، الأنظمة التي تجمع المعاملات خارج السلسلة لتحقيقها تحسينات في الأداء. نقدم TEF في القسم 6.
الشكل 3: شكل مفاهيمي يوضح الإدراك المثالي لطبقة معدنية لا مركزية. ل لسهولة التطوير، يحدد المطور التطبيق اللامركزي، المميز باللون الوردي، باعتباره تطبيقًا افتراضيًا التطبيق في نموذج الآلة الموحدة يقوم المترجم اللامركزي ذو الطبقة المعدنية تلقائيًا بإنشاء وظائف التشغيل البيني المقابلة: smart contracts (يُشار إليه بواسطة SC)، المنطق (المشار إليه بواسطة exec) على DONs، والمحولات التي تتصل بالخدمات الخارجية المستهدفة، وما إلى ذلك، كما هو موضح في التمييز باللون الأصفر. يوضح الشكل 4 من الناحية النظرية كيف تعمل DONs على تحسين مقياس blockchain (smart contract) من خلال تركيز المعاملات وoracle-معالجة التقارير خارج السلسلة، بدلاً من التركيز عليها سلسلة. هذا التحول في الموقع الرئيسي للحساب يقلل من زمن الوصول للمعاملة الرسوم مع زيادة إنتاجية المعاملات. السرية: توفر Blockchains شفافية غير مسبوقة لـ smart contracts والتطبيقات التي تنفذها. ولكن هناك توتراً أساسياً بين الشفافية والسرية. واليوم، على سبيل المثال، أصبحت عمليات التبادل اللامركزية للمستخدمينالشكل 4: شكل مفاهيمي يوضح كيفية تحسين شبكات أوراكل اللامركزية تحجيم blockchain smart contracts الممكنة. الشكل أ ⃝يظهر تقليدي oracle الهندسة المعمارية. يتم إرسال المعاملات مباشرة إلى blockchain، وكذلك التقارير oracle. وبالتالي فإن blockchain، المميز باللون الأصفر، هو الموقع الرئيسي لمعالجة المعاملات. يوضح الشكل ب⃝ استخدام DON لدعم العقود على blockchain. أ DON المعاملات العملياتية القابلة للتنفيذ جنبًا إلى جنب مع البيانات من الأنظمة الخارجية والأمام النتائج - على سبيل المثال، المعاملات المجمعة أو تغييرات حالة العقد الناتجة عن تأثيرات المعاملات - إلى blockchain. وبالتالي فإن DON، المظلل باللون الأصفر، هو العنصر الرئيسي مكان لمعالجة المعاملات. يتم تسجيل الإجراءات على السلسلة، مما يجعل من السهل مراقبة سلوك التبادل، ولكن أيضًا جعل المعاملات المالية للمستخدمين مرئية للعامة. وبالمثل، يتم نقل البيانات إلى الأجهزة الذكية العقود لا تزال على السلسلة. وهذا يجعل هذه البيانات قابلة للتدقيق بشكل ملائم، ولكنها تعمل أيضًا وهو عامل مثبط لموفري البيانات الراغبين في تزويد smart contracts ببيانات حساسة أو بيانات الملكية. نعتقد أن شبكات oracle ستلعب دورًا محوريًا في تحفيز الجيل التالي الأنظمة التي تجمع بين الشفافية الفطرية لـ blockchains ووسائل حماية السرية الجديدة. وفي هذه الورقة، نوضح كيف سيفعلون ذلك باستخدام ثلاثة أساليب رئيسية: • محولات الحفاظ على السرية: تقنيتان مع التخطيط للنشر في شبكات Chainlink، DECO [234] وTown Crier [233]، قم بتمكين العقد oracle لـ استرداد البيانات من الأنظمة خارج السلسلة بطرق تحمي خصوصية المستخدم وبياناته السرية. سوف يلعبون دورًا رئيسيًا في تصميم المحولات الخاصة بـ DONs. (انظر القسم 3.6.2 للحصول على تفاصيل حول هاتين التقنيتين.) • الحساب السري: يمكن لـ DONs ببساطة إخفاء حساباتهم من الاعتماد على blockchains. باستخدام حساب آمن متعدد الأطراف و/أو بيئات تنفيذ موثوقة، من الممكن أيضًا توفير سرية أقوى في DON العقد حساب البيانات التي لا يمكنهم رؤيتها بأنفسهم.
• دعم أنظمة الطبقة الثانية السرية: تم تصميم TEF لدعم مجموعة متنوعة من أنظمة الطبقة الثانية، والتي يستخدم الكثير منها براهين المعرفة الصفرية لتوفير أشكال مختلفة من سرية المعاملات. نناقش هذه الأساليب في القسم 3 (مع تفاصيل إضافية في القسم 6، الملحق ب.1، والملحق ب.2). يقدم الشكل 5 وجهة نظر مفاهيمية لكيفية تدفق البيانات الحساسة من مصادر خارجية إلى smart contract عن طريق محولات الحفاظ على السرية و حساب سري في DON. الشكل 5: رسم تخطيطي مفاهيمي لعمليات الحفاظ على السرية في DON على البيانات الحساسة (مظللة باللون الأصفر). بيانات المصدر الحساسة (الدوائر السوداء) في الويب يتم استخراج الخوادم إلى DON باستخدام محولات الحفاظ على السرية (الخطوط الزرقاء ذات الأسهم المزدوجة). يتلقى DON البيانات المشتقة (دوائر مجوفة) من هذه المحولات— نتيجة تطبيق وظيفة أو، على سبيل المثال، مشاركة سرية، على المصدر الحساس data. قد يطبق الملف القابل للتنفيذ على DON حسابًا سريًا على البيانات المشتقة لإنشاء تقرير (دائرة مزدوجة)، يتم إرساله عبر محول إلى blockchain. ونحن نعتقد أن الأدوات القوية للتعامل مع البيانات السرية ستفتح المجال أمام الجميع مجموعة من التطبيقات. ومن بين هذه العوامل التمويل اللامركزي (والمركزي) الخاص، والهوية اللامركزية، والإقراض القائم على الائتمان، وتوفير المزيد من الكفاءة والفعالية. بروتوكولات "اعرف عميلك" و"الاعتماد" سهلة الاستخدام، كما نناقش في القسم 4. عدالة الطلب في المعاملات: تصميمات blockchain اليوم بها القليل من الأشياء القذرة سر مفتوح: إنها مركزية بشكل سريع الزوال. يمكن لعمال المناجم وvalidators طلب التحويلالإجراءات التي يختارونها. يمكن أيضًا للمستخدمين التلاعب بأمر المعاملة وظيفة رسوم الشبكة التي يدفعونها (على سبيل المثال، أسعار الغاز في Ethereum) وبالنسبة للبعض المدى من خلال الاستفادة من اتصالات الشبكة السريعة. مثل هذا التلاعب يمكن أن يكون على سبيل المثال، خذ شكل المنافسة الأمامية، حيث يكون هناك ممثل استراتيجي مثل عامل المناجم يراقب معاملة المستخدم ويدرج المعاملة الاستغلالية الخاصة به في معاملة سابقة الموضع في نفس الكتلة - سرقة الأموال بشكل فعال من المستخدم من خلال الاستفادة من المعرفة المسبقة بمعاملة المستخدم. على سبيل المثال، قد يقوم الروبوت بوضع أمر شراء قبل المستخدم. ويمكنه بعد ذلك الاستفادة من الزيادة في أسعار الأصول الناجمة عن تجارة المستخدم. تشغيل بعض الروبوتات في المقدمة مما يضر بالمستخدمين العاديين، وهو ما يشبه التردد العالي التداول في وول ستريت — هو أمر سائد بالفعل وموثق جيدًا [90]، كما هو مرتبط هجمات مثل التشغيل الخلفي [159] ومحاكاة المعاملات الآلية [195]. وقد ظهرت مؤخرًا مقترحات لتنظيم استغلال الطلب من قبل القائمين بالتعدين [110]. تقنيات الطبقة الثانية مثل rollups لا تحل المشكلة، ولكنها مجرد إعادة مركزية الطلب، ووضعه في يد الكيان الذي يقوم بإنشاء rollup. أحد أهدافنا هو تقديم خدمة تسمى "التسلسل العادل" إلى Chainlink الخدمات (FSS) [137]. تساعد FSS مصممي smart contract على ضمان الترتيب العادل لأعمالهم المعاملات وتجنب الهجمات الأمامية والخلفية والهجمات ذات الصلة على معاملات المستخدم بالإضافة إلى أنواع أخرى من المعاملات، مثل oracle إرسال التقرير. الخدمة الثابتة الساتلية يمكّن DON من تنفيذ أفكار مثل المفهوم الدقيق والمؤقت لعدالة النظام المقدم في [144]. وكميزة عرضية، يمكن للخدمة الثابتة الساتلية أيضًا أن تخفض شبكة المستخدمين الرسوم (مثل تكاليف الغاز). باختصار، في الخدمة الثابتة الساتلية، تمر المعاملات عبر DON، بدلاً من الانتشار مباشرة إلى الهدف smart contract. يقوم DON بطلب المعاملات ثم إعادة توجيهها لهم بالعقد. الشكل 6: مثال على مدى فائدة الخدمة الثابتة الساتلية. الشكل أ ⃝يبين كيف يقوم عامل المناجم باستغلاله السلطة المركزية لطلب المعاملات، قد تقوم بتبديل زوج من المعاملات: المعاملة 1⃝ يصل قبل 2⃝، لكن عامل التعدين يقوم بتسلسله بعد 2⃝. في المقابل، يظهر الشكل B⃝ كيف يقوم DON بإضفاء اللامركزية على عملية الطلب بين DON العقد. إذا اكتمل النصاب القانوني تستقبل العقد الصادقة 1⃝قبل 2⃝، يتسبب FSS في ظهور 1⃝قبل 2⃝على السلسلة— منع إعادة ترتيب المُعدنين عن طريق إرفاق أرقام تسلسلية قابلة للتنفيذ بموجب العقد. يقارن الشكل 6 التعدين القياسي مع الخدمة الثابتة الساتلية. ويبين كيف في التعدين القياسي،تتم عملية طلب المعاملات بشكل مركزي مع القائم بالتعدين وبالتالي تخضع لـ التلاعب، مثل إعادة ترتيب زوج من المعاملات فيما يتعلق بوصولها مرات. في المقابل، في FSS، تكون العملية لا مركزية بين العقد DON. على افتراض النصاب القانوني للعقد الصادقة، FSS يساعد على فرض سياسات مثل الترتيب الزمني لل المعاملات، مما يقلل من فرص التلاعب من قبل عمال المناجم والكيانات الأخرى. بالإضافة إلى ذلك، نظرًا لأن المستخدمين لا يحتاجون إلى التنافس للحصول على طلبات تفضيلية بناءً على سعر الغاز، يمكنهم دفع أسعار غاز منخفضة نسبيًا (بينما يمكن تجميع المعاملات من DON على دفعات لتوفير الغاز). تقليل الثقة: هدفنا العام في تصميم DONs هو تسهيل عملية للغاية طبقة دعم جديرة بالثقة لـ smart contracts والأنظمة الأخرى المعتمدة على oracle عن طريق اللامركزية وأدوات التشفير وضمانات الاقتصاد المشفر. DON في حد ذاته لا مركزي، ويمكن للمستخدمين الاختيار من بين أي DON متاح يدعم السلسلة الرئيسية التي يرغبون في تشغيلها أو إنتاج DONs إضافية عليها بلجان العقد التي يثقون بها. ومع ذلك، بالنسبة لبعض التطبيقات، وخاصة smart contracts، يجوز لمستخدمي Chainlink تفضيل نموذج الثقة الذي يتعامل مع السلسلة الرئيسية المدعومة بـ DON على أنها أكثر جدارة بالثقة من DON نفسها. بالنسبة لهؤلاء المستخدمين، لدينا بالفعل أو نخطط لدمجهم في بنية شبكة Chainlink عدد من الآليات التي تمكن العقود على سلسلة رئيسية لتعزيز الضمانات الأمنية المقدمة من DONs، أثناء وجوده في وفي نفس الوقت يتم أيضًا فرض الحماية ضد احتمالية وجود مصادر بيانات تالفة مثل خوادم الويب التي يحصل منها DON على البيانات. نصف هذه الآليات في القسم 7. وهي تقع تحت خمسة عناوين رئيسية: • مصادقة مصدر البيانات: أدوات تمكن موفري البيانات من التوقيع رقميًا بياناتهم وبالتالي تعزيز سلسلة العهدة بين الأصل و عقد الاعتماد. • DON تقارير الأقلية: العلامات الصادرة عن مجموعة فرعية من DON العقد التي لاحظ مخالفات الأغلبية في DON. • حواجز الحماية: المنطق الموجود على السلسلة الرئيسية الذي يكتشف الظروف الشاذة والتوقف المؤقت أو يوقف تنفيذ العقد (أو يستدعي علاجات أخرى). • الحوكمة التي تقلل من الثقة: استخدام تحديثات الإصدار التدريجي لتسهيل التفتيش المجتمعي، بالإضافة إلى التدخلات اللامركزية في حالات الطوارئ من أجل التدخل السريع الاستجابة لفشل النظام. • مصادقة الكيان اللامركزي: استخدام البنية التحتية للمفتاح العام (PKI) من أجل تحديد الكيانات في شبكة Chainlink. يعرض الشكل 7 مخططًا مفاهيميًا لأهدافنا المتعلقة بتقليل الثقة. الأمن القائم على الحوافز (الاقتصاد المشفر): تساعد اللامركزية في إنشاء التقارير عبر العقد oracle على ضمان الأمان حتى في حالة تلف بعض العقد.
الشكل 7: تصوير مفاهيمي لهدف تقليل الثقة لدى Chainlink، وهو تقليل حاجة المستخدمين إلى السلوك الصحيح لـ DON ومصادر البيانات مثل الويب الخوادم. تشير النقاط المميزة باللون الأصفر في الشكل إلى مواقع تقليل الثقة: DON و مجموعات فردية أو أقلية من خوادم الويب. تشير النقاط المميزة باللون الوردي إلى مكونات النظام التي تعتبر جديرة بالثقة للغاية من خلال الافتراض: العقود على blockchain والأغلبية من خوادم الويب، أي خوادم الويب في المجمل. لكن من المهم بنفس القدر ضمان أن يكون لدى العقد حافز مالي للتصرف بشكل صحيح. التوقيع المساحي، أي مطالبة العقد بتوفير ودائع الارتباط والقطع (مصادرة) هذه الودائع في حالة سوء السلوك، ستلعب دورًا رئيسيًا في Chainlink. إنه تصميم حوافز مهم تم استخدامه بالفعل في عدد من blockchains، على سبيل المثال، [81، 103، 120، 204]. ومع ذلك، يبدو التخزين في Chainlink مختلفًا تمامًا عن staking في الوضع المستقل blockchains. يهدف التخزين في blockchains إلى منع الهجمات على الإجماع. لديها هدف مختلف في Chainlink: ضمان تسليم تقارير oracle الصحيحة في الوقت المناسب. يجب أن يؤدي نظام staking المصمم جيدًا لشبكة oracle إلى التصدي لهجمات مثل الرشوة غير مربحة للخصم، حتى عندما يكون الهدف هو smart contract ذو مستوى عالٍ القيمة النقدية. نقدم في هذا البحث منهجًا عامًا لـ staking في Chainlink بثلاثة مفاتيح الابتكارات:1. نموذج عدائي قوي يشمل الهجمات التي تم التغاضي عنها في الوقت الحالي النهج. أحد الأمثلة على ذلك هو ما نسميه الرشوة المحتملة. هذا هو شكل من أشكال الرشوة التي تحدد العقد التي تتلقى الرشاوى على أساس مشروط، على سبيل المثال، يقدم رشاوى مضمونة مقدمًا للعقد التي تحددها آلية staking في عشوائي لأدوار معينة (مثل تفعيل الفصل في التقرير). 2. التأثير الخطي الفائق staking، مما يعني بشكل غير رسمي أنه لكي ينجح الخصم، يجب أن تكون لديه ميزانية قدرها مليار دولار أكبر من الودائع المجمعة لجميع oracle العقد. بتعبير أدق، نعني أنه كدالة لـ n، \(B(n) ≫\)dn في a شبكة مكونة من عدد n oracle من العقد لكل منها مبلغ إيداع ثابت $d (بشكل أكثر رسمية، \(B(n) is asymptotically larger in n than \)dn). الشكل 8 يعطي نظرة مفاهيمية ل هذه الخاصية. 3. إطار الحوافز الضمنية (IIF)، وهو نموذج حوافز صممناه من أجله تشمل حوافز قابلة للقياس تجريبيًا تتجاوز الحوافز المودعة بشكل صريح staking الأموال، بما في ذلك فرص الرسوم المستقبلية للعقد. يوسع معهد التمويل الدولي مفهوم حصة تتجاوز ودائع العقدة الصريحة. الشكل 8: رسم تخطيطي مفاهيمي يصور القياس الخطي الفائق في Chainlink staking. ال تنمو الرشوة $B(n) التي يطلبها الخصم بشكل أسرع في n من الودائع المجمعة $dn لجميع العقد oracle. نوضح كيف أن تأثير IIF والخط الفائق staking معًا يؤدي إلى ما نحن عليه استدعاء دورة حميدة من الأمن الاقتصادي لشبكات oracle. عندما يدخل مستخدمون جدد
النظام، وزيادة الأرباح المستقبلية المحتملة من تشغيل Chainlink العقد، و تنخفض التكلفة الحدية للأمن الاقتصادي للمستخدمين الحاليين والمستقبليين. في نظام الطلب المرن، فإن هذه التكلفة المنخفضة تحفز المزيد من المستخدمين على الاستفادة من الشبكة، مما يؤدي إلى إدامة التبني بشكل مستمر في دورة حميدة مستمرة. ملاحظة: على الرغم من أن هذا التقرير يوضح العناصر المهمة لرؤيتنا لتطور Chainlink، إلا أنه غير رسمي ويتضمن القليل من المواصفات الفنية التفصيلية. نحن نخطط ل إصدار أوراق فنية مركزة حول الميزات والأساليب الإضافية مع تطورها. علاوة على ذلك، من المهم التأكيد على أن العديد من عناصر الرؤية المقدمة هنا (تحسينات القياس، وتقنيات السرية، والخدمة الثابتة الساتلية، وما إلى ذلك) يمكن أن يحدث وسوف يحدث تم نشرها في شكل أولي حتى قبل أن تصبح DONs المتقدمة سمة أساسية لـ Chainlink. 1.3 تنظيم هذه الورقة نقدم نموذج الأمان الخاص بنا والترميز في القسم 2 ونحدد اللامركزية Oracle Network API في القسم 3. في القسم 4، نقدم عددًا من الأمثلة على ذلك التطبيقات التي توفر DONs لها نظامًا أساسيًا للنشر جذابًا. يمكن للقراء تعلم معظم المفاهيم الأساسية للورقة من خلال القراءة حتى هذه النقطة. يحتوي الجزء المتبقي من الورقة على مزيد من التفاصيل. وصفنا التسلسل العادل الخدمات (FSS) في القسم 5 وإطار تنفيذ المعاملات (TEF) في القسم 6. نوضح نهجنا لتقليل الثقة في القسم 7. ونأخذ في الاعتبار بعض متطلبات النشر المهمة DON، وهي النشر المتزايد للميزات، وعضوية دفتر الأستاذ الديناميكي، والمساءلة في القسم 8. وأخيرًا، في القسم 9، نقدم نظرة عامة على نهجنا المتطور لتصميم الحوافز. ننتهي في القسم 10. لمساعدة القراء الذين لديهم معرفة محدودة بالمفاهيم الواردة في هذه الورقة، نحن قم بتوفير مسرد في الملحق أ. ونقدم المزيد من التفاصيل حول واجهة DON والوظائف في الملحق ب وتقديم بعض أمثلة المحولات في الملحق ج. في الملحق د، وصفنا طريقة تشفير أولية لمصدر البيانات ذي الثقة المنخفضة تسمى المصادقة بالتوقيعات الوظيفية وتقدم متغيرًا جديدًا يسمى التوقيعات الوظيفية المنفصلة. نناقش بعض الاعتبارات التي تؤثر على اللجنة تحديد DONs في الملحق F.
安全模型和目标
去中心化预言机网络是一个独特的分布式系统，我们预计它将 最初通常（尽管不一定）由以委员会为基础的委员会实施 共识协议并由一组 oracle 节点运行。 DON 主要设计为 使用 oracle 报告增强主链上 smart contract 的功能 和其他服务，但它可以为其他非blockchain系统提供相同的支持服务，因此不需要与特定的主链相关联。
因此，我们考虑的模型和属性在很大程度上独立于 DON 的特定应用。 2.1 当前的建筑模型 需要强调的是，今天的 Chainlink 不是一个单一的服务，而是 一个无需许可的框架，可以在其中启动独特的、独立的 oracle 节点 [77] 的网络。网络具有异构的节点运营商集， 设计。他们提供的服务类型也可能有所不同，这可以 包括例如数据馈送、储备证明、可验证的随机性等。其他 差异可能包括去中心化程度、网络规模 它支持的锁定值以及各种服务级别参数，例如数据频率 和准确性。 Chainlink 的无需许可模式鼓励生态系统的发展，其中 提供商专注于他们最有能力为社区提供的服务。这个 与模型相比，模型可能会降低用户成本并提高服务质量 要求所有节点和网络提供全方位的服务，一种方法 这可以很容易地转变为全系统采用代表最少的服务 节点可用资源的共同点。 随着 Chainlink 在 Chainlink 2.0 中向基于 DON 的设计发展，我们继续 支持无需许可的开放框架模型，同时考虑到以下目标： 为用户提供一系列服务选择，在全球范围内实现最佳匹配 具有特定的应用要求。 2.2 共识假设 我们使用术语“去中心化预言机网络”来涵盖 我们描述的 oracle 系统： oracle 节点维护的数据结构和 核心 API 位于其之上。 我们使用术语“账本”（小写），用 L 表示，表示基础数据 由 DON 维护的结构，用于支持它提供的特定服务。 我们强调，我们的 DON 框架并不将 L 视为独立系统，例如 a blockchain：其目的是支持blockchains和其他系统。区块链是， 当然，这是实现可信账本的一种方法，但还有其他方法。我们期望 在许多情况下，DONs 使用拜占庭容错来实现其底层账本 (BFT) 系统，其大大早于 blockchain，例如 Bitcoin [174]。我们使用 为了方便起见，尽管我们在整篇论文中使用了 BFT 类型符号和属性 强调 DONs 可以使用无需许可的共识协议来实现。 从概念上讲，账本 L 是一个公告板，上面的数据是线性排序的。 我们通常认为分类账具有一些通常归因于的关键属性 blockchains [115]。账本是： • 仅附加： 数据一旦添加就无法删除或修改。• 公共： 任何人都可以阅读其内容，这些内容在时间上是一致的 所有用户的视图.4 • 可用：账本始终可以由授权写入者写入和读取 任何人及时。 当由 DON 实现时，分类帐中可能存在替代属性 委员会。例如，分类账写访问可能仅限于某些用户，如 可能会读取某些应用程序的访问权限，即分类帐不需要按照定义公开 上面。同样，分类账规则可能允许修改或编辑数据。我们不 然而，本文明确考虑了此类变体。 DONs 的模块化设计可以支持任何多种现代 BFT 协议，例如 Hotstuff[231]。确切的选择将取决于信任假设和 oracle 节点之间的网络特征。原则上 DON 也可以 使用高性能的无许可 blockchain 为其分类帐提供支持 同样可扩展的第 2 层或 blockchain 系统。同样，杂交也是可能的： DON 原则上可以由现有节点中的 validator 节点组成。 blockchain，例如，在选择委员会执行的权益证明系统中 交易，例如 [8, 81, 120, 146, 204]。这种特殊的操作模式要求 节点以双重用途方式运行，即既作为 blockchain 节点又作为 DON 运行 节点。 （参见第 8.2 节，了解确保变革连续性的技术讨论 委员会和附录 F 有关随机委员会选择的一些注意事项。） 实际上，在现代 BFT 算法中，节点对账本上的消息进行数字签名。 为了方便起见，我们假设 L 有一个关联的公钥 pkL 并且其内容 由相应的私钥签名。即使当 L 上的数据使用门限签名进行签名。5 门限签名很方便， 因为即使会员资格发生变化，它们也可以为 DON 提供持久的身份 运行它的节点。 （参见附录 B.1.3。）因此我们假设 skL 是秘密共享的 对于某些安全参数 k，以 (k, n) 阈值方式，例如 k = 2f + 1 且 n = 3f + 1，其中 f 是潜在故障节点的数量。 （通过在此选择 k 这样，我们确保故障节点既无法学习 skL，也无法发起拒绝服务攻击 攻击阻止其使用。） L 上的消息采用 M = (m, z) 的形式，其中 m 是字符串，z 是唯一的 顺序索引号。 在适用的情况下，我们以 m = 的形式编写消息 ⟨消息类型：有效负载⟩。消息类型MessageType是指示特定消息的功能的语法糖。 4在没有最终性的 blockchain 实现账本的情况下，通常会抽象出不一致性 通过忽略深度不足的块或“修剪”[115] 来消除。 5在实践中，一些代码库，例如 LibraBFT [205]（Hotstuff 的一个变体）目前已采用 多重签名，而不是阈值签名，以降低通信复杂性为代价 更简单的工程。通过一些额外的成本，oracle 节点可以将阈值签名附加到消息中 写入 L，即使用于 L 的共识协议不使用它们。2.3 符号 我们将运行账本的 n 个 oracle 节点集表示为 O = {Oi}n 我=1。 这样一个 节点集通常称为委员会。为了简单起见，我们假设集合 oracles 实现 DON 功能，即 L 之上的服务，与 保持 L，但它们可以是不同的。我们让 pki 表示公钥 玩家Oi，并ski相应的私钥。 大多数 BFT 算法至少需要 n = 3f + 1 个节点，其中 f 是节点数 潜在的故障节点；其余节点是诚实的，因为它们遵循 协议完全按照规定。如果委员会 O 符合此要求，我们称其为诚实的 要求，即诚实节点的比例大于 2/3。除非另有说明 如上所述，我们假设 O 是诚实的（并且是腐败的静态模型）。我们使用 pkO / skO 与 pkL / skL 可以互换，具体取决于上下文。 我们让 σ = Sigpk[m] 表示消息 m 相对于 pk 的签名，即使用 对应的私钥sk.令 verify(pk, σ, m) →{false, true} 表示相应的签名验证算法。 （我们在整篇论文中都隐含了密钥生成。） 我们使用符号 S 来表示数据源，并使用 S 来表示完整的数据集 给定上下文中的 nS 源。我们用 MAINCHAIN 表示启用了智能合约的 blockchain 由 DON 支持。我们使用术语依赖合约来表示任何智能合约 与 DON 通信的主链上的合约，并使用符号 SC 来 表示这样的合同。 我们通常假设 DON 支持单个主链 MAINCHAIN，尽管它可以支持多个这样的链，如我们在第 4 节的示例中所示。 DON 可以并且通常会支持主链上的多个依赖合约。 （如 如上所述，DON 也可以支持非 blockchain 服务。） 2.4 关于信任模型的说明 如上所述，DONs 可以构建在基于委员会的共识协议之上，并且我们 预计他们会普遍使用此类协议。有许多有力的论据表明 两种选择之一（基于委员会的或无需许可的 blockchains）提供 比其他的安全性更强。 重要的是要认识到基于委员会与未经许可的安全性 去中心化系统是不可通约的。危害 PoW 或 PoS blockchain 通过 51% 攻击，要求对手暂时获得多数资源，并且 可能是匿名的，例如通过在 PoW 系统中租用 hash 电力。这样的 实践中的攻击已经影响了几个 blockchain [200, 34]。相比之下， 损害基于委员会的系统意味着破坏其阈值数量（通常是三分之一）的节点，其中节点可能是公开的、资源丰富的、 和值得信赖的实体。 另一方面，基于委员会的系统（以及“混合”未经许可的系统） 支持委员会的系统）可以支持比严格要求更多的功能无任务系统。这包括维护持久秘密的能力，例如 签名和/或加密密钥——我们设计中的一种可能性。 我们强调 DON 原则上可以建立在基于委员会或 无许可共识协议和 DON 部署者最终可能选择采用 任一方法。 支持信任模型： 如今 Chainlink 的一个关键功能是用户能够 如所讨论的，根据节点性能历史记录的分散记录来选择节点 在第 3.6.4 节中。我们在第 9 节中介绍的 staking 机制和隐性激励框架共同构成了范围广泛且严格的机制设计 该框架将使用户能够极大地扩展衡量 DONs 安全性的能力。同样的框架也将使 DONs 本身成为可能 对参与节点执行各种安全要求并确保运行 在强大的信任模型中。 还可以使用本文中为 DON 描述的工具来强制实施特殊的信任模型要求，例如遵守监管要求。对于 例如，使用第 4.3 节中讨论的技术，节点可以提供以下证据： 节点运营商特征，例如运营区域，可用于帮助 强制遵守《通用数据保护条例》(GDPR) 第 3 条（“领土范围”）[105] 等规定。否则，这种合规性可能会对 在去中心化系统[45]中见面。 此外，在第 7 节中，我们讨论了加强 DONs 稳健性的计划 通过他们支持的主链上的信任最小化机制。
نموذج الأمن والأهداف
تعد شبكة Oracle اللامركزية نظامًا موزعًا متميزًا نتوقع حدوثه في البداية يتم تنفيذها بشكل نموذجي - وإن لم يكن بالضرورة - من خلال لجنة قائمة على أساسها بروتوكول الإجماع ويتم تشغيله بواسطة مجموعة من العقد oracle. تم تصميم DON بشكل أساسي لزيادة إمكانيات smart contract على السلسلة الرئيسية باستخدام تقارير oracle وغيرها من الخدمات، ولكن يمكنها توفير نفس خدمات الدعم لأنظمة أخرى غير blockchain، وبالتالي لا يلزم ربطها بسلسلة رئيسية معينة.
وبالتالي فإن النموذج والخصائص التي نعتبرها مستقلة إلى حد كبير عن استخدام التطبيقات الخاصة بـ DON. 2.1 النموذج المعماري الحالي من المهم التأكيد على أن Chainlink اليوم ليست خدمة متجانسة، بل بالأحرى إطار عمل غير مسموح به يمكن من خلاله إطلاق متميز ومستقل شبكات oracle العقد [77]. تحتوي الشبكات على مجموعات غير متجانسة من مشغلي العقد و التصاميم. وقد يختلفون أيضًا من حيث أنواع الخدمات التي يقدمونها، وهو ما قد يختلف أيضًا تشمل، على سبيل المثال، خلاصات البيانات، وإثبات الاحتياطيات، والعشوائية القابلة للتحقق، وما إلى ذلك. أخرى يمكن أن تشمل الاختلافات درجة اللامركزية وحجم الشبكة من حيث القيمة المقفلة التي يدعمها، ومعلمات مستوى الخدمة المختلفة، مثل تردد البيانات والدقة. يشجع نموذج Chainlink غير المسموح به على نمو النظام البيئي الذي يتخصص مقدمو الخدمة في الخدمات التي هم أكثر قدرة على تقديمها للمجتمع. هذا من المرجح أن يؤدي النموذج إلى تكاليف أقل للمستخدمين وجودة خدمة أعلى من النموذج يتطلب ذلك من جميع العقد والشبكات توفير مجموعة كاملة من الخدمات، وهذا النهج والتي يمكن أن تتحول بسهولة إلى اعتماد على مستوى النظام للخدمات التي تمثل الأقل القاسم المشترك للموارد المتاحة للعقد. مع تطور Chainlink نحو التصميمات المستندة إلى DON في Chainlink 2.0، فإننا نواصل دعم نموذج الإطار المفتوح غير المسموح به، مع مراعاة هدف تزويد المستخدمين بمجموعة من خيارات الخدمة التي تؤدي عالميًا إلى أفضل تطابق مع متطلبات التطبيق الخاصة. 2.2 افتراضات الإجماع نحن نستخدم مصطلح شبكة أوراكل اللامركزية ليشمل الوظائف الكاملة لـ نظام oracle الذي نصفه: كل من بنية البيانات التي تحافظ عليها عقد oracle و واجهة برمجة التطبيقات الأساسية موجودة فوقها. نحن نستخدم مصطلح دفتر الأستاذ (الأحرف الصغيرة)، الذي يُشار إليه بالحرف L، للإشارة إلى البيانات الأساسية البنية التي يحتفظ بها DON وتستخدم لدعم الخدمات المحددة التي تقدمها. نؤكد على أن إطار عملنا DON لا يتعامل مع L كنظام قائم بذاته أ blockchain: الغرض منه هو دعم blockchains والأنظمة الأخرى. بلوكتشين هي، وبطبيعة الحال، هذه إحدى الطرق لتحقيق دفتر أستاذ جدير بالثقة، ولكن هناك طرق أخرى. نحن نتوقع DONs في كثير من الحالات لتحقيق دفاتر الأستاذ الأساسية الخاصة بهم باستخدام Byzantine Fault Tolerant (BFT) الأنظمة، التي تسبق إلى حد كبير blockchain مثل Bitcoin [174]. نحن نستخدم BFT - اكتب التدوين والخصائص في جميع أنحاء الورقة للراحة، على الرغم من أننا أكد على أنه يمكن تحقيق DONs باستخدام بروتوكولات الإجماع غير المسموح بها. من الناحية النظرية، دفتر الأستاذ L عبارة عن لوحة إعلانات يتم ترتيب البيانات عليها خطيًا. نحن ننظر إلى دفتر الأستاذ بشكل عام على أنه يحتوي على بعض الخصائص الأساسية التي تُنسب إليه عادةً blockchains [115]. دفتر الأستاذ هو: • إلحاق فقط: البيانات، بمجرد إضافتها، لا يمكن إزالتها أو تعديلها.• عامة: يمكن لأي شخص قراءة محتوياته، والتي تكون متسقة عبر الزمن في عرض لجميع المستخدمين.4 • متاح: يمكن دائمًا كتابة دفتر الأستاذ بواسطة كتاب معتمدين وقراءته من قبل أي شخص في الوقت المناسب. الخصائص البديلة ممكنة في دفتر الأستاذ لـ DON عند تحقيقها بواسطة a اللجنة. على سبيل المثال، قد يقتصر الوصول إلى الكتابة في دفتر الأستاذ على مستخدمين معينين، مثل قد يكون الوصول للقراءة لبعض التطبيقات، أي أنه لا يلزم أن يكون دفتر الأستاذ عامًا كما هو محدد أعلاه. وبالمثل، قد تسمح قواعد دفتر الأستاذ بتعديل البيانات أو تنقيحها. نحن لا نفعل ذلك ومع ذلك، فكر صراحةً في مثل هذه المتغيرات في هذه الورقة. يمكن للتصميم المعياري لـ DONs أن يدعم أيًا من مجموعة واسعة من BFT الحديثة protocols, e.g., Hotstuff[231]. سيعتمد الاختيار الدقيق على افتراضات الثقة و خصائص الشبكة بين العقد oracle. يمكن لـ DON من حيث المبدأ أن يكون بديلاً استخدم blockchain عالي الأداء بدون إذن لدفتر الأستاذ الخاص به في دوره الداعم طبقة 2 قابلة للتطوير بشكل متساوٍ أو نظام blockchain. وبالمثل، فإن التهجين ممكن أيضًا: يمكن أن يتكون DON من حيث المبدأ من العقد التي هي validators في موجودة blockchain، على سبيل المثال، في أنظمة إثبات الملكية التي يتم فيها اختيار اللجان للتنفيذ المعاملات، على سبيل المثال، [8، 81، 120، 146، 204]. يتطلب وضع التشغيل هذا ذلك تعمل العقد بطريقة الاستخدام المزدوج، أي تعمل كعقد blockchain و DON العقد. (انظر القسم 8.2 لمناقشة التقنيات لضمان الاستمرارية في التغيير اللجان والملحق و لبعض المحاذير بشأن الاختيار العشوائي للجنة.) من الناحية العملية، في خوارزميات BFT الحديثة، تقوم العقد بتوقيع الرسائل رقميًا على دفتر الأستاذ. نحن نفترض من أجل الراحة أن L لديه مفتاح عام مرتبط pkL وأن محتوياته يتم توقيعها بواسطة المفتاح الخاص المقابل. ينطبق هذا التدوين العام حتى عندما يتم توقيع البيانات الموجودة على L باستخدام توقيعات العتبة.5 تعتبر توقيعات العتبة ملائمة، لأنها تتيح هوية ثابتة لـ DON حتى مع تغييرات العضوية العقد التي تعمل عليه. (انظر الملحق ب.1.3.) وبالتالي فإننا نفترض أن skL مشترك بشكل سري بطريقة العتبة (k, n) لبعض معلمات الأمان k، على سبيل المثال، k = 2f + 1 و n = 3f + 1، حيث f هو عدد العقد التي يحتمل أن تكون معيبة. (باختيار k في هذا بهذه الطريقة، نحن نضمن أن العقد المعيبة لا يمكنها تعلم skL ولا تؤدي إلى رفض الخدمة هجوم يمنع استخدامه.) تأخذ الرسالة على L الشكل M = (m, z)، حيث m عبارة عن سلسلة وz فريدة رقم الفهرس التسلسلي. حيثما ينطبق ذلك، نكتب الرسائل في النموذج م = ⟨نوع الرسالة: الحمولة⟩. نوع الرسالة messageType هو السكر النحوي الذي يشير إلى وظيفة رسالة معينة. 4في الحالات التي يحقق فيها blockchain بدون نهائية دفتر الأستاذ، يتم عادةً تجريد التناقض بعيدًا عن طريق تجاهل الكتل العميقة غير الكافية أو "التقليم" [115]. 5In practice, some code bases, e.g., LibraBFT [205], a variant of Hotstuff, have currently adopted التوقيعات المتعددة، بدلاً من توقيعات العتبة، أدى التداول إلى تقليل تعقيد الاتصال هندسة أبسط. مع بعض التكلفة الإضافية، يمكن للعقد oracle إلحاق الحد الأدنى من التوقيعات بالرسائل مكتوبة إلى L حتى لو كان بروتوكول الإجماع المستخدم لـ L لا يستخدمها.2.3 التدوين نشير إلى مجموعة n oracle العقد التي تقوم بتشغيل دفتر الأستاذ بواسطة O = {Oi}n أنا = 1. مثل هذا غالبًا ما تسمى مجموعة العقد باللجنة. للتبسيط، نفترض أن مجموعة oracles التي تنفذ وظيفة DON، أي الخدمات الموجودة أعلى L، متطابقة مع أن الحفاظ على L، ولكن يمكن أن تكون متميزة. نسمح لـ pki بالإشارة إلى المفتاح العام لـ لاعب Oi، والتزلج على المفتاح الخاص المقابل. تتطلب معظم خوارزميات BFT ما لا يقل عن n = 3f + 1 عقد، حيث f هو عدد العقد العقد التي يحتمل أن تكون معيبة. العقد المتبقية صادقة، بمعنى أنها تتبع البروتوكول بالضبط كما هو محدد. ونشير إلى اللجنة يا صادقة إذا استوفت ذلك المتطلبات، أي أن لديها أكثر من 2/3 جزء من العقد الصادقة. ما لم يكن خلاف ذلك ذكرنا، نفترض أن يا صادق (ونموذج ثابت للفساد). نستخدم pkO/ skO بالتبادل مع pkL / skL، اعتمادا على السياق. ندع σ = Sigpk[m] تشير إلى التوقيع على الرسالة m فيما يتعلق بـ pk، أي باستخدام المفتاح الخاص المقابل sk. دع التحقق (pk، σ، m) → {false، true} يشير إلى خوارزمية التحقق من التوقيع المقابلة. (نترك الجيل الرئيسي ضمنيًا في جميع أنحاء الورقة.) نستخدم الرمز S للإشارة إلى مصدر البيانات وS للإشارة إلى المجموعة الكاملة مصادر nS في سياق معين. نشير بواسطة MAINCHAIN إلى تمكين العقد الذكي blockchain مدعوم بـ DON. نستخدم مصطلح عقد الاعتماد للدلالة على أي عقد ذكي عقد على MAINCHAIN الذي يتصل بـ DON، واستخدم الرمز SC لـ تشير إلى مثل هذا العقد. نحن نفترض بشكل عام أن DON يدعم سلسلة رئيسية واحدة MAINCHAIN، على الرغم من أنه يمكن أن يدعم العديد من هذه السلاسل، كما نوضح في الأمثلة في القسم 4. يمكن لـ DON أن يدعم عادةً عقودًا متعددة الاعتماد على MAINCHAIN. (كما كما هو مذكور أعلاه، يمكن أن يدعم DON بدلاً من ذلك الخدمات غير blockchain.) 2.4 ملاحظة حول نماذج الثقة كما هو مذكور أعلاه، قد يتم إنشاء DONs فوق بروتوكولات الإجماع القائمة على اللجنة، ونحن نتوقع أنهم سيستخدمون مثل هذه البروتوكولات بشكل شائع. هناك العديد من الحجج القوية التي يوفر أحد البديلين، القائم على اللجنة أو غير المسموح به blockchains أمان أقوى من الآخر. من المهم أن ندرك أن الأمن يعتمد على اللجنة مقابل عدم الإذن الأنظمة اللامركزية غير قابلة للقياس. المساس بإثبات العمل (PoW) أو إثبات الحصة (PoS) blockchain يتطلب الهجوم بنسبة 51% أن يحصل الخصم على أغلبية الموارد بشكل سريع الزوال و من المحتمل أن يكون مجهول الهوية، على سبيل المثال عن طريق استئجار hash الطاقة في نظام إثبات العمل (PoW). مثل هذا لقد أثرت الهجمات عمليًا بالفعل على العديد من blockchains [200، 34]. في المقابل، إن المساس بالنظام القائم على اللجان يعني إفساد عدد العتبة (عادة الثلث) من عقده، حيث قد تكون العقد معروفة للعامة، ومزودة بموارد جيدة، والجهات الجديرة بالثقة. ومن ناحية أخرى، فإن الأنظمة القائمة على اللجان (وكذلك الأنظمة "الهجينة" غير مسموح بها الأنظمة التي تدعم اللجان) يمكن أن تدعم وظائف أكثر مما هو مطلوب بشكل صارمأنظمة بلا مهمة. يتضمن ذلك القدرة على الحفاظ على الأسرار المستمرة، مثل التوقيع و/أو مفاتيح التشفير — أحد الاحتمالات في تصميماتنا. نؤكد على أنه يمكن من حيث المبدأ بناء DONs على مستوى اللجنة أو قد يختار بروتوكول الإجماع غير المسموح به وموزعي DON في النهاية اعتماده إما النهج. نماذج تعزيز الثقة: إحدى الميزات الرئيسية لـ Chainlink اليوم هي قدرة المستخدمين على ذلك حدد العقد بناءً على السجلات اللامركزية لسجلات أدائها، كما تمت مناقشته في القسم 3.6.4. تشكل آلية staking وإطار الحوافز الضمنية الذي نقدمه في القسم 9 معًا تصميمًا صارمًا وواسع النطاق للآلية إطار عمل من شأنه تمكين المستخدمين بقدرة موسعة بشكل كبير على قياس أمان DONs. هذا الإطار نفسه سيجعل من الممكن أيضًا لـ DONs أنفسهم لفرض متطلبات الأمان المختلفة على العقد المشاركة وضمان التشغيل ضمن نماذج الثقة القوية. من الممكن أيضًا استخدام الأدوات الموضحة في هذا البحث لـ DONs لفرض متطلبات نموذج الثقة الخاصة، مثل الامتثال للمتطلبات التنظيمية. ل على سبيل المثال، باستخدام التقنيات التي تمت مناقشتها في القسم 4.3، يمكن للعقد تقديم دليل على ذلك خصائص مشغل العقدة، على سبيل المثال، منطقة التشغيل، التي يمكن استخدامها للمساعدة فرض الامتثال، على سبيل المثال، المادة 3 من اللائحة العامة لحماية البيانات (GDPR) ("النطاق الإقليمي") [105]. قد يكون مثل هذا الامتثال أمرًا صعبًا يجتمع في الأنظمة اللامركزية [45]. بالإضافة إلى ذلك، نناقش في القسم 7 خططًا لتعزيز قوة DONs من خلال آليات تقليل الثقة في السلاسل الرئيسية التي يدعمونها.
去中心化的 Oracle 网络接口和 Ca-
能力 在这里，我们简单地描述了 DONs 的功能，简单但强大 它们旨在实现的接口。 DON 上的应用程序由可执行文件和适配器组成。可执行文件是 其核心逻辑是确定性程序的程序，类似于 smart contract。 可执行文件还具有许多附带的启动程序，即调用入口的程序 当预定事件发生时（例如，在某些时间），可执行文件逻辑中的点 （就像 cron 作业），当价格超过阈值时，等等——很像 Keepers（参见第 3.6.3 节）。适配器提供链下资源的接口，可以被调用 可执行文件中的发起者或核心逻辑。因为他们的行为可能取决于此 外部资源、启动器和适配器的行为可能是不确定的。 我们描述了 DON 开发者界面以及可执行文件的功能和 适配器通常用于表征计算系统的三种资源：网络、计算和存储。我们对其中每一个进行简要概述 以下资源并在附录 B 中提供更多详细信息。
3.1 网络 适配器是在 DON 上运行的可执行文件可以通过其发送和接收信息的接口。 从off-DON系统接收数据。适配器可以被视为泛化 今天 Chainlink 使用的适配器 [20]。适配器可以是双向的，即它们 不能只是从 DON 拉取数据，而是将数据推送到 Web 服务器。他们还可以利用 分布式协议以及加密功能，例如安全多方 计算。 图 9：适配器连接 DON（表示为 DON1）与一系列不同的资源，包括另一个 DON（表示为 DON2）、一条 blockchain（主链）及其 mempool、外部存储、Web 服务器和 IoT 设备（通过 Web 服务器）。 显示了可以为其创建适配器的外部资源的示例 如图 9 所示。它们包括： • 区块链：适配器可以定义如何将交易发送到 blockchain 并 如何从中读取区块、单个交易或其他状态。适配器一个 也可以为 blockchain 的内存池定义。 （参见第 3.5 节。） • Web 服务器：适配器可以定义可检索数据的 API 来自网络服务器，包括不专门适应的遗留系统 与 DONs 连接。此类适配器还可以包含用于将数据发送到的 API 这样的服务器。 DON 连接的 Web 服务器可以充当网关 其他资源，例如物联网 (IoT) 设备。• 外部存储：适配器可以定义读取和写入存储的方法 DON 之外的服务，例如去中心化文件系统 [40, 188] 或云 存储。 • 其他DON：适配器可以在DON 之间检索和传输数据。 我们预计 DONs 的初始部署将包括一组构建块 此类常用外部资源的适配器，并将进一步允许 DON 特定的 由 DON 节点发布的适配器。作为 smart contract 开发人员编写适配器 今天，我们预计他们将使用这种先进的技术构建更强大的适配器 功能。 我们期望用户最终能够在一个新的适配器中创建新的适配器。 未经许可的方式。 某些适配器的构造方式必须确保由 DON 控制的外部资源的持久性和可用性。例如，云存储可以 需要维护云服务帐户。此外，DON 可以执行 代表用户对私钥进行去中心化管理（例如 [160]）和/或 可执行文件。因此，DON能够控制可用于例如在目标blockchain上发送交易的资源，例如加密货币。 有关 DON 适配器的更多详细信息，请参阅附录 B.1，一些适配器的详细信息请参阅附录 C。 示例适配器。 3.2 计算 可执行文件是 DON 上的基本代码单元。可执行文件是一对 exec = （逻辑，初始化）。这里，逻辑是一个具有多个指定入口的确定性程序 点 (logic1,logic2,...,logicℓ) 和 init 是一组相应的启动器 （初始化1、初始化2、……、初始化）。确保可执行文件逻辑 DON 的完全可审计性 使用底层账本 L 来处理所有输入和输出。因此，例如，任何适配器 作为可执行文件输入的数据必须首先存储在 L 上。 发起人： 今天 Chainlink 中的启动器会导致事件相关的作业执行 Chainlink 节点 [21]。 DONs 中的启动器的功能大致相同。然而，DON 启动器与可执行文件特定关联。发起者可能取决于 基于外部事件或状态、当前时间或 DON 状态的谓词。 由于对事件的依赖，发起者的行为当然可能是不确定的 （当然也可以是适配器）。启动器可以在各个 DON 节点内执行 因此不需要依赖适配器。 （参见下面的示例 1。） 启动器是区分可执行文件和 smart contract 的一个重要特征。 因为可执行文件可以响应启动器而运行，所以它可以有效地操作 自主地，当然通过扩展可以包含可执行文件的混合合同。如今发起者的一种形式是 Chainlink 守护者，它提供交易自动化服务，根据 oracle 报告触发 smart contract 执行，例如清算抵押不足的贷款和执行限价订单交易。 方便地，DONs 中的启动器也可以被视为指定 适用于可执行文件的服务协议，因为它们定义了以下情况 DON 必须调用它。 以下示例说明启动器如何在可执行文件中工作： 示例 1（偏差触发的喂价）。 smart contract SC 可能需要新鲜的 每当价格发生重大变化（例如 1%）时，喂价数据（参见第 3.6.3 节） 一对资产之间的汇率，例如 ETH-USD。波动敏感的价格 今天 Chainlink 支持提要，但了解它们如何实现是有启发性的 通过可执行的 execfeed 在 DON 上实现。 可执行文件 execfeed 在 L 上维护最新的 ETH-USD 价格 r，在 ⟨NewPrice : j, r⟩entries 序列的形式，其中 j 是递增的索引 每次价格更新。 发起者 init1 使每个节点 Oi 监控当前 ETH-USD 价格 与索引 j 的最近存储的价格 r 的偏差至少为 1%。之上 检测到这种偏差，Oi 将新价格的当前视图 ri 写入 L 使用 ⟨PriceView : i, j + 1, ri⟩ 形式的条目。 当至少 k 个这样的 PriceView 条目具有新价格时，第二个启动器 init2 就会触发 由不同节点创建的索引 j + 1 的值已累积在 L 上。然后，init2 调用入口点逻辑 2 来计算前 k 个新的有效价格视图值的中位数 ρ 并将新值 ⟨NewPrice : j + 1, ρ⟩ 写入 L 。 （操作上，节点 可以轮流担任指定撰稿人。） 第三个发起者 init3 监视 L 上的 NewPrice 条目。每当有新报告时 ⟨NewPrice : j, r⟩出现在那里，它调用一个入口点逻辑 3，将 (j, r) 推送到 SC 使用适配器。 正如我们所指出的，可执行文件的功能与 smart contract 类似。 然而，除了其更高的性能之外，它与典型的主链合约不同 以两种基本方式： 1. 机密性：可执行文件可以执行机密计算，即秘密程序可以处理明文输入，或者发布的程序可以处理 秘密输入数据，或两者的组合。在一个简单的模型中，秘密数据可以 由 DON 节点访问，隐藏中间结果并仅公开 处理和清理的值到主链。也可以从 DON 本身隐藏敏感数据：DON 旨在支持此类方法 作为多方计算，例如 [42, 157] 和可信执行环境 (TEE) [84, 133, 152, 229] 为此目的。6 6通过扩展，也可以对 DON 节点保持可执行文件本身的秘密， 尽管这在今天仅适用于使用 TEE 的重要可执行文件。2. 支持角色：可执行文件旨在支持主系统上的 smart contracts 链，而不是取代它们。可执行文件有几个限制： smart contract 不： (a) 信任模型：可执行文件在由 DON：其正确执行依赖于 O 的诚实行为。（主要 然而，链条可以提供一些防范 DON 渎职行为的防护措施，如 第 7.3 节中讨论。） (b) 资产访问：DON 可以控制 blockchain 上的帐户，因此 通过适配器控制其上的资产。但 DON 不能权威地 代表在主链上创建的资产，例如以太坊或 ERC20 tokens，因为 他们的本地链维护其所有权的权威记录。 (c) 生命周期：DONs 可能会故意以有限的生命周期建立起来，因为 由 DON 和所有者之间的链上服务水平协议定义 依赖合同。 相比之下，区块链的作用是 永久档案系统。 有关 DON 计算的更多详细信息，请参阅附录 B.2。 3.3 存储 作为基于委员会的系统，DON 可以持久存储适量的数据 在 L 上的成本比未经许可的 blockchain 低得多。此外，通过适配器， DONs 可以引用外部去中心化系统进行数据存储，例如 Filecoin [85]， 从而可以将此类系统连接到 smart contracts。这个选项特别 作为解决普遍存在的“膨胀”问题的一种手段，对大量数据很有吸引力 blockchain 系统。 因此，DONs 可以在本地或外部存储数据，以便在其特定支持的服务中使用。 DON 还可以以保密的方式使用此类数据， 计算以下数据：(1) 在 DON 节点之间秘密共享或在以下情况下加密 由 DON 节点以适合安全多方计算的方式管理的密钥 或部分或完全同态加密；或 (2) 使用可信执行进行保护 环境。 我们预计 DONs 将采用常见的简单内存管理模型 智能合约系统：可执行文件只能写入自己的内存。可执行文件 但是，可以从其他可执行文件的内存中读取。 有关 DON 存储的更多详细信息，请参阅附录 B.3。 3.4 交易执行框架 (TEF) DON 旨在支持主链 MAINCHAIN （或多个主链）上的合约。详细讨论事务执行框架 (TEF)第 6 节中的内容是有效执行合同的通用方法 SC 跨主链和 DON。 TEF 旨在支持 FSS 和第 2 层 技术——如果需要的话，可以同时进行。事实上，它很可能作为主要车辆 FSS 的使用（因此，我们在本节中不再进一步讨论 FSS）。 简而言之，在 TEF 中，有一个为 MAINCHAIN 设计或开发的原始目标合约 SC 被重构为混合合约。这种重构产生了两个互操作的 混合合约的组成部分：为了清楚起见，我们将其称为主链合约 SCa 在 TEF 的背景下，作为锚定合约和 DON 上的可执行执行程序。的 合约SCa托管用户的资产，执行权威的状态转换，还 提供防护栏（参见第 7.3 节）以防止 DON 中的故障。可执行的 exec 对交易进行排序并为其提供关联的 oracle 数据。可以捆绑 通过多种方式进行 SCa 交易——例如，使用基于有效性证明的或 乐观 rollups，由 DON 保密执行，等等。 我们希望开发出使开发人员能够轻松分割合约的工具 SC 用高级语言编写成 MAINCHAIN 和 DON 逻辑块，SCa 和 分别执行，安全高效地组合。 使用TEF将高性能交易方案与高性能相结合 oracles 是我们的 oracle 缩放方法的组成部分。 3.5 内存池服务 我们打算在 DON 上部署一项重要的应用程序层功能以提供支持 FSS 和 TEF 的核心是 Mempool Services（MS）。 MS 可以被视为一个适配器， 但拥有一流的支持。 MS 提供对传统兼容事务处理的支持。在此用途中，MS 从主链的内存池中摄取那些用于目标合约的交易 主链上的 SC。然后，MS 将这些事务传递给 DON 上的可执行文件， 它们以所需的方式进行处理。 MS 数据可由 DON 使用 组成交易，然后可以直接从 DON 传递到 SC 或 到另一个名为 SC 的合约。例如，DON可以转发交易 通过 MS 收集，或者它可以使用 MS 数据为其发送到的交易设置 Gas 价格 主链。 由于它监控内存池，MS 可以从直接与 SC 交互的用户获取交易。因此，用户可以继续使用以下方式生成交易 遗留软件，即不知道 MS 和 MS 配置的存在的应用程序 合同。 （在这种情况下，必须更改 SC 以忽略原始交易并 仅接受MS处理过的内容，以避免双重处理。） 为了与目标合同 SC 一起使用，MS 可以与 FSS 和/或 TEF 一起使用。3.6 垫脚石：现有 Chainlink 功能 3.6.1 链下报告（OCR） 链外报告 (OCR) [60] 是 Chainlink 中的一种机制，用于 oracle 报告聚合和传输到依赖合约 SC。最近以 Chainlink 价格部署 馈送网络，它代表了通往完整 DON 之路的第一步。 OCR 的核心是 BFT 协议，旨在以部分同步的方式运行 网络。它确保任意存在 f < n/3 时的活性和正确性 故障节点，保证了拜占庭可靠广播的特性，但事实并非如此 完整的 BFT 共识协议。节点不维护消息日志 一致的意思是代表一个在所有观点上都相同的账本， 协议的领导者可以在不违反安全的情况下含糊其辞。 OCR 目前是为特定消息类型设计的： 参与节点报告的（至少 2f +1）个值。它提供了关键保证 它为 SC 输出的报告称为经过验证的报告：经过验证的报告中的中值 报告等于或位于两个诚实节点报告的值之间。此属性是 OCR 的关键安全条件。领导者可能对中位数有一定影响 经证明的报告中的值，但仅受此正确性条件的限制。光学字符识别可以 可以扩展到以不同方式聚合值的消息类型。 虽然 Chainlink 网络今天的活跃度和正确性目标不需要 OCR 是一个成熟的共识协议，它们确实需要 OCR 提供传统 BFT 协议中不存在的一些附加形式的功能，最值得注意的是： 1. 全有或全无的链下报告广播：OCR 确保经过验证的报告 快速可供所有诚实节点使用，或者不可供任何节点使用。这是一种公平 有助于确保诚实节点有机会参与的属性 在经过验证的报告传输中。 2. 可靠传输：OCR 确保即使存在错误或恶意 节点，所有OCR报告和消息在一定时间内传输到SC， 预先定义的时间间隔。这是一个活跃的属性。 3. 基于合同的信任最小化：SC 过滤掉潜在错误的 OCR 生成的报告，例如，如果它们报告的值与其他值显着偏差 最近收到的。这是协议外正确性强制的一种形式。 所有这三个属性都将在 DONs 中发挥自然作用。全有或全无链下 (DON) 广播是加密经济保证的重要组成部分 围绕可靠的传输，这又是适配器的一个重要属性。信任 SC 中的最小化是一种护栏，如第 7.3 节所述。 OCR 还为 Chainlink 的 oracle 网络中的 BFT 协议的操作部署和细化提供了基础，因此，如上所述，这是一条通往完整的路径。 DONs 的功能。3.6.2 德科和城市公告员 DECO [234] 和 Town Crier [233] 是目前正在开发的一对相关技术 在 Chainlink 网络中开发。 如今，大多数 Web 服务器允许用户使用协议通过安全通道进行连接 称为传输层安全 (TLS) [94]。 （HTTPS 表示 HTTP 的一个变体， 启用了 TLS，即以“https”为前缀的 URL 表示使用 TLS 来确保安全。） 不过，大多数启用 TLS 的服务器都有一个显着的限制：它们不进行数字签名 数据。因此，用户或证明者无法呈现她从服务器接收的数据 向第三方或验证者，例如 oracle 或 smart contract，以确保 数据的真实性。 即使服务器对数据进行数字签名，仍然存在保密问题。证明者可能希望在将敏感数据呈现给证明者之前对其进行编辑或修改 验证者。然而，数字签名是专门为使修改后的数据失效而设计的。因此，它们阻止证明者进行保密性的更改 到数据。 （更多讨论请参见第 7.1 节。） DECO 和 Town Crier 旨在允许证明者从网络获取数据 服务器并以确保完整性和机密性的方式将其呈现给验证者。 这两个系统在确保数据呈现的意义上保持完整性 证明者到验证者确实源自目标服务器。他们支持 机密性是指允许证明者编辑或修改数据（同时仍然 保持完整性）。 这两个系统的一个关键特点是它们不需要对系统进行任何修改 目标网络服务器。它们可以与任何现有的启用 TLS 的服务器一起运行。事实上， 它们对服务器是透明的：从服务器的角度来看，证明者是 建立普通连接。 这两个系统具有相似的目标，但在信任模型和实现方面有所不同，正如我们现在简要解释的那样。 DECO 从根本上利用加密协议来实现其完整性 和保密性。在使用 DECO 与目标服务器建立会话时，证明者同时与目标服务器建立交互协议 验证者。该协议使证明者能够向验证者证明它已收到 在当前会话期间来自服务器的给定数据 D。证明者可以 或者向验证者提供 D 的某些属性的零知识证明 因此不直接揭示 D。 在 DECO 的典型使用中，用户或单个节点可以从私有节点导出数据 D。 与 Web 服务器的会话到 DON 中的所有节点。因此，完整的 DON 可以 证明 D 的真实性（或通过零知识证明从 D 导出的事实）。 除了本文后面给出的示例应用程序之外，此功能还可以 用于通过 DON 放大对数据源的高完整性访问。即使只有一个节点 可以直接访问数据源——例如，由于与 数据提供者——整个 DON 仍然有可能证明以下内容的正确性该节点发出的报告。 Town Crier 依赖于使用可信执行环境 (TEE)，例如 Intel 新交所。简而言之，TEE 的功能就像一种黑匣子，在特定环境中执行应用程序 防篡改和保密的方式。原则上，即使是主机的所有者 TEE 正在运行既不能（无法检测地）改变受 TEE 保护的应用程序，也不能 查看应用程序的状态，其中可能包括秘密数据。 Town Crier 可以实现 DECO 的所有功能以及更多功能。 DECO 将证明者限制为与单个验证者交互。相比之下，Town Crier 能够 证明者对从目标服务器获取的数据 D 生成可公开验证的证明， 即任何人，甚至 smart contract，都可以直接验证的证明。城镇公告员可以 还可以安全地获取和使用秘密（例如用户凭据）。 Town Crier 的主要限制是它对 TEE 的依赖。生产 TEE 具有 最近被证明存在许多严重的漏洞，尽管该技术还处于起步阶段，并且无疑会成熟。参见附录 B.2.1 和 B.2.2 TEE 的进一步讨论。 有关 DECO 和 Town Crier 的一些示例应用程序，请参阅第 4.3、4.5 节 9.4.3 和附录 C.1。 3.6.3 现有链上 Chainlink 服务 Chainlink oracle 网络提供多种主要服务 blockchains 和当今的其他去中心化系统。 如所描述的进一步演变 在本白皮书中，将赋予这些现有服务额外的功能和 达到。三个例子是： 数据源： 今天，大多数 Chainlink 用户依赖 smart contracts 使用数据源。这些是根据关键数据的当前价值的报告 权威的链下来源。例如，价格源是报告价格的源 资产——加密货币、商品、外汇、指数、股票等——根据 交换或数据聚合服务。如今，此类信息流已经帮助确保了数十亿美元的安全 通过在 DeFi 系统（如 Aave [147] 和）中使用美元来实现链上价值 Synthetix [208]。 Chainlink 数据源的其他示例包括以下天气数据 参数农作物保险 [75] 和选举数据 [93] 等。 本文中描述的 DON 和其他技术的部署将以多种方式增强 Chainlink 网络中数据馈送的提供，包括： • 扩展：OCR 和随后的 DON 旨在使 Chainlink 服务能够扩展 他们支持的许多 blockchain 都具有显着的差异。例如，我们期望 DONs 将有助于增加节点提供的数据馈送数量 Chainlink 从 100 到 1000 甚至更长。这种缩放将有助于 Chainlink 生态系统实现了全面提供与 smart contract 相关的数据并满足和预测现有和未来需求的目标。• 增强安全性：通过存储中间报告，DONs 将保留记录 节点行为的高保真监控和测量其性能和准确性，为声誉系统提供强有力的经验基础 对于 Chainlink 节点。 FSS 和 TEF 将纳入价格反馈 以灵活的方式处理交易数据，防止抢先交易等攻击。 （明确）staking 将加强现有的加密经济安全保护 数据源。 • 馈送敏捷性：作为与 blockchain 无关的系统（实际上，更广泛地说，与消费者无关的系统），DON 可以促进向多重性提供数据馈送 依赖系统。单个 DON 可以将给定的 feed 同时推送到一组 不同的 blockchain ，消除了对每链 oracle 网络的需求， 能够在新的 blockchain 和其他设备上快速部署现有源 为当前服务的 blockchain 提供数据。 • 保密性：在 DON 中执行广义计算的能力使得敏感数据的计算能够在链外进行，避免在链上进行 曝光。 此外，使用 DECO 或 Town Crier，可以实现 更强的保密性，允许基于非公开数据生成报告 甚至暴露于 DON 节点。示例请参见第 4.3 节和第 4.5 节。 可验证随机函数（VRF）： 几种类型的 DApp 需要可验证的正确随机源，以验证其自身的公平运行。 不可替代代币 (NFTs) 就是一个例子。 Aavegotchi [23] 和 Axie Infinity [35] 中 NFT 特征的稀有度由 Chainlink VRF 决定，分布也是如此 通过以太卡 [102] 中基于票证的抽奖方式获得 NFT 份；种类繁多的 结果随机的游戏 DApp；以及非常规金融工具，例如 PoolTogether [89] 等无损储蓄游戏，它将资金分配给 随机获胜者。其他 blockchain 和非 blockchain 应用程序也需要安全 随机性的来源，包括去中心化系统委员会的选择和 彩票的执行。 虽然区块 hashes 可以作为不可预测的随机性来源，但它们很容易受到敌对矿工的操纵（在某种程度上，用户提交 交易）。 Chainlink VRF [78] 提供了一种更安全的替代方案。安 oracle 有一个关联的私钥/公钥对（sk，pk），其私钥在链外维护，其公钥 pk 已发布。为了输出一个随机值，它 将 sk 应用于由依赖合约提供的不可预测的种子 x（例如，区块 hash 和 DApp 特定参数）使用函数 F，产生 y = Fsk(x) 以及 正确性证明。 （有关 Chainlink 上提供的 VRF，请参阅 [180]。） VRF 可验证的事实是，有了 pk 的知识，就可以检查证明的正确性，从而检查 y 的正确性。因此，y 值对于 对手无法预测 x 或学习 sk 并且服务无法操纵。Chainlink VRF 可能被视为涉及链下私钥托管的一系列应用程序之一。更一般地说，DONs 可以提供安全、 应用程序和/或用户的单个密钥的分散存储，并结合 这种能力具有广义计算。结果是大量的应用程序， 我们在本文中给出了一些示例，包括证明的密钥管理 储备金（参见第 4.1 节）和用户的去中心化凭证（以及其他数字 资产）（参见第 4.3 节）。 饲养员： Chainlink Keepers [87] 使开发人员能够为去中心化编写代码 链外作业的执行，通常会触发依赖smart contracts的执行。 在 Keepers 出现之前，开发者进行此类链下操作是很常见的 逻辑本身，造成集中的故障点（以及大量的重复开发工作）。相反，Keeper 提供了一个易于使用的框架 这些业务的分散外包，缩短了开发周期 活性和其他安全属性的有力保证。守护者可以支持任何 各种各样的触发目标，包括依赖于价格的贷款清算或 金融交易的执行、空投或付款的时间依赖启动 在具有产量收获的系统中，等等。 在 DON 框架中，发起者可以被视为多种意义上的守护者的概括。发起者可以使用适配器，因此可以利用 链上和链下系统的模块化接口库，允许快速 开发安全、复杂的功能。发起者发起计算 可执行文件，它们本身提供 DON 的全部多功能性，允许广泛的 我们在本文中为链上和链下应用程序提供了一系列去中心化服务。 3.6.4 节点声誉/性能历史记录 现有的 Chainlink 生态系统本身记录了性能历史记录 链上贡献节点。这一功能催生了一系列以声誉为导向的资源，这些资源可以摄取、过滤和可视化个人的绩效数据。 节点操作员和数据源。用户可以参考这些资源来获取信息 决定节点选择并监控现有网络的运行。 类似的功能将帮助用户选择DONs。 例如，当今的无许可市场（例如 market.link）允许节点 运营商列出他们的 oracle 服务并通过以下方式证明他们的链外身份 诸如 Keybase [4] 之类的服务，它将 Chainlink 中的节点的配置文件绑定到其 所有者现有的域名和社交媒体帐户。此外，性能 分析工具，例如 market.link 和reputation.link 上提供的工具，允许 用户可以查看各个节点的历史性能统计数据，包括其 平均响应延迟，报告中的值与共识值的偏差 在链上传递、产生收入、实现就业等等。这些分析工具还 允许用户跟踪其他用户对各种 oracle 网络的采用情况，这是一种形式保护此类网络的节点的隐式认可。结果是一个扁平的“网络” 信任”，其中通过使用特定节点，高价值的去中心化应用程序创建 他们对这些节点的信任信号，其他用户可以观察并纳入他们的考虑因素 自己的节点选择决策。 随着 DONs（最初是 OCR）带来了交易处理和 合同活动更普遍地是链下的。记录节点的去中心化模型 DON 本身的性能仍然是可能的。确实，高性能 DONs 的数据容量使得以细粒度构造记录成为可能 方式，并对这些记录执行去中心化计算，产生可信的摘要，可供信誉服务使用并在其上设置检查点 主链。 虽然原则上 DON 有可能在大部分节点损坏的情况下歪曲组成节点的行为，但我们注意到集体 DON 本身在传递链上数据方面的性能在主链上可见 因此不能被歪曲。此外，我们计划探索以下机制： 激励 DON 中节点行为的准确内部报告。例如，通过报告最快返回数据贡献的高性能节点的子集 对于链上转发的报告，DON 会激励节点对不正确的内容提出异议 报告：错误地在此子集中包含节点意味着错误地排除节点 这应该被包括在内，因此对他们的惩罚是无效的。 DON 重复报告失败也会激励诚实节点离开 DON。 准确的绩效历史记录和后续结果的分散编制 用户识别高性能节点以及节点运营商构建的能力 声誉是 Chainlink 生态系统的重要区别特征。 我们 第 9 节展示了我们如何将它们推理为严格且可靠的模型的关键部分。 对 DONs 提供的经济安全的广阔视野。
واجهة شبكة أوراكل اللامركزية وCa-
القدرات نحن هنا نرسم بإيجاز قدرات DONs من حيث البساطة ولكن القوية الواجهة التي تم تصميمها لتحقيقها. تتكون التطبيقات الموجودة على DON من ملفات تنفيذية ومحولات. الملف القابل للتنفيذ هو برنامج منطقه الأساسي هو برنامج حتمي، مشابه لـ smart contract. يحتوي الملف القابل للتنفيذ أيضًا على عدد من البادئين المصاحبين، وهي البرامج التي تستدعي الدخول نقاط في منطق الملف القابل للتنفيذ عند وقوع أحداث محددة مسبقًا، على سبيل المثال، في أوقات معينة (مثل وظيفة كرون)، عندما يتجاوز السعر الحد الأدنى، وما إلى ذلك - يشبه إلى حد كبير الحراس (انظر القسم 3.6.3). توفر المحولات واجهات للموارد خارج السلسلة ويمكن استدعاؤها بواسطة إما البادئين أو المنطق الأساسي في الملفات التنفيذية. لأن سلوكهم قد يعتمد على ذلك من الموارد الخارجية، قد يتصرف البادئون والمحولون بطريقة غير حتمية. نحن نصف واجهة المطور DON وعمل الملفات التنفيذية و المحولات من حيث الموارد الثلاثة المستخدمة عادةً لوصف أنظمة الحوسبة: الشبكات والحوسبة والتخزين. ونقدم لمحة موجزة عن كل واحدة منها الموارد أدناه وتقديم المزيد من التفاصيل في الملحق ب.
3.1 الشبكات المحولات هي واجهات يمكن من خلالها إرسال الملفات التنفيذية التي تعمل على DON و تلقي البيانات من أنظمة DON خارج. يمكن النظر إلى المحولات على أنها تعميم لـ المحولات المستخدمة في Chainlink اليوم [20]. قد تكون المحولات ثنائية الاتجاه، أي أنها لا يمكن سحب البيانات فحسب، بل دفعها من DON إلى خادم الويب. يمكنهم أيضًا الاستفادة البروتوكولات الموزعة بالإضافة إلى وظائف التشفير مثل تعدد الأطراف الآمن حساب. الشكل 9: المحولات التي تربط DON، يُشار إليه بـ DON1، مع مجموعة من الموارد المختلفة، بما في ذلك DON آخر، يُشار إليه بـ DON2، وblockchain (السلسلة الرئيسية) وملحقاتها mempool ووحدة التخزين الخارجية وخادم الويب وأجهزة إنترنت الأشياء (عبر خادم الويب). يتم عرض أمثلة للموارد الخارجية التي يمكن إنشاء محولات لها في الشكل 9. وهي تشمل: • Blockchains: يمكن للمحول تحديد كيفية إرسال المعاملات إلى blockchain و كيفية قراءة الكتل أو المعاملات الفردية أو أي حالة أخرى منها. محول يمكن أيضًا تعريفه لمجمع الذاكرة blockchain. (انظر القسم 3.5.) • خوادم الويب: يمكن للمحولات تحديد واجهات برمجة التطبيقات التي يمكن من خلالها استرداد البيانات من خوادم الويب، بما في ذلك الأنظمة القديمة التي لم يتم تكييفها خصيصًا لها التواصل مع DONs. يمكن أن تتضمن هذه المحولات أيضًا واجهات برمجة التطبيقات لإرسال البيانات إليها مثل هذه الخوادم. قد تكون خوادم الويب التي يتصل بها DON بمثابة بوابات إلى موارد إضافية، مثل أجهزة إنترنت الأشياء (IoT).• وحدة التخزين الخارجية: يمكن للمحول تحديد طرق القراءة والكتابة إلى وحدة التخزين خدمات خارج DON، مثل نظام الملفات اللامركزي [40، 188] أو السحابة تخزين. • DONs أخرى: يمكن للمحولات استرداد البيانات ونقلها بين DONs. نتوقع أن تتضمن عمليات النشر الأولية لـ DONs مجموعة من الكتل البرمجية الإنشائية محولات لمثل هذه الموارد الخارجية شائعة الاستخدام وستسمح أيضًا بـ DON-محدد المحولات التي سيتم نشرها بواسطة العقد DON. كما يكتب مطورو smart contract المحولات اليوم، نتوقع أن يقوموا ببناء محولات أكثر قوة باستخدام هذا المتقدم الوظيفة. نتوقع أنه في النهاية سيكون من الممكن للمستخدمين إنشاء محولات جديدة في ملف بطريقة غير مسموح بها. يجب إنشاء بعض المحولات بطريقة تضمن استمرارية وتوافر الموارد الخارجية التي يتحكم فيها DON. على سبيل المثال، قد يكون التخزين السحابي تتطلب صيانة حساب الخدمات السحابية. بالإضافة إلى ذلك، يمكن تنفيذ DON الإدارة اللامركزية للمفاتيح الخاصة نيابة عن المستخدمين (كما في، على سبيل المثال، [160]) و/أو الملفات التنفيذية. وبالتالي، فإن DON قادر على التحكم في الموارد، مثل العملة المشفرة، التي يمكن استخدامها، على سبيل المثال، لإرسال المعاملات على الهدف blockchain. راجع الملحق ب.1 لمزيد من التفاصيل حول محولات DON، كما هو الحال في الملحق ج لعدد قليل محولات المثال. 3.2 الحساب الملف القابل للتنفيذ هو الوحدة الأساسية للتعليمات البرمجية في DON. الملف القابل للتنفيذ هو زوج exec = (المنطق، الحرف الأول). هنا، المنطق هو برنامج حتمي مع عدد من المدخلات المعينة النقاط (logic1، logic2،...، logicℓ) وinit عبارة عن مجموعة من البادئات المقابلة (init1، init2،...، inite). لضمان إمكانية التدقيق الكامل لمنطق الملف القابل للتنفيذ DON يستخدم دفتر الأستاذ الأساسي L لجميع المدخلات والمخرجات. وهكذا، على سبيل المثال، أي محول يجب تخزين البيانات التي تعمل كمدخل للملف القابل للتنفيذ أولاً على L. المبادرون: يتسبب البادئون في Chainlink اليوم في تنفيذ عمليات تنفيذ مهام تعتمد على الحدث Chainlink العقد [21]. تعمل البادئات في DONs بنفس الطريقة تقريبًا. ومع ذلك، فإن البادئ DON يرتبط بشكل خاص بملف قابل للتنفيذ. قد يعتمد البادئ على حدث أو حالة خارجية، في الوقت الحالي، أو على مسند على حالة DON. ومع اعتمادهم على الأحداث، قد يتصرف المبادرون بالطبع بطريقة غير حتمية (وبطبيعة الحال قد محولات). يمكن للبادئ التنفيذ ضمن العقد الفردية DON ولذا لا داعي للاعتماد على المحول. (انظر المثال 1 أدناه.) تعد البادئات ميزة مهمة تميز الملفات التنفيذية عن smart contracts. نظرًا لأن الملف القابل للتنفيذ يمكن تشغيله استجابةً للبادئ، فإنه يمكن أن يعمل بشكل فعال بشكل مستقل، كما هو الحال بالطبع، يمكن لعقد مختلط يتضمن ما هو قابل للتنفيذ. أحد أشكال المبادرين اليوم هو Chainlink Keepers، الذي يوفر المعاملاتخدمات التشغيل الآلي، مما يؤدي إلى تنفيذ smart contract - مثل تصفية القروض غير المضمونة وتنفيذ عمليات التداول ذات الأوامر المحددة - استنادًا إلى تقارير oracle. ومن الملائم أيضًا أن يتم النظر إلى البادئين في DONs كطريقة لتحديد اتفاقيات الخدمة التي تنطبق على الملف القابل للتنفيذ، لأنها تحدد الظروف في ظلها والذي يجب أن يطلق عليه DON. يوضح المثال التالي كيفية عمل البادئين ضمن ملف قابل للتنفيذ: المثال 1 (موجز الأسعار الناتج عن الانحراف). قد يتطلب smart contract SC طازجًا بيانات تغذية الأسعار (انظر القسم 3.6.3) عندما يكون هناك تغيير جوهري، على سبيل المثال، 1%، في سعر الصرف بين زوج من الأصول، على سبيل المثال، ETH-USD. سعر حساس للتقلب يتم دعم الخلاصات في Chainlink اليوم، ولكن من المفيد أن نرى كيف يمكن أن تكون كذلك تم تحقيقه على DON عن طريق ملف تنفيذي قابل للتنفيذ. يحتفظ الملف التنفيذي القابل للتنفيذ بأحدث سعر لـ ETH-USD r على L، في شكل تسلسل ⟨NewPrice : j، r⟩entries، حيث j هو مؤشر متزايد بـ كل تحديث للسعر. يتسبب البادئ init1 في قيام كل عقدة Oi بمراقبة السعر الحالي لـ ETH-USD انحرافات لا تقل عن 1٪ من أحدث سعر مخزن r مع الفهرس j. على عند اكتشاف مثل هذا الانحراف، يكتب Oi وجهة نظره الحالية ri للسعر الجديد إلى L باستخدام إدخال النموذج ⟨PriceView : i, j + 1, ri⟩. يتم تشغيل البادئ الثاني عند تشغيل إدخالات PriceView على الأقل بسعر جديد تراكمت قيم الفهرس j + 1 التي تم إنشاؤها بواسطة العقد المميزة على L. ثم، init2 يستدعي منطق نقطة الدخول 2 لحساب الوسيط ρ لقيم عرض الأسعار الجديدة والصالحة الأولى k ويكتب قيمة جديدة ⟨NewPrice : j + 1, ρ⟩to L . (من الناحية التشغيلية، العقد قد يتناوبون ككتاب معينين.) يراقب البادئ الثالث init3 إدخالات NewPrice على L. كلما ظهر تقرير جديد ⟨سعر جديد: يظهر j, r⟩ هناك، وهو يستدعي منطق نقطة الدخول 3 الذي يدفع (j, r) إلى SC باستخدام محول. وكما لاحظنا، فإن الملف القابل للتنفيذ يشبه في قدراته smart contract. وبصرف النظر عن أدائها العالي، فهي تختلف عن عقد السلسلة الرئيسية النموذجي بطريقتين أساسيتين: 1. السرية: يمكن للملف القابل للتنفيذ إجراء عمليات حسابية سرية، أي أن برنامجًا سريًا قد يعالج مدخلات نص واضح، أو قد يقوم برنامج منشور بمعالجة بيانات الإدخال السرية، أو مزيج من الاثنين معا. في نموذج بسيط، يمكن للبيانات السرية يمكن الوصول إليها عن طريق العقد DON، والتي تخفي النتائج المتوسطة وتكشف فقط القيم المعالجة والمعقمة إلى MAINCHAIN. من الممكن أيضًا إخفاء البيانات الحساسة عن DONs أنفسهم: DONs تهدف إلى دعم الأساليب مثل كحساب متعدد الأطراف، على سبيل المثال، [42، 157]، وبيئات التنفيذ الموثوقة (TEEs) [84، 133، 152، 229] لهذا الغرض.6 6بالإضافة إلى ذلك، من الممكن أيضًا الحفاظ على سرية الملفات التنفيذية فيما يتعلق بالعقد DON، على الرغم من أن هذا أمر عملي فقط اليوم بالنسبة للملفات التنفيذية غير التافهة التي تستخدم TEEs.2. الدور الداعم: الملف القابل للتنفيذ يهدف إلى دعم smart contracts على الملف الرئيسي سلسلة، بدلا من استبدالها. يحتوي الملف القابل للتنفيذ على العديد من القيود التي أ smart contract لا: (أ) نموذج الثقة: يعمل الملف القابل للتنفيذ ضمن نموذج الثقة المحدد بواسطة DON: يعتمد تنفيذها الصحيح على السلوك الصادق لـ O. (A main ومع ذلك، يمكن للسلسلة توفير بعض حواجز الحماية ضد DON المخالفات، كما تمت مناقشته في القسم 7.3.) (ب) الوصول إلى الأصول: يمكن لـ DON التحكم في حساب على blockchain - وبالتالي السيطرة على الأصول عليه من خلال محول. لكن DON لا يمكن أن يكون بشكل رسمي تمثل الأصول التي تم إنشاؤها على سلسلة رئيسية، على سبيل المثال، Ether أو ERC20 tokens، منذ ذلك الحين تحتفظ سلسلتهم الأصلية بالسجل الرسمي لملكيتهم. (ج) دورة الحياة: قد يتم إيقاف DONs عمدًا مع فترات حياة محدودة، كما يتم تحديدها من خلال اتفاقيات مستوى الخدمة على السلسلة بين DONs والمالكين من الاعتماد على العقود. في المقابل، تهدف سلاسل الكتل إلى العمل أنظمة أرشفة دائمة. راجع الملحق ب.2 لمزيد من التفاصيل حول حساب DON. 3.3 التخزين باعتباره نظامًا قائمًا على اللجان، يستطيع DON تخزين كميات معتدلة من البيانات بشكل مستمر على L بتكلفة أقل بكثير من blockchain غير المسموح به. بالإضافة إلى ذلك، عبر المحولات، يمكن لـ DONs الرجوع إلى الأنظمة اللامركزية الخارجية لتخزين البيانات، على سبيل المثال، Filecoin [85]، وبالتالي يمكن توصيل هذه الأنظمة بـ smart contracts. هذا الخيار على وجه الخصوص جذابة للبيانات المجمعة كوسيلة لمعالجة مشكلة "الانتفاخ" المنتشرة في العالم أنظمة blockchain. وبالتالي يمكن لـ DONs تخزين البيانات محليًا أو خارجيًا لاستخدامها في الخدمات المدعومة بشكل خاص. يمكن لـ DON أيضًا الاستفادة من هذه البيانات بطريقة سرية، الحوسبة على البيانات التي: (1) تمت مشاركتها بشكل سري عبر عقد DON أو مشفرة بموجب مفتاح تتم إدارته بواسطة العقد DON بطرق مناسبة للحساب الآمن متعدد الأطراف أو التشفير المتماثل الجزئي أو الكامل؛ أو (2) محمي باستخدام تنفيذ موثوق به بيئة. نتوقع أن يتبنى DONs نموذجًا بسيطًا لإدارة الذاكرة شائعًا أنظمة العقود الذكية: لا يجوز كتابة الملف القابل للتنفيذ إلا في ذاكرته الخاصة. الملفات التنفيذية ومع ذلك، يمكن قراءتها من ذاكرة الملفات التنفيذية الأخرى. راجع الملحق ب.3 لمزيد من التفاصيل حول تخزين DON. 3.4 إطار تنفيذ المعاملات (TEF) DONs تهدف إلى دعم العقود على سلسلة رئيسية MAINCHAIN (أو على سلاسل رئيسية متعددة). تمت مناقشة إطار تنفيذ المعاملات (TEF) بالتفصيلفي القسم 6، هو نهج للأغراض العامة للتنفيذ الفعال للعقد SC عبر MAINCHAIN وDON. والمقصود من TEF هو دعم الخدمة الثابتة الساتلية (FSS) والطبقة الثانية التقنيات - في وقت واحد، إذا رغبت في ذلك. في الواقع، من المرجح أن تكون بمثابة الوسيلة الرئيسية لاستخدام الخدمة الثابتة الساتلية (ولهذا السبب، فإننا لا نناقش الخدمة الثابتة الساتلية بشكل أكبر في هذا القسم). باختصار، في TEF، تم تصميم أو تطوير عقد SC الأصلي لـ MAINCHAIN يتم إعادة هيكلتها في عقد هجين. تنتج عملية إعادة البناء هذه العملين المتداخلين أجزاء من العقد المختلط: عقد MAINCHAIN SCa الذي نشير إليه للتوضيح في سياق TEFs كعقد أساسي وعقد تنفيذي قابل للتنفيذ على DON. ال يتولى عقد SCa حراسة أصول المستخدمين، وتنفيذ عمليات نقل الحالة الرسمية، وأيضًا يوفر قضبان حماية (انظر القسم 7.3) ضد الأعطال في DON. التنفيذيين القابل للتنفيذ تسلسل المعاملات ويوفر بيانات oracle المرتبطة بها. يمكن أن حزمة معاملات SCa بأي من الطرق العديدة - على سبيل المثال، باستخدام إثبات الصلاحية أو rollups متفائل، والتنفيذ السري بواسطة DON، وما إلى ذلك. نتوقع تطوير أدوات تسهل على المطورين تقسيم العقد SC مكتوبة بلغة عالية المستوى إلى أجزاء من منطق MAINCHAIN وDON وSCa و execs على التوالي، والتي يتم الإنشاء بشكل آمن وفعال. استخدام TEF لدمج أنظمة المعاملات عالية الأداء مع الأداء العالي يعد oracles جزءًا لا يتجزأ من نهجنا في التوسع oracle. 3.5 خدمات ميمبول إحدى ميزات طبقة التطبيق المهمة التي نعتزم نشرها على DONs لدعمها FSS وTEF هما خدمات Mempool (MS). يمكن النظر إلى MS كمحول، ولكن مع دعم من الدرجة الأولى. يوفر MS الدعم لمعالجة المعاملات المتوافقة مع التراث. في هذا الاستخدام، MS يستوعب من مجموعة ذكريات السلسلة الرئيسية تلك المعاملات المخصصة لعقد مستهدف SC على مينشين. يقوم MS بعد ذلك بتمرير هذه المعاملات إلى ملف قابل للتنفيذ على DON، حيث تتم معالجتها بالطريقة المطلوبة. يمكن استخدام بيانات MS بواسطة DON لإنشاء المعاملات التي يمكن بعد ذلك تمريرها مباشرة إلى SC من DON أو إلى عقد آخر يدعو SC. على سبيل المثال، يمكن لـ DON إعادة توجيه المعاملات يتم حصادها عبر MS، أو يمكنها استخدام بيانات MS لتحديد أسعار الغاز للمعاملات التي ترسلها مينشين. ولأنه يراقب مجمع الذاكرة، يستطيع MS الحصول على المعاملات من المستخدمين الذين يتفاعلون مباشرة مع SC. وبالتالي يمكن للمستخدمين الاستمرار في إنشاء معاملاتهم باستخدام البرامج القديمة، أي التطبيقات غير المدركة لوجود MS وMS العقود. (في هذه الحالة، يجب تغيير SC لتجاهل المعاملات الأصلية و تقبل فقط تلك التي تتم معالجتها بواسطة MS، وذلك لتجنب المعالجة المزدوجة.) للاستخدام مع العقد المستهدف SC، يمكن استخدام MS مع FSS و/أو TEF.3.6 نقطة الانطلاق: قدرات Chainlink الموجودة 3.6.1 التقارير خارج السلسلة (OCR) تعد التقارير خارج السلسلة (OCR) [60] آلية في Chainlink لتجميع التقارير oracle ونقلها إلى عقد معتمد SC. تم نشره مؤخرًا بسعر Chainlink شبكات التغذية، فهي تمثل خطوة أولى على الطريق إلى DONs الكاملة. في جوهره، يعد التعرف الضوئي على الحروف (OCR) بمثابة بروتوكول BFT مصمم للعمل بشكل متزامن جزئيًا شبكة. إنه يضمن الحيوية والصحة في وجود f < n/3 بشكل تعسفي العقد المعيبة التي تضمن خصائص البث البيزنطي الموثوق به، لكنها ليست كذلك بروتوكول إجماع BFT كامل. لا تحتفظ العقد بسجلات الرسائل الموجودة متسقة بمعنى تمثيل دفتر أستاذ متطابق في جميع وجهات نظرهم، ويجوز لقائد البروتوكول المراوغة دون انتهاك السلامة. تم تصميم تقنية التعرف الضوئي على الحروف (OCR) حاليًا لنوع معين من الرسائل: التجميع المتوسط لـ (على الأقل 2f +1) القيم التي أبلغت عنها العقد المشاركة. ويوفر ضمانًا أساسيًا بشأن وتسمى التقارير التي تخرجها لـ SC التقارير المعتمدة: القيمة المتوسطة في الشهادة التقرير يساوي أو يقع بين القيم التي تم الإبلاغ عنها بواسطة عقدتين صادقتين. هذه الخاصية شرط السلامة الرئيسي للتعرف الضوئي على الحروف. قد يكون للقائد بعض التأثير على الوسيط القيمة في تقرير مصدق، ولكن تخضع فقط لشرط الصحة هذا. يمكن التعرف الضوئي على الحروف يمكن توسيعها لتشمل أنواع الرسائل التي تجمع القيم بطرق مختلفة. في حين أن أهداف حيوية وصحة الشبكة Chainlink اليوم لا تتطلب ذلك نظرًا لأن تقنية التعرف الضوئي على الحروف (OCR) عبارة عن بروتوكول إجماع كامل، فإنها تتطلب تقنية التعرف الضوئي على الحروف (OCR) لتوفير بعض الأشكال الإضافية من الوظائف غير الموجودة في بروتوكولات BFT التقليدية، وأبرزها: 1. بث تقرير الكل أو لا شيء خارج السلسلة: يضمن التعرف الضوئي على الحروف (OCR) أن التقرير المصدق أصبح متاحًا بسرعة لجميع العقد الصادقة أو لا شيء منهم. هذا هو الإنصاف خاصية تساعد على ضمان حصول العقد الصادقة على فرصة المشاركة في نقل التقرير الموثق. 2. نقل موثوق: يضمن التعرف الضوئي على الحروف (OCR)، حتى في حالة وجود خلل أو ضار العقد، حيث يتم نقل جميع تقارير ورسائل التعرف الضوئي على الحروف إلى SC خلال فترة معينة، فترة زمنية محددة مسبقا. هذه خاصية حيوية. 3. تقليل الثقة على أساس العقد: تقوم SC بتصفية التقارير التي يحتمل أن تكون خاطئة من خلال التعرف الضوئي على الحروف، على سبيل المثال، إذا كانت قيمها المُبلغ عنها تنحرف بشكل كبير عن القيم الأخرى تلك التي تم استلامها مؤخرًا. يعد هذا أحد أشكال تطبيق صحة البروتوكول الإضافي. ستلعب كل هذه الخصائص الثلاثة دورًا طبيعيًا في DONs. يعد بث الكل أو لا شيء خارج السلسلة (DON) لبنة بناء مهمة لضمانات الاقتصاد المشفر حول ناقل الحركة الموثوق به، والذي يعد بدوره خاصية محول أساسية. الثقة إن التقليل في SC هو نوع من حاجز الحماية، كما تمت مناقشته في القسم 7.3. يوفر التعرف الضوئي على الحروف (OCR) أيضًا أساسًا للنشر التشغيلي وتحسين بروتوكولات BFT في شبكات oracle الخاصة بـ oracle وبالتالي، كما هو مذكور أعلاه، مسارًا إلى التنفيذ الكامل وظائف DONs.3.6.2 ديكو وتاون كريير DECO [234] وTown Crier [233] هما زوج من التقنيات ذات الصلة التي يتم حاليًا تطويرها تم تطويره في شبكات Chainlink. تسمح معظم خوادم الويب اليوم للمستخدمين بالاتصال عبر قناة آمنة باستخدام بروتوكول يُسمى أمان طبقة النقل (TLS) [94]. (HTTPS يشير إلى متغير HTTP الذي تم تمكينه باستخدام TLS، أي أن عناوين URL التي تسبقها "https" تشير إلى استخدام TLS للأمان.) على الرغم من ذلك، فإن معظم الخوادم التي تدعم TLS لديها قيود ملحوظة: فهي لا تقوم بالتوقيع رقميًا data. وبالتالي، لا يمكن للمستخدم أو المُثبت تقديم البيانات التي يتلقاها من الخادم إلى طرف ثالث أو جهة التحقق، مثل oracle أو smart contract، بطريقة تضمن صحة البيانات. وحتى لو قام الخادم بتوقيع البيانات رقميًا، تظل هناك مشكلة تتعلق بالسرية. قد يرغب المُثبت في تنقيح البيانات الحساسة أو تعديلها قبل تقديمها إلى أ المتحقق. ومع ذلك، تم تصميم التوقيعات الرقمية خصيصًا لإبطال البيانات المعدلة. وبالتالي، فإنها تمنع المُثبِّت من إجراء تعديلات للحفاظ على السرية إلى البيانات. (انظر القسم 7.1 لمزيد من المناقشة.) تم تصميم DECO وTown Crier للسماح للمثبت بالحصول على البيانات من الويب الخادم وتقديمها إلى جهة التحقق بطريقة تضمن النزاهة والسرية. يحافظ النظامان على النزاهة بمعنى أنهما يضمنان أن البيانات المقدمة من قبل ينشأ المثبت إلى المدقق بشكل أصلي من الخادم الهدف. إنهم يدعمون السرية بمعنى السماح للمحقق بتنقيح البيانات أو تعديلها (في حين لا يزال الحفاظ على النزاهة). الميزة الرئيسية لكلا النظامين هي أنهما لا يتطلبان أي تعديلات على أي منهما خادم الويب المستهدف. يمكنهم العمل مع أي خادم موجود يدعم TLS. في الواقع، فهي شفافة بالنسبة للخادم: من وجهة نظر الخادم، يكون Prover كذلك إنشاء اتصال عادي. لدى النظامين أهداف متشابهة، لكنهما يختلفان في نماذج الثقة وتطبيقاتهما كما نوضح الآن بإيجاز. يستخدم DECO بشكل أساسي بروتوكولات التشفير لتحقيق سلامته وخصائص السرية. أثناء إنشاء جلسة مع خادم مستهدف باستخدام DECO، يشارك Prover في نفس الوقت في بروتوكول تفاعلي مع المتحقق. يتيح هذا البروتوكول للمحقق أن يثبت للمدقق أنه قد استلمه جزء معين من البيانات D من الخادم أثناء جلسته الحالية. يستطيع البرهان وبدلاً من ذلك، قدم للمدقق دليلاً على عدم المعرفة ببعض خصائص D وبالتالي لا تكشف د مباشرة. في الاستخدام النموذجي لـ DECO، يمكن لمستخدم أو عقدة واحدة تصدير البيانات D من عقدة خاصة جلسة مع خادم الويب لجميع العقد في DON. ونتيجة لذلك، يمكن DON الكامل يشهد على صحة D (أو حقيقة مشتقة من D عبر إثبات المعرفة الصفرية). بالإضافة إلى أمثلة التطبيقات الواردة لاحقًا في هذه الورقة، يمكن أن تكون هذه الإمكانية يُستخدم لتضخيم الوصول عالي التكامل إلى مصدر البيانات بواسطة DON. حتى لو عقدة واحدة فقط لديه إمكانية الوصول المباشر إلى مصدر البيانات، على سبيل المثال، بسبب اتفاق حصري معه مزود البيانات - يظل من الممكن لـ DON بأكمله أن يشهد على صحةالتقارير المنبعثة من تلك العقدة. يعتمد Town Crier على استخدام بيئة تنفيذ موثوقة (TEE) مثل Intel سغس. باختصار، يعمل TEE كنوع من الصندوق الأسود الذي ينفذ التطبيقات في ملف واحد طريقة سرية ومضادة للتلاعب. من حيث المبدأ، حتى صاحب المضيف الذي لا يمكن لـ TEE قيد التشغيل (بشكل غير قابل للاكتشاف) تغيير تطبيق محمي بـ TEE ولا عرض حالة التطبيق، والتي قد تتضمن بيانات سرية. يمكن لـ Town Crier تحقيق جميع وظائف DECO والمزيد. يقيد DECO المُثبت على التفاعل مع مدقق واحد. في المقابل، تاون كراير تمكن مُثبت لإنشاء دليل يمكن التحقق منه بشكل عام على البيانات D التي تم جلبها من خادم مستهدف، أي دليل على أن أي شخص، حتى smart contract، يمكنه التحقق مباشرة. يستطيع تاون كريير وأيضًا استيعاب الأسرار واستخدامها بشكل آمن (على سبيل المثال، بيانات اعتماد المستخدم). القيد الرئيسي في Town Crier هو اعتمادها على TEEs. TEEs الإنتاج لديها وقد ثبت مؤخرًا أنها تحتوي على عدد من نقاط الضعف الخطيرة، على الرغم من أن التكنولوجيا لا تزال في مهدها وسوف تنضج بلا شك. انظر الملحقين B.2.1 وB.2.2 للاطلاع على مزيد من المناقشة حول TEEs. للحصول على بعض الأمثلة على تطبيقات DECO وTown Crier، راجع الأقسام 4.3 و4.5 و9.4.3 والملحق ج.1. 3.6.3 الخدمات الموجودة على السلسلة Chainlink توفر شبكات Chainlink oracle عددًا من الخدمات الرئيسية عبر عدد كبير من blockchains والأنظمة اللامركزية الأخرى اليوم. مزيد من التطور كما هو موضح في هذا المستند التقني، ستمنح هذه الخدمات الحالية إمكانات وميزات إضافية الوصول. ثلاثة أمثلة هي: خلاصات البيانات: اليوم، يعتمد غالبية مستخدمي Chainlink على smart contracts. استخدام خلاصات البيانات. هذه تقارير عن القيمة الحالية للأجزاء الرئيسية من البيانات وفقًا لذلك إلى مصادر موثوقة خارج السلسلة. على سبيل المثال، خلاصات الأسعار هي خلاصات تبلغ عن الأسعار الأصول - العملات المشفرة، والسلع، والعملات الأجنبية، والمؤشرات، والأسهم، وما إلى ذلك - وفقًا لـ خدمات التبادل أو تجميع البيانات. تساعد مثل هذه الخلاصات اليوم بالفعل في تأمين المليارات من الدولارات من القيمة على السلسلة من خلال استخدامها في أنظمة DeFi مثل Aave [147] و سينثيتيكس [208]. تتضمن الأمثلة الأخرى لخلاصات بيانات Chainlink بيانات الطقس لـ التأمين على المحاصيل البارامترية [75] وبيانات الانتخابات [93]، من بين عدد آخر. سيؤدي نشر DONs والتقنيات الأخرى الموضحة في هذه المقالة إلى تحسين توفير خلاصات البيانات في شبكات Chainlink بعدة طرق، بما في ذلك: • القياس: يهدف التعرف الضوئي على الحروف (OCR) ومن ثم DONs إلى تمكين خدمات Chainlink على نطاق واسع بشكل كبير عبر العديد من blockchains التي يدعمونها. على سبيل المثال، نتوقع أن DONs سيساعد في زيادة عدد خلاصات البيانات التي توفرها العقد التي تستخدمها Chainlink من 100 إلى 1000 وما بعدها. سيساعد هذا القياس Chainlink يحقق النظام البيئي هدفه المتمثل في توفير البيانات ذات الصلة بـ smart contracts بشكل شامل وتلبية وتوقع الاحتياجات الحالية والمستقبلية.• أمان محسّن: من خلال تخزين التقارير المتوسطة، سيحتفظ DONs بالسجلات سلوكيات العقدة لمراقبة عالية الدقة وقياس أدائها ودقتها، مما يتيح أسسًا تجريبية قوية لأنظمة السمعة للعقد Chainlink. وسيعمل FSS وTEF على تمكين دمج خلاصات الأسعار مع بيانات المعاملات بطرق مرنة تمنع الهجمات مثل التشغيل الأمامي. (صريح) staking سيعزز الحماية الاقتصادية المشفرة الحالية للأمن من خلاصات البيانات. • سرعة التغذية: نظرًا لأن blockchain أنظمة غير محددة (في الواقع، على نطاق أوسع، أنظمة غير محددة للمستهلك)، فإن DON يمكن أن تسهل توفير خلاصات البيانات لعدد كبير من الأشخاص من أنظمة الاعتماد. يمكن لـ DON واحد أن يدفع خلاصة معينة في وقت واحد إلى مجموعة من blockchains المختلفة، مما يلغي الحاجة إلى شبكات oracle لكل سلسلة و تمكين النشر السريع للخلاصات الموجودة على blockchains الجديدة والإضافية الخلاصات عبر blockchains التي تتم خدمتها حاليًا. • السرية: تتيح القدرة على إجراء عمليات حسابية معممة في DON إجراء العمليات الحسابية على البيانات الحساسة خارج السلسلة، مما يتجنب إجراء العمليات الحسابية على السلسلة التعرض. بالإضافة إلى ذلك، باستخدام DECO أو Town Crier، من الممكن تحقيقه وسرية أكبر، مما يسمح بإنشاء التقارير بناءً على بيانات غير موجودة يتعرض حتى لعقد DON. انظر القسم 4.3 والقسم 4.5 للحصول على أمثلة. وظائف عشوائية يمكن التحقق منها (VRFs): تتطلب العديد من أنواع التطبيقات اللامركزية (DApps) مصدرًا عشوائيًا صحيحًا يمكن التحقق منه لتمكين التحقق من عملها العادل. تعتبر الرموز غير القابلة للاستبدال (NFTs) مثالاً على ذلك. يتم تحديد ندرة ميزات NFT في Aavegotchi [23] وAxie Infinity [35] بواسطة Chainlink VRF، كما هو الحال مع التوزيع من NFTs عن طريق الرسومات المستندة إلى التذاكر في بطاقات الأثير [102]؛ مجموعة واسعة من تطبيقات الألعاب اللامركزية التي تكون نتائجها عشوائية؛ والأدوات المالية غير التقليدية، على سبيل المثال، ألعاب الادخار بدون خسارة مثل PoolTogether [89]، والتي تخصص الأموال الفائزين عشوائي. تتطلب التطبيقات الأخرى blockchain وغير blockchain أيضًا أمانًا مصادر العشوائية، بما في ذلك اختيار لجان النظام اللامركزي و تنفيذ اليانصيب. على الرغم من أن الكتلة hashes يمكن أن تكون بمثابة مصدر للعشوائية التي لا يمكن التنبؤ بها، إلا أنها عرضة للتلاعب من قبل القائمين بالتعدين المنافسين (وإلى حد ما من قبل المستخدمين الذين يرسلون المعاملات). يقدم Chainlink VRF [78] بديلاً أكثر أمانًا إلى حد كبير. ان يحتوي oracle على زوج مفاتيح خاص/عام مرتبط (sk, pk) يتم الاحتفاظ بمفتاحه الخاص خارج السلسلة ويتم نشر مفتاحه العام pk. لإخراج قيمة عشوائية، فإنه يطبق sk على بذرة x غير متوقعة مقدمة من عقد الاعتماد (على سبيل المثال، كتلة hash) والمعلمات الخاصة بـ DApp) باستخدام الدالة F، مما يؤدي إلى y = Fsk(x) مع a دليل على صحة. (راجع [180] للتعرف على VRF المتوفر على Chainlink.) ما الذي يجعل VRF الذي يمكن التحقق منه هو حقيقة أنه من خلال معرفة pk، من الممكن التحقق من صحة الدليل وبالتالي صحة y. وبالتالي فإن القيمة y لا يمكن التنبؤ بها بالنسبة لـ an خصم لا يمكنه التنبؤ بـ x أو تعلم sk ولا يمكن للخدمة التلاعب به.Chainlink يمكن النظر إلى VRF على أنه مجرد واحد من مجموعة من التطبيقات التي تتضمن رعاية المفاتيح الخاصة خارج السلسلة. وبشكل أكثر عمومية، يمكن لـ DONs توفير الأمان، التخزين اللامركزي للمفاتيح الفردية للتطبيقات و/أو المستخدمين والجمع بينها هذه القدرة مع الحساب المعمم. والنتيجة هي مجموعة من التطبيقات، من والتي نعطيها بعض الأمثلة في هذه الورقة، بما في ذلك الإدارة الرئيسية لإثبات الاحتياطيات (انظر القسم 4.1) وبالنسبة لبيانات الاعتماد اللامركزية للمستخدمين (وغيرها من البيانات الرقمية). الأصول) (انظر القسم 4.3). الحراس: Chainlink Keepers [87] يمكّن المطورين من كتابة التعليمات البرمجية للأنظمة اللامركزية تنفيذ المهام خارج السلسلة، بشكل عام لتحفيز تنفيذ الاعتماد على smart contracts. قبل ظهور Keepers، كان من الشائع بالنسبة للمطورين تشغيل مثل هذه الخدمات خارج السلسلة المنطق نفسه، مما يخلق نقاط فشل مركزية (فضلاً عن جهود تطوير مكررة كبيرة). يوفر Keepers بدلاً من ذلك إطار عمل سهل الاستخدام لـ الاستعانة بمصادر خارجية لامركزية لهذه العمليات، مما يتيح دورات تطوير أقصر و ضمان قوي للحيوية والخصائص الأمنية الأخرى. يمكن للحافظين دعم أي لمجموعة واسعة من الأهداف المحفزة، بما في ذلك تصفية القروض المعتمدة على السعر أو تنفيذ المعاملات المالية، وبدء عمليات الإنزال الجوي أو المدفوعات التي تعتمد على الوقت في الأنظمة التي تعتمد على حصاد المحصول، وما إلى ذلك. في إطار عمل DON، يمكن النظر إلى البادئين على أنهم تعميم لـ Keepers بعدة معانٍ. يمكن للبادئين الاستفادة من المحولات، وبالتالي يمكنهم الاستفادة من أ مكتبة نمطية من الواجهات للأنظمة الموجودة على السلسلة وخارجها، مما يسمح بسرعة تطوير وظائف آمنة ومتطورة. يبدأ المبادرون الحساب في الملفات التنفيذية، والتي توفر بحد ذاتها التنوع الكامل لـ DONs، مما يسمح بالنطاق الواسع مجموعة من الخدمات اللامركزية التي نقدمها في هذه الورقة للتطبيقات المتصلة بالسلسلة وخارجها. 3.6.4 سمعة العقدة / تاريخ الأداء يوثق النظام البيئي الحالي Chainlink أصلاً تاريخ أداء العقد المساهمة على السلسلة. وقد أدت هذه الميزة إلى ظهور مجموعة من الموارد الموجهة نحو السمعة والتي تستوعب بيانات الأداء وتصفيتها وتصورها على الأفراد. مشغلي العقدة وخلاصات البيانات. يمكن للمستخدمين الرجوع إلى هذه الموارد لجعلها على علم اتخاذ القرارات في اختيار العقد ومراقبة تشغيل الشبكات الحالية. ستساعد الإمكانيات المماثلة المستخدمين على اختيار DONs. على سبيل المثال، تسمح الأسواق غير المسموح بها اليوم مثلmarket.link بالعقدة يقوم المشغلون بإدراج خدمات oracle الخاصة بهم والشهادة على هوياتهم خارج السلسلة من خلال خدمات مثل Keybase [4]، والتي تربط ملف تعريف العقدة في Chainlink بـها أسماء النطاقات الحالية للمالك وحسابات الوسائط الاجتماعية. بالإضافة إلى ذلك، الأداء تسمح أدوات التحليلات، مثل تلك المتاحة علىmarket.link وreputation.link للمستخدمين لعرض إحصائيات حول الأداء التاريخي للعقد الفردية، بما في ذلك متوسط زمن الاستجابة، وانحراف القيم في تقاريرهم عن القيم المتفق عليها يتم ترحيلها على السلسلة، والإيرادات المولدة، والوظائف التي تم إنجازها، والمزيد. أدوات التحليل هذه أيضًا السماح للمستخدمين بتتبع اعتماد شبكات oracle المختلفة من قبل مستخدمين آخرين، وهو شكل من أشكالتأييد ضمني للعقد التي تؤمن هذه الشبكات. والنتيجة هي "شبكة مسطحة من". الثقة" التي يتم من خلالها إنشاء تطبيقات لامركزية عالية القيمة باستخدام عقد معينة إشارة إلى ثقتهم في تلك العقد التي يمكن للمستخدمين الآخرين مراقبتها وأخذها في الاعتبار قرارات اختيار العقدة الخاصة. مع DONs (وفي البداية مع التعرف الضوئي على الحروف) يأتي تحول في معالجة المعاملات و نشاط العقد بشكل عام خارج السلسلة. نموذج لامركزي لتسجيل العقدة يظل الأداء ممكنًا داخل DON نفسه. والواقع أن الأداء العالي وسعة البيانات DONs تجعل من الممكن إنشاء سجلات بطريقة دقيقة الطريقة وأيضًا لإجراء عمليات حسابية لا مركزية على هذه السجلات، مما ينتج عنه ملخصات جديرة بالثقة يمكن أن تستهلكها خدمات السمعة ويتم فحصها مينشين. في حين أنه من الممكن أن يقوم DON من حيث المبدأ بتحريف سلوك العقد المكونة في حالة تلف جزء كبير من العقد، إلا أننا نلاحظ أن المجموعة أداء DON نفسه في تقديم البيانات على السلسلة مرئي على MAINCHAIN وبالتالي لا يمكن تحريفها. بالإضافة إلى ذلك، نحن نخطط لاستكشاف الآليات التي تحفيز إعداد تقارير داخلية دقيقة عن سلوكيات العقدة في DON. على سبيل المثال، من خلال الإبلاغ عن المجموعة الفرعية من العقد عالية الأداء التي تقوم بإرجاع البيانات المساهمة بشكل أسرع إلى تقرير تم ترحيله على السلسلة، يُنشئ DON حافزًا للعقد للاعتراض على الخطأ التقارير: تضمين العقد بشكل غير صحيح في هذه المجموعة الفرعية يعني استبعاد العقد بشكل غير صحيح كان ينبغي إدراجها وبالتالي معاقبتهم بشكل غير صحيح. سيؤدي فشل الإبلاغ المتكرر بواسطة DON أيضًا إلى خلق حافز للعقد الصادقة لمغادرة DON. التجميع اللامركزي لسجلات الأداء الدقيقة وما يترتب على ذلك قدرة المستخدمين على تحديد العقد عالية الأداء ومشغلي العقد للبناء تعد السمعة من السمات المميزة المهمة للنظام البيئي Chainlink. نحن أظهر في القسم 9 كيف يمكننا التفكير فيها باعتبارها جزءًا أساسيًا من خطة صارمة ودقيقة نظرة موسعة للأمن الاقتصادي الذي توفره DONs.
去中心化支持的去中心化服务
甲骨文网络 为了说明 DON 的多功能性以及它们如何启用大量新服务， 我们在本节中介绍了五个基于 DON 的应用程序示例，并描述了 实现它们的混合合约：（1）储备证明，一种跨链服务形式； （2）与企业/遗留系统对接，即创建基于中间件的 抽象层，有助于以最少的成本开发 blockchain 应用程序 blockchain-特定代码或专业知识； (3) 去中心化的身份，使用户能够 获取并管理自己的身份证件和凭证； (4) 优先通道， 确保及时纳入关键基础设施交易的服务（例如 oracle 报告）在 blockchain 上； (5) 保密DeFi，即财务信息 smart contract 隐藏参与方的敏感数据。 在这里，我们
使用 SC 表示混合合约的主链部分并描述 DON 组件单独或作为可执行文件执行。 4.1 储备金证明 对于许多应用程序来说，在 blockchain 之间中继状态非常有用。一个 此类服务的流行应用是加密货币包装。包裹硬币之类的 随着 WBTC [15] 正在成为去中心化金融 (DeFi) 中的流行资产。他们 涉及将“包装”的支持资产存入其源 blockchain MAINCHAIN(1) 并在不同的目标 blockchain MAINCHAIN(2) 上创建相应的 token。 例如，WBTC 是 Ethereum blockchain 上的 ERC20 token 对应的 至 Bitcoin blockchain 上的 BTC。 由于 MAINCHAIN(2) 上的合约无法直接查看 MAINCHAIN(1)， 他们必须显式或隐式依赖 oracle 来报告已包装的存款 smart contract 中的资产，产生有时称为储备证明的东西。在 WBTC [15]，例如托管人 BitGo 持有 BTC 并发行 WBTC， Chainlink 网络提供储备证明 [76]。 DON 本身可以提供储备证明。但是，使用 DON 是可能的 走得更远。 DON 可以管理机密，并通过使用适当的适配器， 可以在任何所需的 blockchain 上进行交易。因此，DON 可以采取行动 作为众多托管人之一，甚至作为唯一的去中心化托管人 打包的资产。 DONs 因此可以作为增强安全性的平台 使用储备证明的现有服务。 例如，假设 MAINCHAIN(1) 为 Bitcoin，MAINCHAIN(2) 为 Ethereum。 在 MAINCHAIN(2) 上，合约 SC 发行代表打包 BTC 的 tokens。 DON 控制BTC地址addr(1) DON。为了包装 BTC，用户 U 从 地址(1) U 至地址(1) DON 以及 MAINCHAIN(2)-地址 addr(2) 乌。 DON 监视器 地址(1) DON 通过 MAINCHAIN(1) 的适配器。 在观察到 U 的存款后，以足够高的概率确认，它通过适配器向 SC 发送一条消息 主链(2)。该消息指示 SC 为 addr(2) 铸造 X tokens 乌。 当 U 释放 X tokens 时，会发生相反的情况。 然而，在 MAINCHAIN(1) 上， 地址(1) DON 发送 X BTC 到 addr(1) U（或另一个地址，如果用户如此请求）。 当然，这些协议可以进行调整，以便与交易所合作，而不是直接 与用户。 4.2 与企业/遗留系统接口 DONs 可以充当 blockchains 之间的桥梁，如证明的示例所示 储备金，但另一个目标是让它们充当储备金之间的双向桥梁 blockchain 和旧系统 [176] 或 blockchain 类似系统，例如中央银行 数字货币[30]。 企业在连接现有系统和 去中心化系统的流程，包括：• 区块链敏捷性：区块链系统变化迅速。企业可能会遇到 blockchain 的快速新出现或流行度上升，其中 交易对手有意愿进行交易，但企业无能力进行交易 现有基础设施的支持。一般来说，blockchains 的活力使得 单个企业很难跟上整个生态系统的步伐。 • 区块链特定的开发资源：对于许多组织来说，雇用或孵化尖端的blockchain 专业知识是很困难的，特别是考虑到 敏捷性的挑战。 • 私钥管理：管理 blockchain 或加密货币的私钥需要不同于传统网络安全的运营专业知识 实践中，很多企业都无法做到这一点。 • 保密性：企业对于暴露其敏感和专有信息持谨慎态度。 数据上链。 为了解决前三个困难，开发人员可以简单地使用 DON 作为安全的中间件层，使企业系统能够读取或写入 blockchains。 DON 可以抽象出详细的技术考虑因素，例如 为开发者和用户提供气体动力学、链重组等。由 为企业系统提供简化的 blockchain 接口，因此 DON 可以 大大简化了 blockchain 感知企业应用程序的开发，消除了企业获取或孵化 blockchain 特定开发资源的负担。 DONs 的这种使用特别有吸引力，因为它使企业开发人员能够 创建很大程度上与 blockchain 无关的智能合约应用程序。结果， 较大的 blockchain 集（其中 DON 被检测为充当中间件）， 企业用户可以轻松访问的更大的 blockchain 集合。开发商 可以通过最少的修改将应用程序从现有的 blockchain 移植到新的应用程序 到他们内部开发的应用程序。 为了解决额外的保密问题，开发人员可以向 我们在本文中介绍并期望部署以支持 DON 应用程序的工具。 其中包括 DECO 和 Town Crier 第 3.6.2 节以及保密性 第 7.1.2 节讨论了 API 修改，本节其余部分介绍了一些特定于应用程序的方法。这些 DON 系统可以提供 关于企业系统状态的高完整性、链上证明而不泄露 敏感企业源数据上链。 4.3 去中心化身份 去中心化身份是用户应该能够 获取并管理自己的凭证，而不是依赖第三方来做 所以。去中心化凭证是对持有者属性或主张的证明，这通常称为索赔。凭证由实体进行数字签名，通常称为 发行者，可以权威地将声明与用户关联起来。在大多数提议的方案中， 声明与去中心化标识符（DID）相关联，这是一个通用标识符 给定用户。凭证绑定到用户持有其私钥的公钥。 因此，用户可以使用她的私钥证明拥有索赔。 去中心化身份是有远见的，现有的和拟议的方案，例如，[14, 92, 129, 216]，具有三个严重的局限性： • 缺乏遗留兼容性：现有的去中心化身份系统依赖于 由称为发行者的权威机构组成的社区，负责生成 DID 凭证。因为 现有的网络服务通常不会对数据进行数字签名，必须启动发行者 作为特殊用途的系统。因为没有动力就没有动力这样做 去中心化的身份生态系统，就会出现先有鸡还是先有蛋的问题。在其他方面 换句话说，目前还不清楚如何引导发行人生态系统。 • 密钥管理不可行：去中心化身份系统要求用户 管理私钥，加密货币的经验已经证明了这一点 成为一个不可行的责任。据估计，大约有 4,000,000 个 Bitcoin 已被 由于密钥管理故障 [194] 而永远丢失，并且许多用户存储了他们的 加密资产与交易所[193]，从而破坏权力下放。 • 缺乏保护隐私的女巫抵抗：投票、token 销售期间公平分配 token 等应用程序的基本安全要求是： 用户无法断言多个身份。现有的去中心化身份提案要求用户透露他们的现实世界身份才能实现这一目标 女巫抵抗，从而破坏重要的隐私保证。 可以使用节点委员会的组合来解决这些问题 在 DON 中执行分布式计算并使用 DECO 等工具 或 Town Crier，如名为 CanDID [160] 的系统中所示。 DECO 或 Town Crier 可以通过设计将现有的 Web 服务转变为无需修改 成为保密凭证颁发者。它们使 DON 能够导出相关的 为此目的的数据到凭证中，同时隐藏不应该的敏感数据 出现在凭证中。 另外，为了方便用户恢复密钥，从而解决密钥管理问题 问题，DON 可以允许用户以秘密共享的形式存储私钥。用户可以 通过向 DON 中的节点证明来恢复其密钥——类似地，使用 Town Crier 或 DECO——通过一组预先确定的网络提供商（例如， 推特、谷歌、脸书）。相对于使用 Town Crier 或 DECO 的好处 OAUTH，是用户隐私。这两个工具使用户能够避免向 DON 泄露信息 网络提供商标识符——通常可以从中导出现实世界的身份。 最后，为了提供 Sybil 抵抗，如 [160] 所示，DON 可以 为用户执行独特的现实世界标识符的隐私保护转换 （例如，社会安全号码（SSN））在用户注册时添加到链上标识符中。因此，系统可以检测重复注册，而无需敏感数据，例如 SSN 被泄露给各个 DON 节点。7 DON 可以代表外部去中心化身份提供任何这些服务 未经许可或经过许可的 blockchain 上的系统，例如 Hyperledger 的实例 印地[129]。 应用示例：KYC： 去中心化身份有望作为一种手段 简化 blockchains 上金融应用程序的要求，同时提高用户体验 隐私。它可以帮助解决两个挑战，即反洗钱/了解你的客户 (AML / KYC) 法规下的认证和合规义务。 许多国家的反洗钱法规要求金融机构（和其他企业）建立并验证与其进行交易的个人和企业的身份。 他们执行交易。 KYC 是金融机构的一个组成部分 更广泛的反洗钱政策，通常还涉及监控用户行为和资金流动等。 KYC 通常涉及用户以某种形式呈现身份凭证（例如， 进入在线网络表单，在用户面前举起身份证件 在视频会议等）。安全创建和呈现去中心化凭证 原则上在几个方面可能是一个有益的替代方案，即：（1） KYC 流程对于用户和金融机构来说更加高效，因为一旦 获得证书后，可以无缝地向任何金融机构出示； (2) 通过妥协减少身份盗窃的机会，从而减少欺诈 个人身份信息 (PII) 和视频验证过程中的欺骗；和 (3) 由于用户保留控制权，降低金融机构 PII 泄露的风险 他们自己的数据。 考虑到金融机构因 AML 合规失败而支付的数十亿美元罚款，以及许多金融机构每年在 KYC 上花费数百万美元，改进措施可以为金融机构带来可观的节省 并且，推而广之，对于消费者[196]。虽然传统金融业发展缓慢 为了采用新的合规工具，DeFi 系统越来越多地采用它 [43]。 应用示例： 抵押贷款不足： 大多数 DeFi 应用程序 如今的支持贷款仅源自完全抵押贷款。这些是贷款 对于存入价值超过贷款价值的加密货币资产的借款人。 最近，人们对 DeFi 社区通常所说的抵押不足贷款产生了兴趣。相比之下，这些贷款需要相应的抵押品 其价值小于贷款本金的价值。抵押贷款不足 类似于传统金融机构通常发放的贷款。而不是依靠 他们以存入的抵押品作为贷款偿还的保证，而是以贷款为基础 对借款人信用记录的决定。 7 此转换依赖于分布式伪随机函数 (PRF)。抵押不足的贷款是 DeFi 贷款市场的一个新兴但不断增长的部分。他们依赖于传统金融所采用的机制 机构，例如法律合同 [91]。是他们成长的必备条件 将能够以提供强大完整性的方式向 DeFi 系统提供有关用户信用度的数据（传统贷款决策的关键因素），即 保证数据正确。 启用 DON 的去中心化身份系统将使潜在借款人能够 生成高保证的凭证，证明其信誉度，同时保留 敏感信息的机密性。具体来说，借款人可以生成这些 基于权威在线来源记录的凭据，同时仅公开 数据由 DON 证明，而不暴露其他潜在敏感数据。对于 例如，借款人可以生成一个凭证，表明她的信用评分 信用局集合超过特定阈值（例如 750），但未透露她的信息 精确的分数或她记录中的任何其他数据。此外，如果需要，此类凭证 可以匿名生成，即用户名可以被视为敏感数据 并且其本身不会暴露于 oracle 节点或她的去中心化凭证中。凭证 它本身可以在链上或链下使用，具体取决于应用程序。 总之，借款人可以向贷方提供有关其信用的重要信息 历史具有很强的完整性，并且没有暴露不必要的敏感信息的风险 数据。 借款人还可以提供各种其他保密凭证 有助于做出贷款决策。例如，凭证可以证明借款人的 拥有（链下）资产，正如我们在下一个示例中所示。 应用示例： 认证： 许多司法管辖区限制可以出售未注册证券的投资者类别。例如，在美国，SEC D 条例规定，要获得此类投资机会的认可， 个人必须拥有 100 万美元的净资产，满足某些最低收入要求，或具有某些专业资格 [209, 210]。目前的认证 流程繁琐且低效，通常需要来自以下机构的证明信 会计师或类似的证据。 去中心化的身份系统将使用户能够从以下位置生成凭证 证明符合认可的现有在线金融服务账户 法规，促进更高效和保护隐私的 KYC 流程。 的 此外，DECO 和 Town Crier 的隐私保护特性将允许这些 生成的凭证具有强有力的完整性保证，而不会直接泄露用户财务状况的详细信息。例如，用户可以生成凭证 证明她的净资产至少为 100 万美元，且无需透露任何其他信息 有关她的财务状况的信息。 4.4 优先频道 优先通道是一项有用的新服务，可以使用 DON 轻松构建。他们的
目标是在主链上及时交付精选的高优先级交易 在网络拥塞期间。优先通道可以被视为一种形式 区块空间上的期货合约，因此作为一种加密商品，这个术语是作为一部分创造的 芝加哥项目 [61, 136]。 优先通道专门用于矿工启用基础设施服务，例如 oracles、合约的治理功能等，而不是用于金融交易等普通用户级活动。 事实上，按照这里的设计，优先 网络中不到100%的算力实施的通道只能 对交货时间提供宽松的限制，防止其用于高度依赖速度的 目标，例如抢先交易。 图 10：优先通道是矿工 M 的保证，或者更一般地说，是矿工 M 的保证 一组矿工 M——向用户 U 表示她的交易 τ 将在 D 块内被开采 包含在内存池中。合约 SC 可以使用 DON 监控来强制执行 频道的服务条款。 优先通道采用一个或一组矿工之间协议的形式 提供通道的（或矿池）M和支付访问费用的用户U。 M 同意当 U 向内存池提交交易 τ 时（无论 Gas 价格如何，但预先商定的 Gas 限制），M 会将其放在接下来的 D 区块内的链上。8 图 10 示意性地描述了这个想法。 优先通道合约说明： 优先级信道可以被实现为 混合 smart contract 大致如下。我们让 SC 表示 MAINCHAIN 上的逻辑 以及 exec 的 DON 上的内容。 SC 接受来自 U. A 的存款/股份 \(d from M and an advance payment \)p DON 可执行文件 exec 监视内存池，在交易放置时触发 如果U提交了M挖矿的交易，它会向SC发送成功消息 服务失败时的及时方式和失败消息。 SC 在收到成功消息后将付款 $p 发送给 M，并发送所有剩余资金， 包括 $d，如果收到失败消息，则发送给 U。成功终止后， 将存款 $d 释放给 M。 矿工M当然可以同时向多个矿工提供优先通道 用户可以与 U 打开优先通道以接收预先商定数量的消息。 4.5 保密 DeFi / Mixicles 如今，DeFi 应用程序 [1] 为用户提供的保密性几乎为零：所有交易在链上都是可见的。各种基于零知识的方法，例如[149, 217]， 可以提供交易隐私，并且 TEF 足够通用来支持它们。但是 这些方法并不全面，例如，通常不会隐藏 交易所基于的资产。 我们最终打算在 DONs 中支持的广泛计算工具将 通过多种不同方式实现隐私保护，可以弥补此类差距，有助于补充其他系统的隐私保证。例如，Mixicles，一种由 Chainlink 实验室研究人员 [135] 提出的保密 DeFi 工具，可以隐藏 支持金融工具的资产类型，非常自然地适合 DON 框架。 Mixicles 最容易解释为它们用于实现简单的二进制文件 选项。 二元期权是一种有两个用户的金融工具，我们将 请参阅此处以与 [135] 作为玩家保持一致，对有两种可能的赛事进行投注 结果，例如资产是否在预先指定的时间超过目标价格。 下面的例子说明了这个想法。 示例 2. Alice 和 Bob 是基于资产价值的二元期权的参与方 称为卡罗尔的泡沫代币（CBT）。 Alice 打赌 CBT 的市场价格为 时间 T = 2025 年 6 月 21 日中午至少 250 美元；鲍勃打赌相反。每个玩家 在预定期限内存入 100 ETH。获胜位置的玩家 收到 200 ETH（即收益 100 ETH）。 8D当然必须足够大，以保证M能够符合高概率。 对于 例如，如果M控制网络中20%的算力，它可能会选择D = 100，确保 失效概率为 ≈2 × 10−10，即小于十亿分之一。给定现有的 Chainlink oracle 网络 O，很容易实现智能 实现例2协议的合约SC，两个玩家各自存款 100 ETH 为 SC。 T 之后的某个时间，查询 q 被发送到 O 请求价格 r CBT 在 T.O 时间向 SC 发送该价格的报告 r。 SC然后将钱发送给Alice 如果 r ≥250，则 Bob 如果不是。然而，这种方法揭示了链上的 r——使其变得容易 让观察者推断出二元期权背后的资产。 在 Mixicles 的术语中，从概念上思考结果是有帮助的 SC 就 Switch 而言，它传输作为谓词计算的二进制值 开关（r）。在我们的示例中，如果 r ≥250，则 switch(r) = 0；鉴于此结果，爱丽丝获胜。 否则 switch(r) = 1 并且 Bob 获胜。 DON 可以通过运行可执行文件将基本 Mixicle 实现为混合合约 exec 计算 switch(r) 并将其在链上报告给 SC。我们展示这个结构 如图 11 所示。 图 11：示例 2 中的基本 Mixicle 图表。为以下内容提供链上保密性： 报告 r，因此二元期权的基础资产 oracle 发送到 仅通过 Switch 签订二进制值 switch(r) 合约 SC。 我们在附录 C.3 中指定了一个适配器 ConfSwitch，可以轻松实现这一点 DON 的目标。 ConfSwitch 背后的基本思想非常简单。而不是报告 r 值，ConfSwitch 仅报告二进制开关值 switch(r)。 SC 可以 旨在仅基于 switch(r) 和 switch(r) 本身进行正确支付 没有透露有关标的资产（在我们的示例中为 CBT）的信息。另外， 通过将密文放在账本上的 (q, r) 上，并使用 pkaud 的公钥进行加密 作为审计员，适配器 ConfSwitch 创建保密审计跟踪。 为了简单起见，我们在这里选择的基本 Mixicle 只隐藏了 在我们的示例中，二元期权背后的资产和赌注。一个成熟的 Mixicle [135] 可以 提供两种形式的保密性。它向观察者隐瞒了：（1）发生了什么事件 玩家对（即 q 和 r）下注，还对 (2) 哪位玩家赢得了赌注。 由于 Mixicles 是在主链上执行的，因此任一玩家都需要中继 switch(r) 从 DON 到 MAINCHAIN，或者可以创建一个可执行的 exec
由 ConfSwitch 输出触发并调用另一个适配器将 switch(r) 发送到 主链。 第三种微妙的保密方式也值得考虑。在 ConfSwitch 的基本实现中，O 在 DON 上运行适配器，从而学习 资产——在我们的例子中是 CBT——以及二元期权的本质。正如所讨论的 然而，在附录 C.3 中，还可以使用 DECO 或 Town Crier 来 甚至向 O 隐瞒此信息。在这种情况下，O 不会了解更多信息 而非 SC 的公共观察员。 有关 Mixicles 的更多详细信息，我们建议读者参阅 [135]。
الخدمات اللامركزية التي تم تمكينها من خلال اللامركزية
شبكات أوراكل لتوضيح مدى تعدد استخدامات DONs وكيفية تمكينها لمجموعة من الخدمات الجديدة، نقدم خمسة أمثلة للتطبيقات المستندة إلى DON في هذا القسم ونصفها العقود الهجينة التي تحققها: (1) إثبات الاحتياطيات، وهو شكل من أشكال الخدمة عبر السلسلة؛ (2) التفاعل مع أنظمة المؤسسة/الأنظمة القديمة، أي إنشاء نظام قائم على البرمجيات الوسيطة طبقة تجريد تسهل تطوير تطبيقات blockchain بأقل قدر ممكن blockchain-رمز أو خبرة محددة؛ (3) الهوية اللامركزية، الأدوات التي تمكن المستخدمين من ذلك الحصول على وثائق الهوية وبيانات الاعتماد الخاصة بهم وإدارتها؛ (4) القنوات ذات الأولوية، خدمة تضمن تضمين معاملات البنية التحتية الحيوية في الوقت المناسب (على سبيل المثال، oracle التقارير) على blockchain؛ و(5) الحفاظ على السرية DeFi، أي الشؤون المالية smart contracts التي تخفي البيانات الحساسة للأطراف المشاركة. هنا، نحن
استخدم SC للإشارة إلى جزء MAINCHAIN من العقد المختلط ووصف DON مكون بشكل منفصل أو من حيث exec القابل للتنفيذ. 4.1 إثبات الاحتياطيات بالنسبة للعديد من التطبيقات، من المفيد ترحيل الحالة بين أو بين blockchains. أ التطبيق الشائع لمثل هذه الخدمات هو تغليف العملات المشفرة. عملات ملفوفة من هذا القبيل نظرًا لأن WBTC [15] أصبحت أحد الأصول الشائعة في التمويل اللامركزي (DeFi). هم تتضمن إيداع الأصل الداعم "المغلف" على مصدره blockchain MAINCHAIN(1) وإنشاء token مطابق على هدف مختلف blockchain MAINCHAIN(2). على سبيل المثال، WBTC هو ERC20 token على Ethereum blockchain الذي يتوافق إلى BTC على Bitcoin blockchain. نظرًا لأن العقود الموجودة على MAINCHAIN(2) ليس لها رؤية مباشرة في MAINCHAIN(1)، يجب عليهم الاعتماد صراحةً أو ضمنًا على oracle للإبلاغ عن رواسب التغليف الأصل في smart contract، مما يؤدي إلى إنتاج ما يسمى أحيانًا إثبات الاحتياطيات. في WBTC [15]، على سبيل المثال، يحتفظ الحافظ BitGo بـ BTC ويصدر WBTC، مع Chainlink شبكة تقدم إثباتات الاحتياطي [76]. يمكن لـ DON أن يقدم في حد ذاته إثباتًا للاحتياطيات. مع DON، فمن الممكن للذهاب أبعد من ذلك. يستطيع DON إدارة الأسرار، ومن خلال استخدام المحولات المناسبة، يمكن التعامل على أي blockchain المطلوب. وبالتالي، من الممكن أن يقوم DON بالتصرف كواحد من بين عدد من أمناء الحفظ - أو حتى كوصي وحيد لا مركزي - لـ أصل ملفوف. وبالتالي يمكن أن يكون DONs بمثابة منصة لتعزيز أمان الخدمات الحالية التي تستخدم إثباتات الاحتياطيات. على سبيل المثال، لنفترض أن MAINCHAIN(1) هو Bitcoin وأن MAINCHAIN(2) هو Ethereum. في MAINCHAIN(2)، يصدر عقد SC tokens الذي يمثل BTC المغلف. DON يتحكم في عنوان عنوان BTC(1) DON. لتغليف BTC، يرسل المستخدم U X BTC منه العنوان(1) ش إلى العنوان (1) DON مع عنوان العنوان الرئيسي (2) MAINCHAIN(2)(2) ش . شاشات DON العنوان(1) DON عبر محول إلى MAINCHAIN(1). عند ملاحظة إيداع U، مع تأكيد عالي الاحتمال بدرجة كافية، فإنه يرسل رسالة إلى SC عبر محول إلى مينشين(2). توجه هذه الرسالة SC إلى سك X tokens لـ addr(2) ش . لكي تقوم U بإصدار X tokens، يحدث العكس. على MAINCHAIN(1)، ومع ذلك، العنوان(1) DON يرسل X BTC إلى العنوان(1) U (أو إلى عنوان آخر، إذا طلب المستخدم ذلك). يمكن بالطبع تكييف هذه البروتوكولات للعمل مع البورصات، وليس بشكل مباشر مع المستخدمين. 4.2 التفاعل مع أنظمة المؤسسات / الأنظمة القديمة يمكن أن تكون DONs بمثابة جسور بين blockchains وفيما بينها، كما في مثال الإثبات من الاحتياطيات، ولكن الهدف الآخر هو أن تكون بمثابة جسور ثنائية الاتجاه بينهما blockchains والأنظمة القديمة [176] أو blockchain الأنظمة المشابهة مثل البنك المركزي العملات الرقمية [30]. تواجه الشركات عددًا من التحديات في ربط أنظمتها الحالية و العمليات للأنظمة اللامركزية، بما في ذلك:• مرونة سلسلة الكتل: تتغير أنظمة سلسلة الكتل بسرعة. قد تواجه المؤسسة المظهر الجديد السريع أو ترتفع شعبيتها blockchains يرغب الأطراف المقابلة في إجراء المعاملات، ولكن ليس لدى المؤسسة أي منها الدعم في البنية التحتية القائمة. بشكل عام، ديناميكية blockchains هي التي تصنع فمن الصعب على المؤسسات الفردية أن تظل على اطلاع على النظام البيئي الكامل. • موارد التطوير الخاصة بـ Blockchain: بالنسبة للعديد من المؤسسات، يعد توظيف أو احتضان الخبرات المتطورة blockchain أمرًا صعبًا، لا سيما في ضوء تحدي خفة الحركة. • إدارة المفتاح الخاص: تتطلب إدارة المفاتيح الخاصة لـ blockchain أو العملات المشفرة خبرة تشغيلية متميزة عن تلك الخاصة بالأمن السيبراني التقليدي الممارسات وغير متاحة للعديد من الشركات. • السرية: تخشى الشركات الكشف عن معلوماتها الحساسة وملكيتها البيانات على السلسلة. لمعالجة الثلاثة الأولى من هذه الصعوبات، يمكن للمطورين ببساطة استخدام DON كطبقة وسيطة آمنة لتمكين أنظمة المؤسسة من القراءة منها أو الكتابة إليها blockchains. يمكن لـ DON تجريد الاعتبارات الفنية التفصيلية مثل ديناميكيات الغاز، وإعادة تنظيم السلسلة، وما إلى ذلك، لكل من المطورين والمستخدمين. بواسطة من خلال تقديم واجهة blockchain مبسطة لأنظمة المؤسسة، يمكن لـ DON بالتالي تبسيط عملية تطوير تطبيقات المؤسسات المدركة blockchain إلى حد كبير، مما يزيل العبء عن المؤسسات المتمثل في الحصول على موارد التطوير المحددة أو احتضانها blockchain. يعد هذا الاستخدام لـ DONs جذابًا بشكل خاص لأنه يمكّن مطوري المؤسسات من ذلك إنشاء تطبيقات العقود الذكية التي تكون blockchain حيادية إلى حد كبير. ونتيجة لذلك، أكبر مجموعة blockchains التي تم تجهيز DON لها لتكون بمثابة برامج وسيطة، أكبر مجموعة blockchains التي يمكن لمستخدمي المؤسسة الوصول إليها بسهولة. المطورين يمكن نقل التطبيقات من blockchains الموجودة إلى تطبيقات جديدة بأقل قدر من التعديل لتطبيقاتهم المطورة داخليًا. ولمعالجة المشكلة الإضافية المتعلقة بالسرية، يمكن للمطورين اللجوء إلى الأدوات التي نقدمها في هذه الورقة ونتوقع نشرها لدعم تطبيقات DON. وتشمل هذه DECO وTown Crier القسم 3.6.2 بالإضافة إلى الحفاظ على السرية تعديلات واجهة برمجة التطبيقات (API) التي تمت مناقشتها في القسم 7.1.2 وعدد من الأساليب الخاصة بالتطبيقات التي تمت تغطيتها في الجزء المتبقي من هذا القسم. يمكن أن توفر أنظمة DON هذه شهادات عالية النزاهة على السلسلة حول حالة نظام المؤسسة دون الكشف عنها بيانات مصدر المؤسسة الحساسة على السلسلة. 4.3 الهوية اللامركزية الهوية اللامركزية هي مصطلح عام لفكرة أن المستخدمين يجب أن يكونوا قادرين على ذلك الحصول على بيانات الاعتماد الخاصة بهم وإدارتها، بدلاً من الاعتماد على أطراف ثالثة للقيام بذلك هكذا. أوراق الاعتماد اللامركزية هي شهادات على سمات أو تأكيدات صاحبها،والتي غالبا ما تسمى المطالبات. يتم توقيع بيانات الاعتماد رقميًا من قبل الكيانات، والتي غالبًا ما تسمى المصدرون، الذين يمكنهم ربط المطالبات بشكل رسمي بالمستخدمين. في معظم المخططات المقترحة، ترتبط المطالبات بمعرف لامركزي (DID)، وهو معرف عالمي لـ مستخدم معين. ترتبط بيانات الاعتماد بمفتاح عام يحمل المستخدم مفتاحه الخاص. وبالتالي يمكن للمستخدم إثبات حيازة المطالبة باستخدام مفتاحه الخاص. الرؤية باعتبارها هوية لامركزية هي المخططات الحالية والمقترحة، على سبيل المثال، [14، 92، 129، 216]، لها ثلاثة قيود شديدة: • عدم التوافق مع التراث: تعتمد أنظمة الهوية اللامركزية الحالية على أ مجتمع السلطات، الذي يطلق عليه جهات الإصدار، لإنتاج بيانات اعتماد DID. لان لا تقوم خدمات الويب الحالية عمومًا بتوقيع البيانات رقميًا، ويجب إطلاق جهات الإصدار كأنظمة ذات أغراض خاصة. لأنه لا يوجد حافز للقيام بذلك دون النظام البيئي اللامركزي للهوية، ينتج عنه مشكلة الدجاجة والبيضة. في غيرها بعبارة أخرى، من غير الواضح كيفية تمهيد النظام البيئي للمصدر. • إدارة المفاتيح غير العملية: تتطلب أنظمة الهوية اللامركزية من المستخدمين القيام بذلك إدارة المفاتيح الخاصة، وهو ما أظهرته تجربة العملات المشفرة ليكون عبئا غير عملي. تشير التقديرات إلى وجود حوالي 4,000,000 Bitcoin فقدت إلى الأبد بسبب فشل إدارة المفاتيح [194]، ويقوم العديد من المستخدمين بتخزين ملفاتهم الأصول المشفرة مع البورصات [193]، مما يقوض اللامركزية. • عدم وجود مقاومة Sybil للحفاظ على الخصوصية: أحد المتطلبات الأمنية الأساسية للتطبيقات مثل التصويت، والتخصيص العادل لـ tokens خلال مبيعات token، وما إلى ذلك هو أن لا يتمكن المستخدمون من تأكيد هويات متعددة. تتطلب مقترحات الهوية اللامركزية الحالية من المستخدمين الكشف عن هوياتهم الحقيقية من أجل تحقيق ذلك مقاومة Sybil، مما يقوض ضمانات الخصوصية المهمة. من الممكن معالجة هذه المشكلات باستخدام مجموعة من لجنة العقد إجراء عمليات حسابية موزعة داخل DON واستخدام أدوات مثل DECO أو Town Crier، كما هو موضح في نظام يسمى CanDID [160]. يمكن لـ DECO أو Town Crier حسب التصميم تشغيل خدمات الويب الحالية دون تعديل إلى جهات إصدار أوراق الاعتماد التي تحافظ على السرية. إنها تمكن DON من التصدير ذات الصلة البيانات لهذا الغرض إلى بيانات اعتماد مع إخفاء البيانات الحساسة التي لا ينبغي ذلك تظهر في بيانات الاعتماد. بالإضافة إلى ذلك، لتسهيل استرداد المفاتيح للمستخدمين، وبالتالي معالجة إدارة المفاتيح المشكلة، DON يمكن أن يسمح للمستخدمين بتخزين المفاتيح الخاصة في نموذج مشترك سري. يمكن للمستخدمين استعادة مفاتيحهم عن طريق إثبات العقد الموجودة في DON - وبالمثل، باستخدام Town Crier أو DECO - القدرة على تسجيل الدخول إلى الحسابات مع مجموعة من موفري الويب المحددين مسبقًا (على سبيل المثال، تويتر، جوجل، فيسبوك). فائدة استخدام Town Crier أو DECO، بدلاً من OAUTH، هي خصوصية المستخدم. تمكّن هاتان الأداتان المستخدم من تجنب الكشف لـ DON معرف مزود الويب - والذي غالبًا ما يمكن استخلاص هويات العالم الحقيقي منه. أخيرًا، لتوفير مقاومة Sybil، كما هو موضح في [160]، من الممكن لـ DON أن إجراء تحويل للحفاظ على الخصوصية لمعرفات العالم الحقيقي الفريدة للمستخدمين (على سبيل المثال، أرقام الضمان الاجتماعي (SSNs)) في المعرفات الموجودة على السلسلة عند تسجيل المستخدم.وبالتالي يمكن للنظام اكتشاف التسجيلات المكررة بدون بيانات حساسة مثل يتم الكشف عن أرقام الضمان الاجتماعي إلى العقد الفردية DON.7 يمكن لـ DON تقديم أي من هذه الخدمات نيابة عن الهوية اللامركزية الخارجية الأنظمة الموجودة على blockchains غير المسموح بها أو المسموح بها، على سبيل المثال، مثيلات Hyperledger إندي [129]. مثال للتطبيق: KYC: الهوية اللامركزية تبشر بالخير كوسيلة لتحقيق ذلك تبسيط متطلبات التطبيقات المالية على blockchains مع تحسين المستخدم الخصوصية. هناك تحديان يمكن أن تساعد في معالجتهما، وهما التزامات الاعتماد والامتثال بموجب لوائح مكافحة غسل الأموال / معرفة عميلك (AML / KYC). تتطلب لوائح مكافحة غسل الأموال في العديد من البلدان من المؤسسات المالية (وغيرها من الشركات) تحديد هويات الأفراد والشركات التي تتعامل معها والتحقق منها. يقومون بالمعاملات. يشكل "اعرف عميلك" (KYC) أحد مكونات المؤسسة المالية سياسة مكافحة غسيل الأموال الأوسع نطاقًا، والتي تتضمن أيضًا عادةً مراقبة سلوكيات المستخدم ومراقبة تدفقات الأموال، من بين أمور أخرى. تتضمن عملية اعرف عميلك (KYC) عادةً تقديم المستخدم لبيانات اعتماد الهوية بشكل ما (على سبيل المثال، الدخول إلى نموذج ويب عبر الإنترنت، مع رفع وثيقة هوية أمام وجه المستخدم في جلسة فيديو، وما إلى ذلك). تأمين إنشاء وعرض بيانات الاعتماد اللامركزية يمكن من حيث المبدأ أن يكون بديلاً مفيدًا في عدة جوانب، وبالتحديد من خلال: (1) التصنيع تعتبر عملية "اعرف عميلك" (KYC) أكثر كفاءة للمستخدمين والمؤسسات المالية، لأنه بمجرد وبعد الحصول على بيانات الاعتماد، يمكن تقديمها بسهولة إلى أي مؤسسة مالية؛ (2) الحد من الاحتيال عن طريق تقليل فرص سرقة الهوية من خلال التسوية ومعلومات التعريف الشخصية (PII) والانتحال أثناء التحقق بالفيديو؛ و (3) تقليل مخاطر تعرض معلومات تحديد الهوية الشخصية للخطر في المؤسسات المالية، مع احتفاظ المستخدمين بالسيطرة من بياناتهم الخاصة. ونظراً للعقوبات التي تبلغ مليارات الدولارات والتي تدفعها المؤسسات المالية بسبب الإخفاق في الامتثال لمكافحة غسل الأموال، وإنفاق العديد من المؤسسات المالية ملايين الدولارات سنوياً على "اعرف عميلك"، فإن التحسينات يمكن أن تحقق وفورات كبيرة للمؤسسات المالية وبالتالي، للمستهلكين [196]. في حين أن القطاع المالي التقليدي بطيء لاعتماد أدوات امتثال جديدة، تتبنى أنظمة DeFi هذه الأداة بشكل متزايد [43]. مثال على التطبيق: القروض غير المضمونة: معظم تطبيقات DeFi التي دعم الإقراض اليوم تنشأ فقط القروض المضمونة بالكامل. هذه هي القروض المقدمة للمقترضين الذين يقومون بإيداع أصول العملات المشفرة بقيمة تتجاوز قيمة القروض. لقد نشأ الاهتمام مؤخرًا بما يشير إليه مجتمع DeFi عمومًا بالقروض غير المضمونة. هذه، على النقيض من ذلك، هي القروض التي لها ضمانات المقابلة أن تكون قيمته أقل من أصل القرض. القروض غير المضمونة تشبه القروض التي غالبا ما تقدمها المؤسسات المالية التقليدية. بدلا من الاعتماد على الضمانات المودعة كضمان لسداد القرض، فإنهم بدلاً من ذلك يعتمدون على الإقراض القرارات المتعلقة بالتاريخ الائتماني للمقترضين. 7 يعتمد هذا التحويل على دالة عشوائية زائفة موزعة (PRF).تشكل القروض غير المضمونة جزءًا ناشئًا ولكنه متنامي من سوق الإقراض DeFi. وهي تعتمد على آليات مثل تلك التي تستخدمها المؤسسات المالية التقليدية المؤسسات، مثل العقود القانونية [91]. مطلب أساسي لنموهم ستكون القدرة على تقديم بيانات حول الجدارة الائتمانية للمستخدم - وهو عامل رئيسي في قرارات الإقراض التقليدية - لأنظمة DeFi بطريقة توفر نزاهة قوية، على سبيل المثال، ضمان البيانات الصحيحة. إن نظام الهوية اللامركزي الذي يدعم DON سيمكن المقترضين المحتملين من إنشاء بيانات اعتماد عالية الضمان تشهد على جدارتها الائتمانية مع الحفاظ عليها سرية المعلومات الحساسة. وعلى وجه التحديد، يمكن للمقترضين إنشاء هذه تعتمد بيانات الاعتماد على سجلات من مصادر موثوقة عبر الإنترنت مع الكشف فقط عن البيانات الموثقة بواسطة DON، دون الكشف عن بيانات أخرى قد تكون حساسة. ل على سبيل المثال، يمكن للمقترض إنشاء بيانات اعتماد تشير إلى أن درجة الائتمان الخاصة به تبلغ درجة تتجاوز مجموعة مكاتب الائتمان حدًا معينًا (على سبيل المثال، 750)، دون الكشف عنها النتيجة الدقيقة أو أي بيانات أخرى في سجلاتها. بالإضافة إلى ذلك، إذا رغبت في ذلك، أوراق الاعتماد هذه يمكن إنشاؤها بشكل مجهول، أي أنه يمكن التعامل مع اسم المستخدم على أنه بيانات حساسة وهي نفسها غير معرضة للعقد oracle أو في بيانات اعتمادها اللامركزية. الاعتماد نفسها يمكن استخدامها على السلسلة أو خارج السلسلة، اعتمادًا على التطبيق. باختصار، يمكن للمقترض تقديم معلومات أساسية للمقرضين بشأن ائتمانهم تاريخ يتمتع بنزاهة قوية ودون التعرض لخطر التعرض لأشياء حساسة وغير ضرورية data. ويمكن للمقترض أيضًا تقديم مجموعة متنوعة من بيانات الاعتماد الأخرى التي تحافظ على السرية مفيدة في اتخاذ قرارات الإقراض. على سبيل المثال، يمكن أن تشهد بيانات الاعتماد على المقترض حيازة الأصول (خارج السلسلة)، كما نوضح في مثالنا التالي. مثال على التطبيق: الاعتماد: تحدد العديد من الولايات القضائية فئة المستثمر التي يمكن بيع الأوراق المالية غير المسجلة لها. على سبيل المثال، في الولايات المتحدة، SEC تنص اللائحة د على أنه لكي يتم اعتمادك لمثل هذه الفرص الاستثمارية، أ يجب أن يمتلك الفرد قيمة صافية قدرها مليون دولار، أو يستوفي بعض متطلبات الحد الأدنى للدخل، أو أن يكون لديه مؤهلات مهنية معينة [209، 210]. الاعتماد الحالي العمليات مرهقة وغير فعالة، وغالبًا ما تتطلب خطاب تصديق من محاسب أو ما شابه ذلك. سيمكن نظام الهوية اللامركزي المستخدمين من إنشاء بيانات الاعتماد من حسابات الخدمات المالية الحالية عبر الإنترنت التي تثبت الامتثال للاعتماد اللوائح التنظيمية، وتسهيل عملية "اعرف عميلك" (KYC) الأكثر كفاءة والحفاظ على الخصوصية. ال علاوة على ذلك، فإن خصائص الحفاظ على الخصوصية الخاصة بـ DECO وTown Crier، ستسمح بذلك سيتم إنشاء بيانات الاعتماد مع ضمان قوي بالنزاهة دون الكشف بشكل مباشر عن تفاصيل الوضع المالي للمستخدم. على سبيل المثال، يمكن للمستخدم إنشاء بيانات اعتماد إثبات أن ثروتها الصافية لا تقل عن مليون دولار دون الكشف عن أي مبلغ إضافي معلومات عن وضعها المالي. 4.4 القنوات ذات الأولوية تعتبر القنوات ذات الأولوية خدمة جديدة مفيدة يسهل إنشاؤها باستخدام DON. بهم
الهدف هو تقديم معاملات مختارة وذات أولوية عالية في الوقت المناسب على MAINCHAIN خلال فترات ازدحام الشبكة. يمكن النظر إلى القنوات ذات الأولوية كشكل من أشكال العقود الآجلة على مساحة الكتلة وبالتالي كسلعة مشفرة، وهو مصطلح تمت صياغته كجزء لمشروع شيكاغو [61، 136]. القنوات ذات الأولوية مخصصة خصيصًا للقائمين بالتعدين لتمكين خدمات البنية التحتية، مثل oracles، ووظائف إدارة العقود، وما إلى ذلك - وليس للأنشطة العادية على مستوى المستخدم مثل المعاملات المالية. في الواقع، كما هو مصمم هنا، أولوية يمكن تنفيذ القناة بأقل من 100% من طاقة التعدين في الشبكة فقط توفر حدودًا فضفاضة على أوقات التسليم، مما يمنع استخدامها بشكل كبير يعتمد على السرعة أهداف مثل الجري الأمامي. الشكل 10: القناة ذات الأولوية هي ضمان من قبل عامل التعدين M - أو بشكل عام أ مجموعة من عمال المناجم M—إلى المستخدم U الذي سيتم تعدين معاملته τ ضمن الكتل D من التضمين في mempool. يمكن لعقد SC استخدام مراقبة DON لفرض شروط خدمة القناة. تأخذ القناة ذات الأولوية شكل اتفاقية بين القائم بالتعدين أو مجموعة من المعدنين (أو مجمعات التعدين) M التي توفر القناة والمستخدم U الذي يدفع رسوم الوصول. يوافق M على أنه عندما يرسل U معاملة τ إلى مجموعة الذاكرة (مع أي سعر للغاز،ولكن بحد الغاز المتفق عليه مسبقًا)، سيضعه M على السلسلة ضمن الكتل D التالية.8 تم توضيح الفكرة بشكل تخطيطي في الشكل 10. وصف عقد قناة الأولوية: يمكن تحقيق القناة ذات الأولوية باعتبارها الهجين smart contract تقريبًا على النحو التالي. نسمح لـ SC بالإشارة إلى المنطق الموجود على MAINCHAIN وذلك على DON بواسطة exec. تقبل SC إيداعًا/حصة \(d from M and an advance payment \)p من الولايات المتحدة DON يقوم exec القابل للتنفيذ بمراقبة مجمع الذاكرة، مما يؤدي إلى تشغيل المعاملة بواسطة U. يرسل رسالة نجاح إلى SC إذا أرسل U معاملة قام M بالتنقيب فيها طريقة في الوقت المناسب ورسالة فشل في حالة فشل الخدمة. ترسل SC الدفع $p إلى M مع إعطاء رسالة نجاح وترسل جميع الأموال المتبقية، بما في ذلك $d، إلى U إذا تلقى رسالة فشل. عند الإنهاء الناجح، فإنه إيداع الإصدارات $d إلى M. يمكن لعامل التعدين M بالطبع توفير قنوات ذات أولوية متعددة في وقت واحد المستخدمين ويمكنهم فتح قناة ذات أولوية مع U لعدد متفق عليه مسبقًا من الرسائل. 4.5 الحفاظ على السرية DeFi / المختلطات اليوم، توفر تطبيقات DeFi [1] القليل من السرية للمستخدمين: جميع المعاملات مرئية على السلسلة. مختلف المناهج القائمة على المعرفة الصفرية، على سبيل المثال، [149، 217]، يمكن أن توفر خصوصية المعاملات، وTEF عام بما يكفي لدعمها. لكن هذه الأساليب ليست شاملة، ولا تخفي، على سبيل المثال، عادة الأصول التي تعتمد عليها الصفقة. المجموعة الواسعة من الأدوات الحسابية التي نعتزم دعمها في النهاية في DONs تمكين الخصوصية بعدد من الطرق المختلفة التي يمكنها سد هذه الثغرات، مما يساعد في استكمال ضمانات الخصوصية للأنظمة الأخرى. على سبيل المثال، يمكن لـ Mixicles، وهي أداة للحفاظ على السرية DeFi اقترحها Chainlink الباحثون في المختبرات [135]، إخفاء نوع الأصل الذي يدعم الأداة المالية، ويتناسب بشكل طبيعي جدًا مع DON إطار العمل. يتم شرح Mixicles بسهولة أكبر من حيث استخدامها لتحقيق ثنائي بسيط الخيار. الخيار الثنائي هو أداة مالية فيها مستخدمان، وسنقوم بذلك قم بالرجوع هنا للتأكد من الاتساق مع [135] كلاعبين، يراهنون على حدث مع احتمالين النتائج، على سبيل المثال، ما إذا كان الأصل يتجاوز السعر المستهدف في وقت محدد مسبقًا أم لا. المثال التالي يوضح الفكرة. مثال 2. أليس وبوب طرفان في خيار ثنائي يعتمد على قيمة الأصل يُسمى رمز فقاعة كارول (CBT). تراهن أليس على أن سعر السوق للـ CBT سيكون عند ما لا يقل عن 250 دولارًا أمريكيًا في الوقت T = ظهر يوم 21 يونيو 2025؛ يراهن بوب على العكس. كل لاعب إيداع 100 ETH في الموعد النهائي المحدد مسبقًا. اللاعب ذو المركز الفائز يتلقى 200 ETH (أي يكسب 100 ETH). يجب أن يكون 8D كبيرًا بما يكفي لضمان توافق M مع الاحتمالية العالية. ل على سبيل المثال، إذا كان M يتحكم في 20% من طاقة التعدين في الشبكة، فقد يختار D = 100، مما يضمن احتمال الفشل ≈2 × 10−10، أي أقل من واحد في المليار.نظرًا لوجود شبكة Chainlink oracle O، فمن السهل تنفيذ شبكة ذكية عقد SC الذي يحقق الاتفاق في المثال 2. يقوم اللاعبان بإيداع كل منهما 100 إيثيريوم في SC. في وقت ما بعد T، يتم إرسال استعلام q إلى O لطلب سعر r يرسل CBT في الوقت T. O تقريرًا بهذا السعر إلى SC. ثم يرسل SC الأموال إلى أليس إذا ص ≥250 وبوب إذا لم يكن كذلك. ومع ذلك، يكشف هذا النهج عن السلسلة، مما يجعل الأمر سهلاً للمراقب لاستنتاج الأصول الكامنة وراء الخيار الثنائي. في مصطلحات Mixicles، من المفيد التفكير بشكل مفاهيمي في النتيجة من SC من حيث المحول الذي ينقل قيمة ثنائية محسوبة كمسند التبديل (ص). في مثالنا، Switch(r) = 0 إذا r ≥250؛ وبالنظر إلى هذه النتيجة، تفوز أليس. وإلا فإن التبديل (ص) = 1 ويفوز بوب. يمكن لـ DON أن يحقق Mixicle أساسي كعقد مختلط عن طريق تشغيل ملف قابل للتنفيذ exec الذي يحسب التبديل (r) ويبلغ عنه في السلسلة إلى SC. نعرض هذا البناء في الشكل 11. الشكل 11: رسم تخطيطي لـ Mixicle الأساسي في المثال 2. لتوفير السرية على السلسلة التقرير r، وبالتالي الأصل الذي يقوم عليه الخيار الثنائي، يرسل oracle إلى عقد SC عبر التبديل فقط مفتاح القيمة الثنائية (ص). لقد قمنا بتحديد محول ConfSwitch في الملحق C.3 الذي يجعل من السهل تحقيق ذلك هدف في DON. الفكرة الأساسية وراء ConfSwitch بسيطة للغاية. بدلا من الإبلاغ القيمة r، تقوم ConfSwitch بالإبلاغ فقط عن قيمة التبديل الثنائي (r). يمكن أن يكون SC مصممة لإجراء الدفع الصحيح بناءً على المفتاح (r) وحده، والمفتاح (r) بمفرده لا يكشف عن أي معلومات حول الأصل الأساسي — CBT في مثالنا. بالإضافة إلى ذلك، عن طريق وضع نص مشفر على (q, r) على دفتر الأستاذ المشفر تحت pkaud، المفتاح العام لـ مدققًا، يقوم المحول ConfSwitch بإنشاء مسار تدقيق يحافظ على السرية. إن Mixicle الأساسي الذي اخترناه للبساطة لوصفه هنا يخفي فقط الأصول والرهان وراء الخيار الثنائي في مثالنا. علبة Mixicle كاملة [135] توفير شكلين من السرية. ويخفي عن الناظرين: (1) ما حدث يراهن اللاعبون على (أي q وr) ولكن أيضًا (2) اللاعب الذي فاز بالرهان. نظرًا لأنه يتم تنفيذ Mixicles على MAINCHAIN، فسيحتاج أي من اللاعبين إلى التتابع قم بالتبديل (r) من DON إلى MAINCHAIN، أو يمكن إنشاء ملف exec قابل للتنفيذ لذلك
يتم تشغيله عند الإخراج بواسطة ConfSwitch ويستدعي محولًا آخر لإرسال المفتاح (r) إليه مينشين. وهناك نوع ثالث دقيق من السرية يستحق النظر فيه أيضًا. في التنفيذ الأساسي لـ ConfSwitch، يقوم O بتشغيل المحول على DON وبالتالي يتعلم الأصول - CBT في مثالنا - وبالتالي طبيعة الخيار الثنائي. كما نوقش ومع ذلك، في الملحق C.3، من الممكن أيضًا استخدام DECO أو Town Crier من أجل قم بإخفاء هذه المعلومات حتى عن O. وفي هذه الحالة، لن يتعلم O المزيد من المعلومات من المراقب العام للSC. لمزيد من التفاصيل حول Mixicles، نحيل القراء إلى [135].
公平测序服务
我们期望 DONs 将提供一项利用其网络、计算和存储功能的重要服务，称为公平排序服务 (FSS)。 尽管 FSS 可能被简单地视为在 DON 框架内实现的应用程序，但我们强调它是一项我们相信在各个领域都有很高需求的服务。 blockchains，我们希望 Chainlink 网络积极支持。 当在公共 blockchain 网络上执行时，当今的许多 DeFi 应用程序 揭示可以被用户利用以谋取自身利益的信息，类似于 现有的内幕泄密和操纵机会普遍存在 市场 [64, 155]。相反，FSS 为公平的 DeFi 生态系统铺平了道路。 FSS 帮助开发人员构建免受市场操纵的DeFi合约 因信息泄露而造成的。鉴于我们在下面强调的问题，FSS 是 对于第 2 层服务特别有吸引力，并且适合此类服务的框架 我们将在第 6 节中讨论。 挑战： 在现有的无需许可的系统中，交易是完全有序的 由矿工自行决定。在许可网络中，validator 节点可能会施加 相同的力量。这是一种在很大程度上未被认识到的短暂集中化形式。 否则分散的系统。矿工可以（暂时）审查其交易 自己的利益[171]或重新排序以最大化自己的收益，这一概念称为可开采价值（MEV）[90]。 MEV 这个术语有一点欺骗性：它并不指代 只考虑矿工可以捕获的价值：一些MEV可以被普通用户捕获。 然而，由于矿工比普通用户拥有更多的权力，MEV 代表了任何实体通过对抗性重新排序可以获得的价值上限 和补充交易插入。即使矿工简单地下令交易 基于费用（gas），无需操纵，用户自己可以操纵gas价格 使他们的交易比那些不太复杂的交易更有优势。 戴安等人。 [90] 记录并量化机器人（而非矿工）采取的方式 利用气体动力学的方式损害当今 DeFi 系统的用户以及如何 MEV 甚至威胁到 blockchain 中底层共识层的稳定性。 交易订单操纵的其他例子也经常出现，例如[50, 154]。新的事务处理方法（例如 rollups）是一种非常有前途的方法 解决高吞吐量 blockchains 的扩展问题。然而，他们并没有解决 MEV的问题。相反，他们将其转移到生成 rollup 的实体。那 实体，无论是 smart contract 的操作员还是提供 (zk-)rollup 的用户 有效性证明，有权订购和插入交易。换句话说，rollups 将 MEV 替换为 REV：汇总可提取值。 MEV 影响即将提交到内存池的交易 但尚未在链上承诺。有关此类交易的信息广泛 在网络中可用。矿工、validators和普通网络参与者可以 因此，利用这些知识并创建相关交易。此外，矿工和 validators 可能会影响他们提交的交易的顺序 并利用这一点为自己谋利。 领导者对共识交易排序施加不当影响的问题 自 20 世纪 90 年代以来，协议在文献中就已为人所知 [71, 190]，但还没有令人满意的 到目前为止，解决方案已在实践中实现[97]。 主要原因是所提出的解决方案（至少直到最近）无法轻易地与公众整合 blockchains，因为它们依赖于交易内容在之后仍然保密 他们的顺序已经确定。 公平测序服务 (FSS) 概述： DONs 将提供去中心化交易排序的工具，并根据依赖项指定的策略来实施它 合同创建者，理想情况下是公平的，而不是让那些希望这样做的参与者受益 操纵交易顺序。这些工具共同构成了 FSS。 FSS 包括三个组成部分。首先是交易监控。在FSS中， O 中的 oracle 节点都监视 MAINCHAIN 的内存池并（如果需要）允许 通过专门的渠道在链下提交交易。二是交易顺序。依赖合约的 O 订单交易中的节点 根据为该合同定义的策略。第三是交易记录。 交易排序后，O中的节点共同将交易发送到 主链。 FSS 的潜在好处包括： • 订单公平性：FSS 包含帮助开发人员确保交易的工具 对特定合同的输入以不会产生不公平的方式排序 对于资源丰富和/或技术精湛的用户来说是有优势的。订购政策 可以为此目的指定网络。 • 减少或消除信息泄漏：通过确保网络参与者无法利用有关即将进行的交易的知识，FSS 可以减少或消除信息泄漏。 消除基于现有信息的抢先交易等攻击 提交交易之前的网络。防止利用此类 泄漏确保依赖于原始未决的对抗性交易 在原始交易提交之前，交易无法进入账本。• 降低交易成本：消除玩家对提交速度的要求 他们的交易为smart contract，FSS可以大大降低交易处理的成本。 • 优先排序：FSS 可以自动给予关键事务特殊优先级 订购。例如，为了防止针对 oracle 的抢先交易攻击 报告，例如 [79]，FSS 可以将 oracle 报告插入交易流中 追溯性地。 FSS 在 DON 中的首要目标是帮助 DeFi 创作者实现公平 金融系统，即不利于特定用户（或矿工）的系统 基于速度、内部知识或执行技术的能力优于其他人 操纵。虽然公平的明确、普遍的概念是难以捉摸的，但完美的公平在 任何合理的感觉都是无法实现的，FSS旨在为开发者提供强大的 一套工具，以便他们能够执行有助于实现 DeFi 设计目标的策略。 我们注意到，虽然 FSS 的主要目标是充当公平排序服务 DON 的目标主链，某些与 FSS 相同的公平性需求 保证也适用于在其中运行的（去中心化）协议 DON 派对。因此，FSS 可以更广泛地视为由子集提供的服务 DON 节点不仅可以对主链用户发送的交易进行公平排序 还包括其他 DON 节点之间共享的事务（即消息）。在本节中， 我们将主要关注对主链交易进行排序的目标。 章节组织：在第 5.1 节中，我们描述了推动 FSS 设计的两个高级应用程序：防止 oracle 报告的抢先交易和防止 用户交易的抢先交易。然后我们提供有关 FSS 设计的更多细节 在第 5.2 节中。第 5.3 节描述了公平排序保证和手段的示例 来实现它们。最后，第 5.4 节和第 5.5 节讨论了网络级威胁 分别针对网络洪水和女巫攻击的此类政策和解决方法 攻击。 5.1 抢先交易问题 为了解释 FSS 的目标和设计，我们描述了两种常见的抢先交易形式 攻击和现有解决方案的局限性。 抢先交易是一个类的例子 交易排序攻击：有许多相关的攻击，例如我们没有涵盖的反向运行和夹心（前端运行加反向运行）[237] 在这里，但 FSS 也可以帮助解决这个问题。 5.1.1 Oracle抢先交易 oracles 的传统角色是向 blockchain 应用程序提供链下数据 成为抢先交易攻击的天然目标。考虑使用 oracle 提供各种价格源的常见设计模式 到链上交易所：oracle 定期（例如每小时）收集价格数据 不同的资产并将它们发送到交换合约。这些价格数据交易 呈现明显的套利机会：例如，如果最新的 oracle 报告列出 某些资产的价格要高得多，对手可能会抢先发送 oracle 报告给 购买资产并在 oracle 的报告处理完毕后立即转售。 减速带和追溯定价： oracle 抢先交易问题的自然解决方案是给予 oracle 报告高于其他交易的特殊优先级。对于 例如，可以以高额费用发送 oracle 报告，以鼓励矿工处理 首先是他们。但如果套利机会很高，这并不能阻止抢先交易， 也无法阻止矿工自己套利。 因此，一些交易所采取了更重量级的“减速带”，例如在处理之前将用户交易排队等待多个区块 或在新的 oracle 报告到达时追溯调整价格。这些解决方案的缺点是它们增加了交换实现的复杂性， 增加存储需求，从而增加交易成本，并破坏用户体验，因为资产交换只有在相当长的一段时间后才会得到确认。 捎带： 在继续讨论 FSS 之前，我们先讨论搭载，这是一种非常简单且 oracle 抢先交易问题的优雅解决方案。不适用于地址 然而，在其他情况下却是抢先交易。 简而言之，不是定期向链上合约发送报告，而是 oracles 发布用户在购买或出售时附加到其交易中的签名报告 链上资产。然后交易所只需检查报告是否有效且最新 （例如，oracle 可以签署报告有效的一系列区块），并提取 从中获取相关价格。 与上述“减速带”相比，这种简单的方法具有许多优点 方法：（1）交易合约不需要保存喂价状态，这应该 导致交易成本降低； (2) 由于 oracle 报告是根据需要发布到链上的，因此 oracle 可以生成更频繁的更新（例如每分钟），从而 最大限度地减少抢先报告带来的套利机会9； (3)交易可以 立即得到验证，因为它们始终包含新鲜的价格信息。 然而，这种方法并不完美。首先，这个搭载解决方案将 交易所用户有责任获取最新的 oracle 报告并将其附加到他们的 交易。其次，虽然捎带交易最大限度地减少了套利机会，但它不能 在不影响链上合约活跃性的情况下完全防止它们。确实，如果一个 oracle 报告在某个区块号 n 之前有效，然后将交易提交到区块 n + 1 将需要新的有效报告。由于传播的固有延迟 从 oracles 向用户报告，对块 n + 1 有效的新报告将具有 9只有当资产价格的可利用差异超过无关的资产价格差异时，套利才有价值。 买卖资产所需的费用，例如矿工和交易所收取的费用。在区块 n + 1 被开采之前的某个时期（例如在区块 n −k 处）公布，从而 创建一个包含 k 个区块的序列，其中存在短暂的套利机会。我们 现在描述 FSS 如何克服这些限制。 通过 FSS 对 oracle 报告进行优先级排序： FSS 可以解决 oracle 抢先交易问题 通过构建上述捎带解决方案来解决问题，但推动额外的 使用 oracle 向去中心化预言机网络报告增强交易的工作。 在较高层面上，oracle 节点收集用于链上交换的交易， 就实时价格反馈达成一致，并将价格反馈连同收集的交易一起发布到主链合约中。从概念上讲，人们可以将这种方法视为一种 “数据增强事务批处理”，其中 oracle 确保最新的 喂价总是添加到交易中。 FSS 解决方案可以对交易所用户透明地实施，并且 正如我们在第 5.2 节中更详细描述的那样，对合约逻辑的更改最小。确保 新的 oracle 报告始终优先于用户交易只是一个例子 FSS 可以采用和执行的订购政策。社会保障基金秩序保障政策 第 5.3 节更概括地描述了公平性。 5.1.2 抢先交易的用户交易 我们现在转向通用应用程序中的抢先交易，其中上述防御方法 不起作用。可以通过以下场景概括地捕获该问题： 对手看到一些用户交易 tx1 发送到 P2P 网络并注入 它自己的对抗性交易 tx2，以便 tx2 在 tx1 之前被处理（例如，通过支付 更高的交易费用）。例如，这种抢先交易在 利用 DeFi 系统 [90] 中的套利机会的机器人，并影响了 各种去中心化应用程序[101]。建立公平的交易秩序 在 blockchain 上处理可以解决此问题。 更根本的是，有时甚至没有必要查看 tx1 的详细信息，并且 仅仅知道 tx1 的存在就可能让对手通过其抢先交易 tx1 拥有 tx2 并欺骗创建 tx1 的无辜用户。例如，用户可能 众所周知会定期交易特定资产。防止此类攻击需要 还可以避免元数据泄漏的缓解措施[62]。这个问题的一些解决方案 存在，但它们会带来延迟和可用性问题。 通过 FSS 从网络订单到最终订单： 抢先交易的机会 出现的原因是现有系统没有机制来确保执行的顺序 链上出现的交易尊重事件顺序和信息流 网络之外。这代表了由于在 blockchain 上实施应用程序（例如交易平台）的缺陷而产生的问题。理想情况下，人们会 确保事务按照原来的顺序在 blockchain 上提交 创建并发送到 blockchain 的 P2P 网络。但自从 blockchain 网络
是分布式的，无法捕获这样的订单。 FSS因此引入了机制 防止违反公平性，而这种违反公平性只是因为分布式 blockchain 网络的性质。 5.2 社会保障计划详情 图 12： 具有两种不同交易路径的订单公平内存池： 直接和 基于内存池。 图 12 显示了 FSS 的总体示意图。为了确保公平，提供 FSS 的 DON 必须干扰进入主链的交易流程。 可能需要对客户端、主链上的 smart contracts 或两者进行调整。在较高的层面上，FSS 的交易处理可以分解为三个部分 阶段，描述如下： (1) 交易监控； (2) 交易排序；和 (3) 交易过帐。根据用于事务排序的排序方法，需要额外的协议步骤，如下一节所述。 5.2.1 交易处理 交易监控： 我们设想 FSS 监控采用两种不同的方法 发往特定 smart contract 的用户交易，直接且基于内存池： • 直接：直接方法在概念上是最简单的，但需要进行更改 用户客户端，以便交易直接发送到去中心化预言机网络节点，而不是主链的节点。 DON 收集 用户交易发往特定的 smart contract SC，并根据 关于某些订购政策。然后 DON 将有序交易发送到 主链上的smart contract。一些排序机制还需要直接方法，因为创建交易的用户必须以加密方式 在将其发送到 FSS 之前对其进行保护。 • 基于内存池：为了促进 FSS 与旧客户端的集成，DON 可以使用Mempool Services（MS）来监控主链的mempool并收集 交易。 直接传输可能是许多合同的首选实施方式， 我们相信它在许多情况下应该相当实用。 我们简要讨论如何对现有的 DApp 进行最小程度的修改以支持 直接传输，同时保持良好的用户体验。我们描述方法 使用 Ethereum 和 MetaMask [6] 因为这些是当今最流行的选择，但是 上述技术应该扩展到其他链和钱包。最近的 Ethereum 改进提案，“EIP-3085：钱包添加Ethereum链RPC方法”[100]， 将可以轻松定位自定义 Ethereum 链（使用与 MAINCHAIN 的（以防止来自 MetaMask 和其他基于浏览器的钱包的重放攻击）。实施此提案后，一个 DApp 寻求使用 DON 只需向其前端添加一个方法调用即可直接传输 交易到任何暴露 Ethereum 兼容 API 的 DON 。与此同时， “EIP-712：Ethereum 类型化结构化数据 hash 处理和签名” [49] 提供了一个稍微 涉及更多但已经广泛部署的替代方案，DApp 用户可以使用 MetaMask 用于签署指定 DON 交易的结构化数据。 DApp可以发送 此签名的结构化数据到 DON。 最后，我们注意到混合方法也是可能的。 例如，遗产 客户可以继续将交易发送到主链的内存池中，但至关重要 交易（例如 oracle 报告）直接发送到 DON 节点（特别是 提供 oracle 报告（例如喂价更新）的节点集和节点集 提供的 FSS 可能重叠或相同）。 交易排序： FSS 的主要目的是保证用户交易按照预先定义的策略进行排序。这项政策的性质将 取决于应用程序的需求以及它所处理的不公平交易订单的类型 旨在预防。 由于 DON 上的 FSS 能够处理数据并维护本地状态， 他们可能会根据所提供的信息强加任意排序策略 可在 oracles 处购买。 特定的排序策略及其实现将在随后的 5.3 节中讨论。交易过账： 在收集并排序用户交易（直接从用户接收或从内存池收集）后，DON 将这些交易发送到主链。因此，DON 与主链的交互仍然存在 受主链矿工管辖的（可能不公平的）交易排序。为了利用去中心化交易排序的好处，目标智能 因此，合同 SC 的设计必须将 DON 视为“一等”公民。我们 区分两种方法： • DON-only 合约：最简单的设计选项是让主链变得智能 合约SC仅接受已由DON处理的交易。这个 确保 smart contract 按照建议的顺序处理交易 DON，但事实上限制 smart contract 在基于委员会的系统中运行（即 DON 委员会现在拥有持续的权力来确定 交易的排序和包含）。 • 双级合约：首选、更细粒度的设计，主链智能 合约 SC 接受源自 DON 和遗留系统的交易 用户，10 但对 DON 未处理的交易设置了传统的“减速带”。例如，可以处理来自 DON 的交易 立即，而遗留事务则由 smart contract “缓冲” 一段固定的时间。其他防止抢先交易的标准机制 例如提交-显示方案或 VDF [53] 也可以应用于遗留 交易。这确保了 DON 有序的交易确实得到处理 同意该命令，但没有赋予 DON 不必要的审查权力 交易。 由于 FSS 强加的交易排序要求交易在“链外”聚合，因此该解决方案自然地与其他旨在降低链上处理成本的聚合技术相结合。例如，收集后 对交易进行排序后，DON 可以将这些交易作为 单个“批量交易”（例如 rollup），从而减少总交易 费。 执行交易指令： 无论是仅 DON 还是双级设计， 主链smart contract SC和DON必须共同设计，以保证DON的交易顺序得到维护。在这里，我们也设想了不同的 设计选项： • 序列号：DON 可以为每笔交易附加一个序列号，并将这些交易发送到主链的内存池中。 主要 10如果 DON 的交易监控基于内存池，则遗留交易必须与 DON 交易区分开来，以便它们不会被 DON 收集，例如通过特殊标签 嵌入交易中或通过指定特定的 Gas 价格，例如DON 交易有gas 价格低于一定阈值。链 smart contract SC 忽略“无序”到达的交易。我们 请注意，在这种设置中，主链矿工可以决定忽略 DON 的 交易排序，从而导致交易失败。通过保持 SC 的（昂贵的）状态来强制执行正确的交易排序是可能的，某种程度上 类似于 TCP 如何缓冲无序数据包直到丢失的数据包被删除 收到。 • 事务nonces：对于许多blockchain，特别是Ethereum， 上述序列编号方法可以利用内置事务 nonces 来 强制主链smart contract SC按顺序处理交易。 在这里，DON 节点通过单个主链帐户将交易发送到主链，并受到 DON 节点之间共享的密钥的保护。该帐户的 交易 nonce 确保交易以正确的顺序进行挖掘和处理。 • 聚合交易：DON 可以聚合rollup 中的多个交易。 （或类似于 rollup 的捆绑包）。主链 smart contract 需要 旨在处理此类聚合交易。 • 使用主链代理聚合交易：这里，DON 类似地将交易捆绑到主链的一个“元交易”中，但依赖于 自定义代理 smart contract 来解压交易并将其转发到 目标合同 SC。该技术对于遗留兼容性很有用。元交易的行为类似于 rollup，但不同之处在于它们由未压缩的 一次发布到主链的交易列表。 最后一种设计的优点是无缝支持用户交易 在达到 DON 的目标之前，它们本身通过主链合约进行代理 合同 SC。例如，考虑将交易发送到某个钱包的用户 合约，该合约又向 SC 发送内部交易。分配序列 此类交易的编号会很棘手，除非用户的钱包合约是 专门设计用于将每笔内部交易的序列号转发至 SC。 同样，此类内部交易也无法轻松聚合成直接发送到 SC 的元交易。我们讨论进一步的设计考虑 以下此类代理交易。 5.2.2 事务原子性 到目前为止，我们的讨论隐含地假设交易与单个交易交互 链上 smart contract （例如，用户向交易所发送购买请求）。然而，在 在 Ethereum 等系统中，单个交易可以由多个内部交易组成，例如，一个 smart contract 调用另一个合约中的函数。下面，我们 描述了两种对“多合约”交易进行排序的高级策略，同时 保留事务的原子性（即，由 交易全部按照正确的顺序执行，或者根本不执行）。强原子性： 最简单的解决方案是将 FSS 直接应用于整个“多合约”交易，如上所述。也就是说，用户发送他们的交易 进入网络，FSS 监控、排序并将这些交易发布到 主链。 这种方法在技术上很简单，但有一个潜在的限制：如果用户 交易与两个合约 SC1 和 SC2 交互，两者都希望公平杠杆 排序服务，那么这两个合约的排序策略必须一致。也就是说，给定两个不同的交易 tx1 和 tx2，每个交易都与之交互 SC1 和 SC2 都不能出现 SC1 的策略先排序 tx1 后排序 tx2 而 SC2 的政策规定了相反的顺序。 对于绝大多数感兴趣的场景，我们预计不同合约采用的排序策略将是一致的。例如，SC1 和 SC2 可能希望交易按照其到达内存池的大概时间进行排序， SC1 可能还希望始终首先交付某些 oracle 报告。作为 后者oracle报告交易不与SC2交互，政策一致。 弱原子性： 就其全面的普遍性而言，FSS 可以应用于个人层面 内部交易。 考虑 tx = { txpre, txSC, txpost} 形式的交易，由一些初始的 交易〜txpre，这会导致内部交易〜txSC到SC，这反过来 发出内部交易〜txpost。 SC 的排序策略可能决定如何 内部交易 ~txSC 必须相对于发送的其他交易进行排序 到 SC，但保留 txpre 和 txpost 的排序顺序。 鉴于 Ethereum 等系统中事务处理的本质，开发针对特定内部事务的排序服务并不简单。通过专门设计的合约 SC，这可以通过以下方式实现： 1. 交易tx被发送到网络并被挖掘（没有任何排序） 由 FSS 执行）。执行初始的 txpre，并调用 txSC。 2. SC不执行~txSC并返回。 3. FSS 监控 SC 的内部事务，对它们进行排序，然后将它们发回 到 SC（即，通过将交易 ~txSC 直接发送到 SC）。 4. SC 处理从 FSS 接收到的交易 txSC，并发出由 txSC 产生的内部交易 txpost。 使用这种方法，事务不会完全原子地执行（即原始的 交易 tx 被分解为多个链上交易），但是 内部交易被保留。 该解决方案存在许多设计限制。例如，~txpre 不能 假设~txSC 和~txpost 将被执行。此外，SC 的设计应使得 代表某个用户执行交易 〜txSC 和 〜txpost，即使它们是由 FSS 发送。由于这些原因，更粗粒度的“强原子性”解决方案 以上在实践中可能是更可取的。 为了尊重更复杂的依赖关系，涉及多个事务和 它们各自的内部事务，FSS的事务调度程序可能包含 类似于关系型事务管理器中的复杂功能 数据库管理器。 5.3 公平交易排序 这里我们讨论交易排序公平性的两个概念以及相应的实现，这可以通过 FSS 来实现： 基于策略的顺序公平性 FSS 和安全因果关系保存强加的，这需要在 FSS 中使用额外的加密方法。 订单公平性： 顺序公平是共识协议中时间公平的概念 这首先是由 Kelkar 等人正式提出的。 [144]。 凯尔卡等人。旨在实现一种自然政策形式，其中交易是 根据 DON （或 P2P 网络， 对于基于内存池的 FSS）。然而，在去中心化系统中， 节点可能会看到事务以不同的顺序到达。 建立总订单 所有交易的问题正是底层共识协议所解决的问题 主链。 凯尔卡等人。 [144] 因此引入一个较弱的概念，可以 在去中心化预言机网络的帮助下实现，称为“区块订单公平性”。 它将 DON 在某个时间间隔内收到的交易分组为 “块”并同时在同一位置插入该块的所有交易 （即高度）进入主链。因此它们被排序在一起并且必须是可执行的 并行进行，而不会在它们之间造成任何冲突。 粗略地说，顺序公平性表明，如果大部分节点在 τ2 之前看到事务 τ1，那么 τ1 将在 τ2 之前或在同一块中排序。通过施加如此粗略的 交易订单的粒度，抢先交易和其他与订单相关的攻击的机会大大减少。 凯尔卡等人。提出一系列名为 Aequitas [144] 的协议，该协议解决了 不同的部署模型，包括同步、部分同步和异步网络设置。相对于基本的 BFT 共识，Aequitas 协议会带来大量的通信开销，因此对于实际使用来说并不理想。 然而，我们相信 Aequitas 的实用变体将会出现，可以使用 用于 FSS 和其他应用程序中的事务排序。一些相关方案有 已经提出了较少伴随的形式主义和较弱的性质， 例如，[36,151,236]，但实际性能更好。这些方案都可以支持 在 FSS 中也是如此。 还值得注意的是，术语“公平”出现在 blockchain 的其他地方 具有不同含义的文学，即机会意义上的公平矿工与其承诺资源成正比 [106, 181] 或 validators 平等机会[153]。 安全因果关系保存： 防止分布式平台中的抢先交易和其他顺序违规的最广为人知的方法依赖于加密技术 技术。它们的共同特点是隐藏交易数据本身，等到 共识层秩序已建立，交易数据公开 稍后进行处理。这保留了交易之间的因果顺序 由 blockchain 执行。相关安全概念和密码协议 在 blockchains [71, 190] 出现之前已经得到了很大的发展。 “输入因果关系”[190] 和“安全因果关系保存”[71, 97] 的安全条件正式要求不知道任何有关交易的信息 在该交易在全球秩序中的位置尚未确定之前。在此之前，对手必须无法以加密方式推断出任何信息 强烈的感觉。 人们可以区分四种加密技术来保持因果关系： • 提交-显示协议 [29, 142, 145]：而不是宣布交易 明确地说，只有对交易的加密承诺才会被广播。在所有已提交但隐藏的事务已排序之后（在 blockchain 早期） MAINCHAIN 本身的系统，但这里是 FSS），发送者必须在预定的时间间隔内公开承诺并披露交易数据。 然后网络验证开放是否满足先前的承诺。的 此方法的起源可以追溯到 blockchains 出现之前。 虽然它特别简单，但该方法存在相当大的缺点，并且由于两个原因不容易采用。首先，由于在排序协议层面仅存在承诺，因此交易的语义 在达成共识期间无法验证。与客户的额外往返 是必需的。然而，更严重的是，权衡了没有开口可能会发生的可能性。 到达，这可能相当于拒绝服务攻击。此外，它 很难确定开局在一致的、分布式的情况下是否有效 方式，因为所有参与者必须就空缺是否到达达成一致 时间。 • 延迟恢复的提交-显示协议[145]：一项挑战 提交-显示方法是，客户端可以推测性地提交交易，并在后续交易使其有利可图时才显示它。一个 提交-显示方法的最新变体提高了对此的恢复能力 一种不当行为。特别是，TEX 协议 [145] 解决了这个问题 使用一种巧妙的方法，其中加密交易包含解密密钥 可以通过计算可验证的延迟函数（VDF）获得[53, 221]。如果一个客户 未能及时解密她的交易，系统中的其他人将解密 通过解决一个中等难度的密码难题来代表她。• 阈值加密 [71, 190]：该方法利用 DON 可以执行 阈值加密操作。假设 FSS 维护一个加密公共 key pkO 和 oracle 在它们之间共享相应的私钥。 然后，客户端在 pkO 下加密交易并将其发送到 FSS。社会保障基金订单 DON 上的交易，然后解密它们，最后将它们注入到 主链按固定顺序排列。因此，加密可确保排序 不是基于交易内容，而是数据本身在以下情况下可用： 需要。 该方法最初由 Reiter 和 Birman [190] 提出，后来由 Cachin 等人改进。 [71]，它与许可共识相结合 协议。最近的工作探索了使用阈值密码学作为 用于通用消息 [33, 97] 和共享数据 [41] 的一般计算的共识级别机制。 与提交-显示协议相比，阈值加密可以防止简单的拒绝服务攻击（尽管考虑到解密的计算成本，需要小心）。它让 DON 以自己的速度自主前进，无需 等待客户的进一步行动。交易在解密后可以立即得到验证。此外，客户用一个加密所有交易 DON 的密钥，通信模式与其他相同 交易。安全地管理阈值密钥并更改节点 然而，O 可能会带来额外的困难。 • 承诺秘密共享[97]：而不是加密下的交易数据 DON 持有的密钥，客户端也可以为 O 中的节点秘密共享它。 使用混合的、计算安全的秘密共享方案，交易 首先使用带有随机密钥的对称密码进行加密。仅共享相应的对称密钥，并将密文提交给DON。 客户端必须使用单独加密的消息向 O 中的每个节点发送一个密钥共享。其余协议步骤与阈值相同 加密，只不过交易数据采用对称解密 从其份额重建每笔交易密钥后的算法。 此方法不需要设置或管理公钥密码系统 与 DON 相关。但是，客户端必须了解其中的节点 O 并在安全的环境中与每个人进行交流，这使得 给客户带来额外的负担。 尽管加密方法提供了针对信息的完整保护 从提交的交易泄漏到网络，它们不隐藏元数据。对于 例如，发件人的 IP 地址或 Ethereum 地址仍可被使用 进行抢先交易和其他攻击的对手。各种隐私增强 部署在网络层的技术，例如[52,95,107]，或事务层， 例如，[13, 65]，需要实现这一目标。特定作品的影响 元数据的数量，即交易发送到哪个合约，可以（部分）隐藏通过在同一个 DON 上复用许多合约。密码隐藏 交易本身也不能阻止损坏的交易的优先级 DON 节点与交易发送者勾结。 加密协议保证的安全因果关系补充了任何策略的秩序公平性保证，我们打算探索两者的结合 方法，如果可能的话。如果对手无法从中获得显着优势 观察元数据，安全的因果关系保存协议可以与 也是一种简单的订购方法。例如oracle节点可以写入交易 他们收到后立即发送给 L，不得重复。那么交易将是 根据他们在L上的出现进行排序并随后解密。 我们还计划考虑使用 TEE 作为帮助执行公平排序的一种方式；为了 例如，Tesseract [44] 可能被视为实现了一种因果排序形式，但一个 TEE 以显式形式处理交易的能力得到了加强，同时 保留他们的机密。 5.4 网络层注意事项 到目前为止，我们对 FSS 的描述主要集中在强制执行 FSS 的问题上。 最终的交易顺序与其在网络中观察到的顺序相匹配。此后， 我们考虑网络层本身可能出现的公平问题。 传统电子市场的高频交易者投入大量资金 资源以获得卓越的网络速度[64]，加密货币交易所的交易者表现出类似的行为[90]。网络速度在以下方面都具有优势 观察其他方的交易并提交竞争交易。 实践中采用并在 Flash Boys [155] 一书中普及的一种补救措施是 最初在 IEX 交易所 [128] 中引入的“减速带”，后来在其他交易所中引入 交换 [179] （结果混合 [19]）。该机制对市场准入施加了延迟（IEX 为 350 微秒），目的是抵消市场准入的优势。 速度。经验证据，例如[128]，支持其减少某些交易的功效 普通投资者的成本。 FSS 可以简单地用于实现非对称 减速带——延迟传入交易的减速带。 Budish、Cramton 和 Shim [64] 认为，利用速度优势 在连续时间市场中是不可避免的，并主张在市场中采取结构性补救措施 以批量拍卖为基础的市场形式。但这种方法并未得到广泛采用 在现有的交易平台上。 传统的交易系统是中心化的，通常通过以下方式接收交易： 单个网络连接。相比之下，在去中心化系统中，可以 从多个有利位置观察交易传播。因此，可以观察到 P2P 网络中的网络泛洪等行为。 我们打算 探索 FSS 的网络层方法，帮助开发人员指定策略 禁止此类不良网络行为。5.5 实体级公平政策 秩序公平和安全因果关系旨在对以下交易执行排序： 尊重它们创建和首次提交到网络的时间。这种公平概念的局限性在于，它不能防止对手发起攻击 通过向系统注入大量交易来获得优势，观察到的策略 作为在 token 销售 [159] 中执行有效交易狙击的一种方式，并 造成拥堵，导致债务抵押头寸 (CDP) [48] 清算。 换句话说，秩序公平强制的是交易的公平，而不是玩家的公平。 如CanDID系统[160]所示，可以使用oracle工具，例如DECO 或 Town Crier 与节点委员会（例如 DON）结合以实现 各种形式的女巫抵抗，同时保护隐私。用户可以注册身份 并在不透露身份本身的情况下提供其独特性的证据。 抗女巫凭证提供了一种丰富交易排序的可能方法 限制洪水攻击机会的政策。例如，一个 token 销售可能只允许每个注册用户进行一笔交易，其中注册 需要国家标识符的唯一性证明，例如社会安全号码。 这种方法并非万无一失，但可能被证明是减轻交易泛滥攻击的有用策略。
خدمات التسلسل العادل
إحدى الخدمات المهمة التي نتوقع أن تقدمها DONs والتي تعمل على تعزيز إمكانات الشبكات والحوسبة والتخزين الخاصة بها تسمى خدمات التسلسل العادل (FSS). على الرغم من أنه قد يُنظر إلى الخدمة الثابتة الساتلية (FSS) ببساطة على أنها تطبيق تم تحقيقه ضمن إطار عمل DON، إلا أننا نسلط الضوء عليها كخدمة نعتقد أنها ستحظى بطلب مرتفع عبر جميع أنحاء العالم blockchains، والتي نتوقع أن تدعمها شبكة Chainlink بشكل نشط. عند تنفيذها على شبكات blockchain العامة، فإن العديد من تطبيقات DeFi الحالية الكشف عن المعلومات التي يمكن استغلالها من قبل المستخدمين لمصلحتهم الخاصة، على غرار هذا النوع من التسريبات الداخلية وفرص التلاعب السائدة في الوقت الحالي الأسواق [64، 155]. بدلاً من ذلك، تمهد خدمة FSS الطريق نحو نظام بيئي عادل DeFi. الخدمة الثابتة الساتلية يساعد المطورين على إنشاء عقود DeFi محمية من التلاعب بالسوق الناتجة عن تسرب المعلومات. وبالنظر إلى المشاكل التي نسلط الضوء عليها أدناه، فإن FSS كذلك جذابة بشكل خاص لخدمات الطبقة الثانية وتناسبها في إطار هذه الخدمات التي نناقشها في القسم 6. التحدي: في الأنظمة الحالية غير المسموح بها، يتم طلب المعاملات بالكامل حسب تقدير عمال المناجم. في الشبكات المرخصة، قد يتم تطبيق العقد validator نفس القوة. وهذا شكل من أشكال المركزية المؤقتة غير المعترف بها إلى حد كبير في خلاف ذلك الأنظمة اللامركزية. يمكن لعامل التعدين (مؤقتًا) فرض رقابة على المعاملات الخاصة به المنفعة الخاصة [171] أو إعادة ترتيبها لتعظيم مكاسبها الخاصة، وهي فكرة تسمى القيمة القابلة للاستخراج (MEV) [90]. مصطلح MEV خادع بعض الشيء: فهو لا يشير فقط للقيمة التي يمكن لعمال المناجم التقاطها: يمكن للمستخدمين العاديين التقاط بعض MEV. نظرًا لأن القائمين بالتعدين يتمتعون بقدرة أكبر من القوة التي يتمتع بها المستخدمون العاديون، فإن MEV تمثل حدًا أعلى لمقدار القيمة التي يمكن لأي كيان الحصول عليها من خلال إعادة الترتيب التنافسي وإدخال المعاملات التكميلية. حتى عندما يقوم عمال المناجم بطلب المعاملات ببساطة على أساس الرسوم (الغاز)، وبدون تلاعب، يمكن للمستخدمين أنفسهم التلاعب بأسعار الغاز لتفضيل معاملاتهم على المعاملات الأقل تعقيدًا. ديان وآخرون. [90] توثيق وقياس الطرق التي تتخذها الروبوتات (وليس عمال المناجم) الاستفادة من ديناميكيات الغاز بطريقة تضر مستخدمي أنظمة DeFi اليوم وكيف حتى أن MEV يهدد استقرار طبقة الإجماع الأساسية في blockchain. تظهر أمثلة أخرى للتلاعب بأوامر المعاملات بانتظام، على سبيل المثال، [50، 154].تعد أساليب معالجة المعاملات الجديدة مثل rollups طريقة واعدة للغاية لمشاكل تحجيم الإنتاجية العالية blockchains. ومع ذلك، فإنها لا تعالج مشكلة MEV. وبدلاً من ذلك، يقومون بنقله إلى الكيان الذي يقوم بإنشاء rollup. ذلك الكيان، سواء كان مشغل smart contract أو مستخدمًا يقدم (zk-)rollup مع إثبات الصلاحية، لديه القدرة على طلب وإدراج المعاملات. بمعنى آخر، rollups مبادلة MEV بـ REV: القيمة المجمعة القابلة للاستخراج. تؤثر MEV على المعاملات القادمة التي تم إرسالها إلى مجمع الذاكرة لكن لم يلتزموا بعد بالسلسلة. المعلومات حول مثل هذه المعاملات على نطاق واسع المتاحة في الشبكة. يمكن لعمال المناجم وvalidators والمشاركين العاديين في الشبكة ولذلك استغلال هذه المعرفة وإنشاء المعاملات التابعة. بالإضافة إلى ذلك، قد يؤثر القائمون بالتعدين وvalidator على ترتيب تلك المعاملات التي يقومون بها أنفسهم ويستغلون ذلك لصالحهم. مشكلة التأثير غير المبرر من قبل القادة على طلب المعاملات بالإجماع البروتوكولات معروفة في الأدبيات منذ التسعينيات [71، 190]، ولكن لا يوجد مرض مرضي لقد تم تنفيذ الحلول عمليًا حتى الآن [97]. والسبب الرئيسي هو أن الحلول المقترحة - على الأقل حتى وقت قريب جدًا - لا يمكن دمجها بسهولة مع الجمهور blockchains، حيث يعتمدون على بقاء محتوى المعاملات سريًا إلى ما بعد تم تحديد ترتيبهم. نظرة عامة على خدمات التسلسل العادل (FSS): ستوفر DONs أدوات لتحقيق اللامركزية في طلب المعاملات وتنفيذها وفقًا لسياسة محددة من خلال الاعتماد منشئ العقد، ومن الأفضل أن يكون عادلاً، ولا يفيد الجهات الفاعلة التي ترغب في ذلك التلاعب في ترتيب المعاملات. وتشكل هذه الأدوات مجتمعة الخدمة الثابتة الساتلية. يتضمن FSS ثلاثة مكونات. الأول هو مراقبة المعاملات. في الخدمة الثابتة الساتلية، oracle العقد الموجودة في O كلاهما تراقب مجمع ذاكرة MAINCHAIN وتسمح (إذا رغبت في ذلك) تقديم المعاملات خارج السلسلة من خلال قناة متخصصة. والثاني هو تسلسل المعاملات. العقد في معاملات أمر O لعقد الاعتماد وفقا للسياسة المحددة لهذا العقد. والثالث هو نشر المعاملات. بعد طلب المعاملات، تقوم العقد الموجودة في O بإرسال المعاملات بشكل مشترك إلى السلسلة الرئيسية. تشمل الفوائد المحتملة للخدمة الثابتة الساتلية ما يلي: • عدالة الطلب: تشتمل الخدمة الثابتة الساتلية (FSS) على أدوات لمساعدة المطورين على ضمان إتمام المعاملات يتم طلب الإدخال في عقد معين بطريقة لا تعطي ظلمًا ميزة للمستخدمين ذوي الموارد الجيدة و/أو الأذكياء تقنيًا. سياسات الطلب يمكن تحديدها لهذا الغرض. • الحد من تسرب المعلومات أو القضاء عليه: من خلال ضمان عدم تمكن المشاركين في الشبكة من استغلال المعرفة المتعلقة بالمعاملات القادمة، يمكن للخدمات المالية الثابتة أن تخفف أو القضاء على الهجمات مثل التشغيل الأمامي التي تعتمد على المعلومات المتوفرة في الشبكة قبل تنفيذ المعاملات. منع استغلال مثل هذه ويضمن التسرب المعاملات الخصومة التي تعتمد على الأصل المعلق لا يمكن للمعاملات إدخال دفتر الأستاذ قبل تنفيذ المعاملات الأصلية.• انخفاض تكلفة المعاملات: من خلال القضاء على حاجة اللاعبين إلى السرعة في الإرسال معاملاتهم إلى smart contract، FSS يمكن أن تقلل بشكل كبير من تكلفة معالجة المعاملات. • ترتيب الأولويات: يمكن للخدمات المالية الثابتة (FSS) أن تمنح المعاملات الهامة أولوية خاصة تلقائيًا الطلب. على سبيل المثال، لمنع الهجمات الأولية ضد oracle التقارير، على سبيل المثال، [79]، يمكن لخدمة FSS إدراج تقرير oracle في تدفق المعاملات بأثر رجعي. الهدف الشامل لـ FSS في DONs هو تمكين DeFi منشئي المحتوى من تحقيق العدالة الأنظمة المالية، أي الأنظمة التي لا تفيد مستخدمين معينين (أو عمال المناجم) على الآخرين على أساس السرعة أو المعرفة الداخلية أو القدرة على الأداء الفني التلاعب. في حين أن المفهوم العام الواضح للعدالة بعيد المنال، فإن العدالة الكاملة موجودة أي معنى معقول لا يمكن تحقيقه، تهدف FSS إلى تزويد المطورين بأداة قوية مجموعة من الأدوات حتى يتمكنوا من فرض السياسات التي تساعد في تحقيق أهداف التصميم الخاصة بهم لـ DeFi. نلاحظ أنه على الرغم من أن الهدف الرئيسي لـ FSS هو العمل كخدمة تسلسل عادلة MAINCHAIN الذي تستهدفه DONs، بعضًا من نفس العدالة التي ترغب فيها FSS يمكن أن تكون الضمانات مناسبة أيضًا للبروتوكولات (اللامركزية) التي يتم تشغيلها فيما بينها DON الحفلات. وبالتالي، يمكن النظر إلى الخدمة الثابتة الساتلية (FSS) على نطاق أوسع باعتبارها خدمة تقدمها مجموعة فرعية من DON العقد للتسلسل العادل ليس فقط للمعاملات المرسلة من قبل مستخدمي MAINCHAIN ولكن أيضًا المعاملات (أي الرسائل) المشتركة بين عقد DON الأخرى. في هذا القسم، سنركز في المقام الأول على هدف تسلسل معاملات MAINCHAIN. تنظيم القسم: في القسم 5.1، نصف تطبيقين عاليي المستوى يحفزان تصميم FSS: منع التشغيل الأمامي لتقارير oracle ومنع التشغيل الأمامي لمعاملات المستخدم. ثم نقدم المزيد من التفاصيل حول تصميم الخدمة الثابتة الساتلية في القسم 5.2. يصف القسم 5.3 أمثلة على ضمانات ووسائل النظام العادل لتحقيقها. أخيرًا، يناقش القسم 5.4 والقسم 5.5 التهديدات على مستوى الشبكة مثل هذه السياسات والوسائل لمعالجتها، على التوالي لفيضانات الشبكة وسيبيل الهجمات. 5.1 مشكلة التشغيل الأمامي لشرح أهداف وتصميم FSS، وصفنا شكلين عامين من السباق الأمامي الهجمات والقيود المفروضة على الحلول القائمة. الجري في المقدمة يمثل فئة من هجمات طلب المعاملات: هناك عدد من الهجمات ذات الصلة مثل الهجوم الخلفي والتداخل (التشغيل الأمامي بالإضافة إلى التشغيل الخلفي) [237] التي لا نغطيها هنا، ولكن الذي FSS يساعد أيضا على معالجة. 5.1.1 أوراكل للتشغيل الأمامي في دورهم التقليدي المتمثل في توفير البيانات خارج السلسلة لتطبيقات blockchain، oracles تصبح هدفا طبيعيا للهجمات الأمامية.ضع في اعتبارك نمط التصميم الشائع لاستخدام oracle لتوفير خلاصات الأسعار المختلفة إلى بورصة على السلسلة: بشكل دوري (على سبيل المثال كل ساعة)، يقوم oracle بجمع بيانات الأسعار لـ أصول مختلفة ويرسلها إلى عقد الصرف. هذه المعاملات بيانات الأسعار تقديم فرص واضحة للمراجحة: على سبيل المثال، إذا كان أحدث تقرير oracle يسرد سعر أعلى بكثير لبعض الأصول، يمكن للخصم أن يتقدم بتقرير oracle إلى شراء الأصول وإعادة بيعها على الفور بمجرد معالجة تقرير oracle. مطبات السرعة والتسعير بأثر رجعي: الحل الطبيعي لمشكلة التشغيل الأمامي oracle هو إعطاء تقارير oracle أولوية خاصة على المعاملات الأخرى. ل على سبيل المثال، يمكن إرسال تقارير oracle برسوم عالية لتشجيع القائمين بالتعدين على المعالجة لهم أولا. ولكن هذا لن يمنع التقدم إذا كانت فرصة المراجحة عالية، ولا يمكنها منع المراجحة من قبل عمال المناجم أنفسهم. وبالتالي، لجأت بعض البورصات إلى تنفيذ "مطبات سريعة" أكثر ثقلاً، مثل وضع معاملات المستخدم في قائمة الانتظار لعدد من الكتل قبل المعالجة. لهم، أو تعديل الأسعار بأثر رجعي عند وصول تقرير oracle جديد. عيوب هذه الحلول هي أنها تضيف تعقيدًا إلى تنفيذ التبادل، زيادة متطلبات التخزين وبالتالي تكاليف المعاملات، وتعطيل تجربة المستخدم حيث لا يتم تأكيد تبادل الأصول إلا بعد فترة زمنية طويلة. الحمولة على الظهر: قبل الانتقال إلى الخدمة الثابتة الساتلية (FSS)، نناقش مسألة التحميل على الظهر، وهي طريقة بسيطة للغاية حل أنيق لمشكلة التشغيل الأمامي oracle. لا ينطبق على معالجة ومع ذلك، في المقدمة في سيناريوهات أخرى. باختصار، بدلاً من إرسال التقارير بشكل دوري إلى العقد الموجود على السلسلة، oracles نشر التقارير الموقعة التي يلحقها المستخدمون بمعاملاتهم عند الشراء أو البيع الأصول على السلسلة. تقوم البورصة بعد ذلك بالتحقق ببساطة من أن التقرير صالح وحديث (على سبيل المثال، يمكن لـ oracle التوقيع على نطاق من الكتل التي يكون التقرير صالحًا لها)، والمقتطفات تغذية السعر ذات الصلة منه. يتمتع هذا الأسلوب البسيط بعدد من المزايا مقارنة بـ "مطب السرعة" المذكور أعلاه المنهج: (1) لا يحتاج عقد الصرف إلى الحفاظ على حالة الأسعار، وهو ما ينبغي يؤدي إلى انخفاض تكاليف المعاملات؛ (2) بما أن تقارير oracle يتم نشرها على السلسلة على أساس الحاجة، يمكن لـ oracles إنشاء تحديثات أكثر تكرارًا (على سبيل المثال، كل دقيقة)، وبالتالي تقليل فرص المراجحة من خلال إعداد التقرير مسبقًا9؛ (3) يمكن المعاملات سيتم التحقق من صحتها على الفور، لأنها تتضمن دائمًا موجزًا جديدًا للأسعار. لكن النهج ليس مثاليا. أولاً، يضع هذا الحل البديل المسؤولية تقع على عاتق مستخدمي البورصة لجلب تقارير oracle المحدثة وإرفاقها بملفاتهم المعاملات. وثانيا، في حين أن الاعتماد على الفائض من شأنه أن يقلل من فرص المراجحة، فإنه لا يفعل ذلك منعها تمامًا دون التأثير على حيوية العقد الموجود على السلسلة. في الواقع، إذا تقرير oracle صالح حتى رقم الكتلة n، ثم يتم إرسال المعاملة للحظر سيتطلب n + 1 تقريرًا صالحًا جديدًا. بسبب التأخير المتأصل في نشر التقارير من oracles إلى المستخدمين، فإن التقرير الجديد الصالح للكتلة n + 1 سيكون له 9. لا تكون المراجحة جديرة بالاهتمام إلا إذا كان الفارق القابل للاستغلال في أسعار الأصول يتجاوز الفارق الدخيل. الرسوم المطلوبة لشراء وبيع الأصول، على سبيل المثال، تلك التي يتم جمعها من قبل عمال المناجم والبورصة.ليتم نشرها في فترة ما قبل استخراج الكتلة n + 1، على سبيل المثال في الكتلة n -k، وبالتالي إنشاء سلسلة من الكتل k حيث توجد فرصة للمراجحة قصيرة الأجل. نحن صف الآن كيف يتغلب FSS على هذه القيود. تحديد أولويات تقارير oracle مع FSS: يمكن لـ FSS معالجة التشغيل الأمامي oracle المشكلة من خلال البناء على الحل البديل المذكور أعلاه، ولكن مع دفع الحل الإضافي العمل على زيادة المعاملات من خلال تقارير oracle إلى شبكة Oracle اللامركزية. على مستوى عالٍ، تجمع العقد oracle المعاملات الموجهة للتبادل على السلسلة، الاتفاق على موجز الأسعار في الوقت الفعلي، ونشر موجز الأسعار جنبًا إلى جنب مع المعاملات المجمعة في عقد السلسلة الرئيسية. من الناحية النظرية، يمكن للمرء أن يفكر في هذا النهج باعتباره "تجميع المعاملات المعززة بالبيانات"، حيث يضمن oracle أن يتم تحديث تتم إضافة خلاصة الأسعار دائمًا إلى المعاملات. يمكن تنفيذ حلول الخدمة الثابتة الساتلية (FSS) بشفافية لمستخدمي البورصة، ومع الحد الأدنى من التغييرات في منطق العقد، كما نوضح بمزيد من التفصيل في القسم 5.2. ضمان إن تقارير oracle الجديدة التي يتم منحها الأولوية دائمًا على معاملات المستخدم هي مجرد مثال واحد لسياسة الطلب التي يمكن لـ FSS اعتمادها وتنفيذها. سياسات FSS لضمان النظام يتم وصف العدالة بشكل أكثر عمومية في القسم 5.3. 5.1.2 معاملات المستخدم التي يتم تشغيلها مسبقًا ننتقل الآن إلى التشغيل الأمامي في التطبيقات العامة، حيث طريقة الدفاع أعلاه لا يعمل. يمكن التقاط المشكلة على نطاق واسع من خلال السيناريو التالي: يرى الخصم بعض معاملات المستخدم tx1 مرسلة إلى شبكة P2P ويقوم بحقنها معاملتها الخصومة tx2، بحيث تتم معالجة tx2 قبل tx1 (على سبيل المثال، عن طريق الدفع رسوم معاملة أعلى). على سبيل المثال، هذا النوع من التقدم شائع بين الروبوتات التي تستغل فرص المراجحة في أنظمة DeFi [90] وقد أثرت على مستخدمي التطبيقات اللامركزية المختلفة [101]. فرض نظام عادل بين المعاملات معالجتها على blockchain يعالج هذه المشكلة. والأهم من ذلك، أن رؤية تفاصيل tx1 ليست ضرورية في بعض الأحيان إن المعرفة بمجرد وجودها قد تسمح للخصم بتشغيل tx1 من خلاله امتلاك tx2 والاحتيال على المستخدم البريء الذي أنشأ tx1. على سبيل المثال، يمكن للمستخدم أن يكون معروفًا بتداول أصل معين في أوقات منتظمة. يتطلب منع مثل هذه الهجمات عمليات التخفيف التي تتجنب تسرب بيانات التعريف أيضًا [62]. بعض الحلول لهذه المشكلة موجودة، ولكنها تسبب تأخيرات ومخاوف بشأن سهولة الاستخدام. من ترتيب الشبكة إلى الترتيب النهائي مع الخدمة الثابتة الساتلية: فرص للتقدم للأمام تنشأ لأن الأنظمة القائمة ليس لديها آليات لضمان النظام الذي تظهر المعاملات على نحو متسلسلة فيما يتعلق بترتيب الأحداث وتدفق المعلومات خارج الشبكة. يمثل هذا مشكلة ناشئة عن أوجه القصور في تنفيذ التطبيقات (على سبيل المثال، منصات التداول) على blockchain. من الناحية المثالية، يمكن للمرء أن يفعل ذلك تأكد من تنفيذ المعاملات على blockchain بنفس الترتيب الذي كانت عليه تم إنشاؤها وإرسالها إلى شبكة P2P الخاصة بـ blockchain. ولكن منذ شبكة blockchain
يتم توزيعها، ولا يمكن التقاط مثل هذا الطلب. لذلك يقدم FSS الآليات للحماية من انتهاكات العدالة، التي تنشأ فقط بسبب التوزيع طبيعة شبكة blockchain. 5.2 تفاصيل الخدمة الثابتة الساتلية الشكل 12: مجموعة ذاكرة عادلة للطلب مع مسارين مختلفين للمعاملات: مباشر و على أساس mempool. ويبين الشكل 12 مخططاً عاماً للخدمة الثابتة الساتلية. لضمان العدالة، يجب أن يتداخل DON الذي يوفر خدمة FSS مع تدفق المعاملات عند دخولها إلى MAINCHAIN. قد يكون من الضروري إجراء تعديلات على العملاء، على smart contracts على MAINCHAIN، أو على كليهما. على مستوى عالٍ، يمكن تقسيم معالجة المعاملات بواسطة الخدمة الثابتة الساتلية (FSS) إلى ثلاثة المراحل الموضحة أدناه: (1) مراقبة المعاملات؛ (2) تسلسل المعاملات؛ و (3) ترحيل المعاملات. اعتمادًا على طريقة الطلب المستخدمة لتسلسل المعاملات، هناك حاجة إلى خطوات بروتوكول إضافية، كما هو موضح في القسم التالي. 5.2.1 معالجة المعاملات مراقبة المعاملات: نحن نتصور طريقتين مختلفتين لرصد الخدمة الثابتة الساتلية معاملات المستخدم المخصصة لـ smart contract محدد ومباشر ومستند إلى مجمع الذاكرة: • المباشر: النهج المباشر هو أبسط من الناحية المفاهيمية، ولكنه يتطلب إجراء تغييرات عليه عملاء المستخدمين بحيث يتم إرسال المعاملات مباشرة إلى Oracle اللامركزيةعقد الشبكة، بدلاً من عقد السلسلة الرئيسية. يتم تجميع DON معاملات المستخدم الموجهة إلى smart contract SC محددة وأوامرها بناءً على ذلك على بعض سياسة الطلب. يقوم DON بعد ذلك بإرسال المعاملات المطلوبة إلى smart contract على السلسلة الرئيسية. تتطلب بعض آليات الطلب أيضًا النهج المباشر لأن المستخدم الذي يقوم بإنشاء المعاملة يجب أن يكون مشفرًا حمايته قبل إرساله إلى FSS. • مستند إلى Mempool: لتسهيل تكامل FSS مع العملاء القديمين، DON يمكن استخدام Mempool Services (MS) لمراقبة مجمع الذاكرة الخاص بالسلسلة الرئيسية وجمعه المعاملات. من المرجح أن يكون النقل المباشر هو التنفيذ المفضل للعديد من العقود، ونعتقد أنه ينبغي أن يكون عمليًا إلى حد ما في كثير من الحالات. نناقش بإيجاز كيف يمكن تعديل التطبيقات اللامركزية الحالية إلى الحد الأدنى لدعمها النقل المباشر مع الحفاظ على تجربة مستخدم جيدة. وصفنا النهج استخدام Ethereum وMetaMask [6] نظرًا لأن هذه هي الخيارات الأكثر شيوعًا اليوم، ولكن يجب أن تمتد التقنيات المذكورة إلى السلاسل والمحافظ الأخرى. حديثة Ethereum اقتراح التحسين، "EIP-3085: تضيف المحفظة Ethereum طريقة سلسلة RPC" [100]، سيجعل من السهل استهداف سلاسل Ethereum المخصصة (باستخدام معرف سلسلة مختلف عن تلك الخاصة بـ MAINCHAIN لمنع هجمات إعادة التشغيل) من MetaMask والمحافظ الأخرى المستندة إلى المتصفح. بعد تنفيذ هذا الاقتراح، يسعى تطبيق DApp إلى استخدام DON سيضيف ببساطة استدعاء أسلوب واحد إلى الواجهة الأمامية ليتمكن من الإرسال مباشرة المعاملات إلى أي DON يعرض واجهة برمجة التطبيقات المتوافقة مع Ethereum. في هذه الأثناء، "EIP-712: Ethereum البيانات المنظمة المكتوبة hash للتوقيع والتوقيع" [49] يوفر قليلاً بديل أكثر مشاركة ولكنه منتشر بالفعل على نطاق واسع، حيث يمكن لمستخدم DApp استخدامه MetaMask لتوقيع البيانات المنظمة التي تحدد معاملة DON. يمكن للتطبيق اللامركزي إرسال وقعت هذه البيانات المنظمة على DON. وأخيرا، نلاحظ أن النهج الهجين ممكن أيضا. على سبيل المثال، التراث يمكن للعملاء الاستمرار في إرسال المعاملات إلى مجمع ذكريات السلسلة الرئيسية، ولكن الأمر بالغ الأهمية يتم إرسال المعاملات (على سبيل المثال، تقارير oracle) إلى العقد DON مباشرة (على وجه الخصوص، مجموعة من العقد توفر تقارير oracle مثل تحديثات موجز الأسعار ومجموعة العقد قد يتداخل توفير الخدمة الثابتة الساتلية (FSS) أو يكون متطابقًا). تسلسل المعاملات: الغرض الرئيسي من FSS هو ضمان ترتيب معاملات المستخدم وفقًا لسياسة محددة مسبقًا. طبيعة هذه السياسة سوف تعتمد على احتياجات التطبيق وأنواع أوامر المعاملات غير العادلة التي يقدمها يهدف إلى منع. نظرًا لأن FSS الموجود على DON قادر على معالجة البيانات والحفاظ على الحالة المحلية، فقد يفرضون سياسة تسلسل تعسفية بناءً على المعلومات الموجودة متاح على oracles. تتم مناقشة سياسات الطلب الخاصة وتنفيذها لاحقًا في القسم 5.3.ترحيل المعاملات: بعد جمع وترتيب معاملات المستخدم، سواء المستلمة مباشرة من المستخدمين أو التي تم جمعها من مجمع الذاكرة، يرسل DON هذه المعاملات إلى السلسلة الرئيسية. وعلى هذا النحو، تظل تفاعلات DON مع السلسلة الرئيسية قائمة تخضع لطلبات المعاملات (التي قد تكون غير عادلة) والتي يحكمها القائمون بالتعدين في السلسلة الرئيسية. للاستفادة من فوائد طلب المعاملات اللامركزية، الهدف ذكي وبالتالي، يجب تصميم عقد SC بحيث يعامل DON كمواطن من "الدرجة الأولى". نحن التمييز بين نهجين: • DON- العقود فقط: أبسط خيار للتصميم هو جعل السلسلة الرئيسية ذكية لا يقبل عقد SC إلا المعاملات التي تمت معالجتها بواسطة DON. هذا يضمن أن smart contract يعالج المعاملات بالترتيب الذي يقترحه DON، ولكن بحكم الأمر الواقع يقيد smart contract للعمل في نظام قائم على اللجنة (على سبيل المثال، تتمتع لجنة DON الآن بسلطة مستمرة لتحديد ترتيب وإدراج المعاملات). • العقود ذات الفئة المزدوجة: التصميم المفضل والأكثر تفصيلاً يحتوي على السلسلة الرئيسية الذكية يقبل عقد SC المعاملات الناشئة من DON ومن التراث المستخدمين،10 ولكنها تضع "مطبات السرعة" التقليدية على المعاملات التي لم تتم معالجتها بواسطة DON. على سبيل المثال، قد تتم معالجة المعاملات من DON على الفور، بينما يتم "تخزين" المعاملات القديمة بواسطة smart contract لـ فترة زمنية محددة. آليات قياسية أخرى لمنع التشغيل الأمامي مثل مخططات الكشف عن الالتزام أو VDFs [53] يمكن أيضًا تطبيقها على الإصدارات القديمة المعاملات. وهذا يضمن معالجة المعاملات المطلوبة DON الأمر المتفق عليه، دون إعطاء DON السلطة غير المرغوب فيها للرقابة المعاملات. نظرًا لأن فرض طلب المعاملات بواسطة الخدمة الثابتة الساتلية (FSS) يتطلب تجميع المعاملات "خارج السلسلة"، فمن الطبيعي أن يتم دمج هذا الحل مع تقنيات التجميع الأخرى التي تهدف إلى تقليل تكاليف المعالجة على السلسلة. على سبيل المثال، بعد جمع و لطلب المعاملات، قد يرسل DON هذه المعاملات إلى السلسلة الرئيسية باعتبارها "معاملة مجمعة" واحدة (على سبيل المثال، rollup)، مما يقلل من إجمالي المعاملة رسوم. تنفيذ أمر المعاملة: سواء كان في تصميم DON فقط أو تصميم ثنائي الفئة، يجب أن يتم تصميم السلسلة الرئيسية smart contract SC وDON بشكل مشترك لضمان دعم طلب المعاملات الخاص بـ DON. وهنا أيضًا، نتصور مختلفًا خيارات التصميم: • الأرقام التسلسلية: يمكن لـ DON إلحاق رقم تسلسلي بكل معاملة، وإرسال هذه المعاملات إلى مجمع ذكريات السلسلة الرئيسية. الرئيسي 10إذا كانت مراقبة معاملات DON تعتمد على مجمع الذاكرة، فيجب تمييز المعاملات القديمة عن معاملات DON بحيث لا يتم جمعها بواسطة DON، على سبيل المثال، عبر علامة خاصة جزءا لا يتجزأ من الصفقة أو عن طريق تحديد سعر معين للغاز، على سبيل المثال. DON المعاملات بها غاز الأسعار تحت عتبة معينة.تتجاهل السلسلة smart contract SC المعاملات التي تصل "خارج التسلسل". نحن لاحظ أنه في هذا الإعداد، يمكن للقائمين بالتعدين في السلسلة الرئيسية أن يقرروا تجاهل DON طلب المعاملات، مما يؤدي إلى فشل المعاملات. من الممكن عن طريق الاحتفاظ بحالة (باهظة الثمن) لـ SC فرض ترتيب المعاملات الصحيح إلى حد ما بشكل مشابه لكيفية قيام بروتوكول TCP بتخزين الحزم خارج الترتيب حتى تصبح الحزم المفقودة تلقى. • المعاملات nonces: بالنسبة للعديد من blockchains، وعلى وجه الخصوص لـ Ethereum، يمكن لنهج الترقيم التسلسلي أعلاه الاستفادة من المعاملة المضمنة nonces فرض أن السلسلة الرئيسية smart contract SC تعالج المعاملات بالتسلسل. هنا، ترسل العقد DON المعاملات إلى السلسلة الرئيسية من خلال حساب mainchain واحد، محمي بمفتاح مشترك بين العقد DON. الحساب تضمن المعاملة nonce استخراج المعاملات ومعالجتها بالترتيب الصحيح. • تجميع المعاملات: يمكن لـ DON تجميع معاملات متعددة في rollup (أو في حزمة مشابهة لـ rollup). يجب أن تكون السلسلة الرئيسية smart contract مصممة للتعامل مع مثل هذه المعاملات الإجمالية. • تجميع المعاملات باستخدام وكيل السلسلة الرئيسية: هنا، يقوم DON بالمثل بتجميع المعاملات في "معاملة تعريفية" واحدة للسلسلة الرئيسية، ولكنها تعتمد على الوكيل المخصص smart contract لتفريغ المعاملات وترحيلها إلى العقد المستهدف SC. يمكن أن تكون هذه التقنية مفيدة للتوافق القديم. تعمل المعاملات الوصفية مثل rollup ولكنها تختلف من حيث أنها تتكون من ملف غير مضغوط قائمة المعاملات المنشورة مرة واحدة على السلسلة الرئيسية. يتمتع التصميم الأخير بميزة دعم معاملات المستخدم بسلاسة هم أنفسهم وكيلون من خلال عقد السلسلة الرئيسية قبل الوصول إلى هدف DON عقد SC. على سبيل المثال، فكر في مستخدم يرسل معاملة إلى بعض المحافظ العقد، والذي بدوره يرسل معاملة داخلية إلى SC. تعيين تسلسل سيكون رقم مثل هذه المعاملة صعبًا، ما لم يكن عقد محفظة المستخدم كذلك مصمم خصيصًا لإعادة توجيه الرقم التسلسلي مع كل معاملة داخلية إلى SC. وبالمثل، لا يمكن تجميع هذه المعاملات الداخلية بسهولة في معاملة وصفية يتم إرسالها مباشرة إلى SC. نناقش المزيد من اعتبارات التصميم ل مثل هذه المعاملات بالوكالة أدناه. 5.2.2 الذرية الصفقة لقد افترضت مناقشتنا حتى الآن ضمنيًا أن المعاملات تتفاعل مع واحدة على السلسلة smart contract (على سبيل المثال، يرسل المستخدم طلب شراء إلى البورصة). ومع ذلك، في أنظمة مثل Ethereum، يمكن أن تتكون المعاملة الواحدة من معاملات داخلية متعددة، على سبيل المثال، واحدة smart contract تستدعي وظيفة في عقد آخر. أدناه، نحن وصف استراتيجيتين رفيعتي المستوى لتسلسل المعاملات "متعددة العقود"، بينما الحفاظ على ذرية المعاملة (أي تسلسل الإجراءات المنصوص عليها من قبل يتم تنفيذ جميع المعاملات بالترتيب الصحيح، أو لا يتم تنفيذها على الإطلاق).الذرية القوية: الحل الأبسط هو تطبيق الخدمة الثابتة الساتلية، كما هو موضح أعلاه، مباشرة على المعاملات "متعددة العقود" بأكملها. أي أن المستخدمين يرسلون معاملاتهم في الشبكة ويقوم FSS بمراقبة وتسلسل هذه المعاملات ونشرها على السلسلة الرئيسية. هذا الأسلوب بسيط من الناحية الفنية، ولكن له قيد محتمل واحد: إذا كان المستخدم تتفاعل المعاملة مع عقدين SC1 وSC2 يرغب كلاهما في الاستفادة بشكل عادل خدمات التسلسل، فإن سياسة التسلسل لهذين العقدين يجب أن تكون متسقة. وهذا يعني أنه في ضوء معاملتين مختلفتين tx1 وtx2 يتفاعل كل منهما معهما لكل من SC1 وSC2، يجب ألا تكون سياسة SC1 هي التي تطلب tx1 قبل tx2 في حين أن سياسة SC2 تنص على الأمر المعاكس. بالنسبة للغالبية العظمى من السيناريوهات محل الاهتمام، فإننا نتصور أن سياسات التسلسل المعتمدة في العقود المختلفة ستكون متسقة. على سبيل المثال، كل من SC1 وSC2 قد ترغب في أن يتم ترتيب المعاملات حسب وقت وصولها التقريبي إلى مجمع الذاكرة، وقد يرغب SC1 أيضًا في تسليم تقارير معينة oracle أولاً دائمًا. كما معاملات التقرير oracle الأخيرة لا تتفاعل مع SC2، والسياسات متسقة. الذرية الضعيفة: في عموميتها الكاملة، يمكن تطبيق الخدمة الثابتة الساتلية على المستوى الفردي المعاملات الداخلية. خذ بعين الاعتبار المعاملات بالصيغة tx = {˜txpre, ˜txSC, ˜txpost}، والتي تتكون من بعض العناصر الأولية المعاملة (المعاملات) ˜txpre، والتي تؤدي إلى معاملة داخلية ˜txSC إلى SC، والتي بدورها يصدر المعاملة (المعاملات) الداخلية ˜txpost. قد تحدد سياسة التسلسل الخاصة بـ SC كيفية القيام بذلك يجب أن يتم طلب المعاملة الداخلية ˜txSC فيما يتعلق بالمعاملات الأخرى المرسلة إلى SC، ولكن اترك ترتيب التسلسل مفتوحًا لـ "txpre" و"txpost". نظرًا لجوهر معالجة المعاملات في أنظمة مثل Ethereum، فإن تطوير خدمة تسلسل تستهدف معاملات داخلية محددة ليس بالأمر السهل. مع عقد SC المصمم خصيصًا، يمكن تحقيق ذلك على النحو التالي: 1. يتم إرسال المعاملة tx إلى الشبكة واستخراجها (بدون أي تسلسل يؤديها FSS). يتم تنفيذ الأمر ˜txpre الأولي، ويستدعي ˜txSC. 2. SC لا ينفذ "txSC" ويعود. 3. يقوم FSS بمراقبة المعاملات الداخلية إلى SC، وتسلسلها، ثم إرسالها مرة أخرى إلى SC (أي عن طريق إرسال المعاملات ˜txSC مباشرة إلى SC). 4. تقوم SC بمعالجة المعاملات ˜txSC المستلمة من FSS، وتصدر المعاملات الداخلية ˜txpost الناتجة عن ˜txSC. باستخدام هذا النهج، لا يتم تنفيذ المعاملات بشكل ذري بالكامل (أي النسخة الأصلية يتم تقسيم المعاملة tx إلى معاملات متعددة على السلسلة)، ولكن ترتيب يتم الحفاظ على المعاملات الداخلية. يتضمن هذا الحل عددًا من قيود التصميم. على سبيل المثال، لا يمكن لـ txpre افترض أنه سيتم تنفيذ ˜txSC و ˜txpost. وعلاوة على ذلك، ينبغي تصميم SC بحيث تنفيذ المعاملات ˜txSC و ˜txpost نيابة عن مستخدم معين، على الرغم من أنها كانت كذلكأرسلت بواسطة FSS. لهذه الأسباب، الحل الأكثر خشونة هو "الذرية القوية". من المرجح أن يكون ما سبق هو الأفضل في الممارسة العملية. لاحترام التبعيات الأكثر تعقيدًا، والتي تتضمن معاملات متعددة و المعاملات الداخلية الخاصة بكل منها، قد يحتوي برنامج جدولة المعاملات في FSS وظائف معقدة تشبه تلك الموجودة في مديري المعاملات العلائقية مديري قواعد البيانات. 5.3 تسلسل المعاملات العادلة نناقش هنا فكرتين للعدالة فيما يتعلق بتسلسل المعاملات والتطبيقات المقابلة، والتي يمكن أن تحققها الخدمة الثابتة الساتلية: عدالة الطلب على أساس سياسة ما تفرضها الخدمة الثابتة الساتلية (FSS) والحفاظ على العلاقة السببية الآمنة، الأمر الذي يتطلب طرق تشفير إضافية في الخدمة الثابتة الساتلية (FSS). عدالة النظام: عدالة النظام هي فكرة العدالة الزمنية في بروتوكولات الإجماع تم تقديمه رسميًا لأول مرة بواسطة Kelkar et al. [144]. كيلكار وآخرون. تهدف إلى تحقيق شكل من أشكال السياسة الطبيعية التي تتم فيها المعاملات تم طلبها بناءً على وقت استلامها لأول مرة بواسطة DON (أو شبكة P2P، في حالة FSS المستندة إلى mempool). لكن الأمر مختلف في النظام اللامركزي قد ترى العقد وصول المعاملات بترتيب مختلف. إنشاء النظام الإجمالي في جميع المعاملات هي المشكلة نفسها التي تم حلها من خلال بروتوكول الإجماع الأساسي مينشين. كيلكار وآخرون. [144] لذلك يقدم فكرة أضعف يمكن أن تكون تم تحقيقه بمساعدة شبكة أوراكل اللامركزية، والتي تسمى "عدالة أوامر الكتلة". يقوم بتجميع المعاملات التي تلقاها DON خلال فترة زمنية في ملف "block" ويقوم بإدراج جميع معاملات الكتلة بشكل متزامن وفي نفس الموضع (أي الارتفاع) إلى MAINCHAIN. وبالتالي يتم ترتيبها معًا ويجب أن تكون قابلة للتنفيذ بالتوازي، دون خلق أي صراعات فيما بينها. بشكل تقريبي، تنص عدالة الطلب على أنه إذا رأى جزء كبير من العقد المعاملة τ1 قبل τ2، إذن سيتم تسلسل τ1 قبل أو في نفس الكتلة مثل τ2. بفرض مثل هذه الخشنة التفاصيل المتعلقة بأمر المعاملة، تقل فرص الهجوم الأمامي والهجمات الأخرى المتعلقة بالأمر بشكل كبير. كيلكار وآخرون. يقترح عائلة من البروتوكولات تسمى Aequitas [144]، والتي تعالج نماذج نشر مختلفة، بما في ذلك إعدادات الشبكة المتزامنة والمتزامنة جزئيًا وغير المتزامنة. تفرض بروتوكولات Aequitas أعباء اتصال كبيرة مقارنة بالإجماع الأساسي BFT وبالتالي فهي ليست مثالية للاستخدام العملي. ومع ذلك، نعتقد أن المتغيرات العملية لـ Aequitas ستظهر والتي يمكن استخدامها لتسلسل المعاملات في الخدمة الثابتة الساتلية والتطبيقات الأخرى. بعض المخططات ذات الصلة لديها تم بالفعل اقتراحها والتي تحتوي على شكليات أقل وخصائص أضعف، على سبيل المثال، [36، 151، 236]، لكن الأداء العملي أفضل. يمكن دعم هذه المخططات في الخدمة الثابتة الساتلية كذلك. ومن الجدير بالذكر أيضًا أن مصطلح "العدالة" يظهر في مكان آخر في blockchain الأدب ذو معنى مختلف، وهو الإنصاف بمعنى الفرصةالقائمين بالتعدين يتناسب مع مواردهم الملتزم بها [106، 181] أو validators من حيث تكافؤ الفرص [153]. تأمين الحفاظ على السببية: يعتمد الأسلوب الأكثر شهرة لمنع التجاوزات وانتهاكات الطلب الأخرى في الأنظمة الأساسية الموزعة على التشفير التقنيات. السمة المشتركة بينهما هي إخفاء بيانات المعاملة نفسها، والانتظار حتى تم إنشاء الطلب في طبقة الإجماع والكشف عن بيانات المعاملة لاحقا للمعالجة. وهذا يحافظ على الترتيب السببي بين المعاملات التي تتم تم تنفيذه بواسطة blockchain. مفاهيم الأمان وبروتوكولات التشفير ذات الصلة تم تطويرها بشكل كبير قبل ظهور blockchains [71، 190]. تتطلب الشروط الأمنية الخاصة بـ "سببية الإدخال" [190] و"الحفاظ على السببية الآمنة" [71، 97] رسميًا عدم معرفة أي معلومات حول المعاملة قبل أن يتم تحديد موقع هذه الصفقة في النظام العالمي. يجب ألا يتمكن الخصم من استنتاج أي معلومات حتى ذلك الوقت بطريقة مشفرة شعور قوي. يمكن للمرء أن يميز بين أربع تقنيات تشفير للحفاظ على العلاقة السببية: • بروتوكولات الكشف عن الالتزام [29، 142، 145]: بدلاً من الإعلان عن المعاملة في الوضوح، يتم بث فقط التزام التشفير بالمعاملة. بعد أن يتم طلب جميع المعاملات الملتزمة ولكن المخفية (في أوائل blockchain الأنظمة الموجودة على MAINCHAIN نفسها، ولكن هنا بواسطة FSS)، يجب على المرسل فتح الالتزام والكشف عن بيانات المعاملة خلال فترة زمنية محددة مسبقًا. ثم تتحقق الشبكة من أن الافتتاح يفي بالالتزام السابق. ال تعود أصول هذه الطريقة إلى ما قبل ظهور blockchains. وعلى الرغم من بساطة هذا النهج بشكل خاص، إلا أنه ينطوي على عيوب كبيرة وليس من السهل استخدامه لسببين. أولاً، بما أن الالتزام موجود فقط على مستوى بروتوكول الطلب، فإن دلالات المعاملة لا يمكن التحقق من صحتها أثناء الإجماع. رحلة إضافية ذهابًا وإيابًا إلى العميل مطلوب. لكن الأمر الأكثر خطورة هو احتمال عدم فتح أبوابها قد تصل إلى أي وقت مضى، الأمر الذي قد يصل إلى مستوى هجوم رفض الخدمة. علاوة على ذلك، فإنه من الصعب تحديد ما إذا كان الافتتاح صالحًا بشكل متسق وموزع بطريقة لأنه يجب على جميع المشاركين الاتفاق على ما إذا كان الافتتاح قد وصل أم لا الوقت. • بروتوكولات الكشف عن الالتزام مع تأخير الاسترداد [145]: أحد التحديات مع نهج الالتزام والكشف هو أن العميل قد يلتزم بمعاملة مضاربة ويكشف عنها لاحقًا فقط إذا كانت المعاملات اللاحقة تجعلها مربحة. أ يعمل البديل الأخير من نهج الكشف عن الالتزام على تحسين المرونة ضد هذا نوع من سوء السلوك. وعلى وجه الخصوص، يعالج بروتوكول TEX [145] هذه المشكلة باستخدام أسلوب ذكي تتضمن فيه المعاملات المشفرة مفتاح فك التشفير يمكن الحصول عليها عن طريق حساب دالة تأخير يمكن التحقق منها (VDF) [53، 221]. إذا كان العميل إذا فشلت في فك تشفير معاملتها في الوقت المناسب، فسيقوم الآخرون في النظام بفك التشفير نيابة عنها عن طريق حل لغز تشفير صعب إلى حد ما.• تشفير العتبة [71، 190]: تستغل هذه الطريقة ما قد يؤديه DON عمليات عتبة التشفير. افترض أن FSS يحتفظ بتشفير عام يتشارك المفتاحان pkO وoracles المفتاح الخاص المقابل فيما بينهما. يقوم العملاء بعد ذلك بتشفير المعاملات بموجب pkO وإرسالها إلى FSS. أوامر الخدمة الثابتة الساتلية المعاملات على DON، ثم يقوم بفك تشفيرها وإدخالها أخيرًا في MAINCHAIN بالترتيب الثابت. التشفير بالتالي يضمن أن الطلب لا يعتمد على محتوى المعاملة، بل على أن البيانات نفسها تكون متاحة متى مطلوب. تم اقتراح هذه الطريقة في الأصل بواسطة رايتر وبيرمان [190] وتم تحسينها لاحقًا بواسطة Cachin et al. [71]، حيث تم دمجه بإجماع مسموح به البروتوكول. لقد استكشفت الأعمال الحديثة استخدام تشفير العتبة كطريقة آلية على مستوى الإجماع للرسائل العامة [33، 97] وللحسابات العامة مع البيانات المشتركة [41]. بالمقارنة مع بروتوكولات كشف الالتزام، يمنع تشفير العتبة هجمات رفض الخدمة البسيطة (على الرغم من أن الحذر مطلوب نظرًا للتكلفة الحسابية لفك التشفير). فهو يتيح لـ DON المضي قدمًا بشكل مستقل وبسرعته الخاصة وبدون ذلك في انتظار المزيد من إجراءات العميل. يمكن التحقق من صحة المعاملات فورًا بعد فك تشفيرها. علاوة على ذلك، يقوم العملاء بتشفير كافة المعاملات باستخدام أداة واحدة مفتاح DON ويظل نمط الاتصال كما هو مع الآخرين المعاملات. إدارة مفتاح العتبة بشكل آمن ومع تغيير العقد ومع ذلك، قد يطرح صعوبات إضافية. • المشاركة السرية الملتزم بها [97]: بدلاً من تشفير بيانات المعاملة تحتها المفتاح الذي يحتفظ به DON، يجوز للعميل أيضًا مشاركته سرًا للعقد الموجودة في O. باستخدام نظام مشاركة سري مختلط وآمن حسابيًا، تتم المعاملة يتم تشفيره أولاً باستخدام تشفير متماثل بمفتاح عشوائي. تتم مشاركة المفتاح المتماثل المقابل فقط ويتم إرسال النص المشفر إلى DON. يجب على العميل إرسال مشاركة مفتاح واحدة إلى كل عقدة في O باستخدام رسالة مشفرة بشكل منفصل. خطوات البروتوكول المتبقية هي نفسها كما هو الحال مع العتبة التشفير، إلا أنه يتم فك تشفير بيانات المعاملة بطريقة متماثلة الخوارزمية بعد إعادة بناء مفتاح كل معاملة من مشاركاتها. لا تتطلب هذه الطريقة إعداد أو إدارة نظام تشفير المفتاح العام المرتبطة بـ DON. ومع ذلك، يجب أن يكون العملاء على علم بالعقد الموجودة في O والتواصل في سياق آمن مع كل واحد منهم في أي مكان عبء إضافي على العملاء. على الرغم من أن طرق التشفير توفر حماية كاملة ضد المعلومات تتسرب من المعاملات المقدمة إلى الشبكة، فهي لا تخفي البيانات الوصفية. ل على سبيل المثال، لا يزال من الممكن استخدام عنوان IP أو عنوان Ethereum الخاص بالمرسل خصمًا لأداء الهجمات الأمامية والهجمات الأخرى. تعزيز الخصوصية المختلفة التقنيات المنتشرة في طبقة الشبكة، على سبيل المثال، [52، 95، 107]، أو طبقة المعاملات، على سبيل المثال، [13، 65]، ستكون هناك حاجة لتحقيق هذا الهدف. تأثير قطعة معينة من الممكن إخفاء البيانات الوصفية (جزئيًا)، أي العقد الذي يتم إرسال المعاملة إليهمن خلال مضاعفة العديد من العقود على نفس DON. إخفاء التشفير المعاملات في حد ذاتها لا تمنع أيضًا تحديد أولويات المعاملات عن طريق التالف DON العقد المتواطئة مع مرسلي المعاملات. إن السببية الآمنة التي تضمنها بروتوكولات التشفير تكمل ضمانات عدالة الطلب لأي سياسة، ونحن نعتزم استكشاف مزيج من الاثنين الأساليب، حيثما كان ذلك ممكنا. إذا لم يتمكن الخصم من الحصول على ميزة كبيرة منه ومن خلال مراقبة البيانات الوصفية، يمكن استخدام بروتوكولات الحفاظ على العلاقة السببية الآمنة جنبًا إلى جنب نهج الطلب الساذج أيضًا. على سبيل المثال، يمكن للعقد oracle كتابة المعاملات إلى L بمجرد استلامها، دون ازدواجية. المعاملات ستكون بعد ذلك تم طلبها وفقًا لظهورها على L وتم فك تشفيرها لاحقًا. ونخطط أيضًا للنظر في استخدام TEEs كوسيلة للمساعدة في فرض النظام العادل؛ ل على سبيل المثال، يمكن النظر إلى Tesseract [44] على أنه يحقق شكلاً من أشكال الترتيب السببي، ولكن أحد معززة بقدرة TEE على معالجة المعاملات بشكل واضح أثناء الحفاظ على سريتهم. 5.4 اعتبارات طبقة الشبكة حتى الآن، ركز وصفنا للخدمة الثابتة الساتلية (FSS) بشكل أساسي على مشكلة فرض ذلك يتطابق الترتيب النهائي للمعاملات مع ترتيبها الملحوظ في الشبكة. الآخرة، نحن نأخذ في الاعتبار مشكلات العدالة التي قد تنشأ في طبقة الشبكة نفسها. يستثمر المتداولون عالي التردد في الأسواق الإلكترونية التقليدية قدرًا كبيرًا من المال الموارد اللازمة للحصول على سرعة شبكة فائقة [64]، ويظهر المتداولون في بورصات العملات المشفرة سلوكًا مشابهًا [90]. تمنح سرعة الشبكة ميزة في كل من مراقبة معاملات الأطراف الأخرى وتقديم المعاملات المتنافسة. أحد العلاجات التي تم نشرها عمليًا وتم نشرها في كتاب Flash Boys [155] هو "مطب السرعة" الذي تم تقديمه في البداية في بورصة IEX [128] ولاحقًا في بورصات أخرى التبادلات [179] (مع نتائج مختلطة [19]). وتفرض هذه الآلية تأخيرا (350 ميكروثانية في IEX) على الوصول إلى السوق، وذلك بهدف تحييد المزايا في السرعة. الأدلة التجريبية، على سبيل المثال. [128]، يدعم فعاليته في تقليل تداولات معينة التكاليف بالنسبة للمستثمرين العاديين. يمكن استخدام FSS ببساطة لتنفيذ نظام غير متماثل مطب السرعة - الذي يؤخر المعاملات الواردة. يرى بوديش وكرامتون وشيم [64] أن استغلال المزايا في السرعة لا مفر منه في الأسواق المستمرة، ويجادلون من أجل علاج هيكلي في شكل من أشكال الأسواق القائمة على المزاد دفعة واحدة. لكن هذا النهج لم يترسخ على نطاق واسع في منصات التداول الحالية. أنظمة التداول التقليدية مركزية، وعادة ما تتلقى المعاملات من خلالها اتصال شبكة واحدة. على النقيض من ذلك، في النظام اللامركزي، من الممكن مراقبة انتشار المعاملة من نقاط مراقبة متعددة. وبالتالي، من الممكن ملاحظة سلوكيات مثل غمر الشبكة في شبكة P2P. نحن ننوي لاستكشاف أساليب طبقة الشبكة للخدمة الثابتة الساتلية (FSS) التي تساعد المطورين على تحديد السياسات حظر مثل هذه السلوكيات الشبكة غير المرغوب فيها.5.5 سياسات العدالة على مستوى الكيان تهدف عدالة النظام والسببية الآمنة إلى فرض أمر على المعاملات يحترم الوقت الذي تم فيه إنشائها وإرسالها لأول مرة إلى الشبكة. أحد القيود على فكرة العدالة هذه هو أنها لا تمنع الهجمات التي يقوم بها الخصم تكتسب ميزة من خلال إغراق النظام بالعديد من المعاملات، وهي استراتيجية تمت ملاحظتها في البرية كوسيلة لإجراء عمليات قنص فعالة للمعاملات في token المبيعات [159] ول خلق ازدحام يؤدي إلى تصفية مراكز الديون المضمونة (CDPs) [48]. وبعبارة أخرى، فإن عدالة النظام تفرض العدالة فيما يتعلق بالمعاملات، وليس اللاعبين. كما هو موضح في نظام CanDID [160]، من الممكن استخدام أدوات oracle مثل DECO أو Town Crier بالاشتراك مع لجنة العقد (مثل DON) لتحقيق أشكال مختلفة من مقاومة العرافة مع حماية الخصوصية. يمكن للمستخدمين تسجيل الهويات وتقديم دليل على تفردهم دون الكشف عن الهويات نفسها. توفر بيانات الاعتماد المقاومة لـ Sybil طريقة محتملة لإثراء طلب المعاملات السياسات بطريقة من شأنها أن تحد من فرص الهجمات الفيضانات. على سبيل المثال، أ token قد يسمح البيع بمعاملة واحدة فقط لكل مستخدم مسجل، حيث يتم التسجيل يتطلب إثباتًا على تفرد المعرف الوطني، مثل رقم الضمان الاجتماعي. مثل هذا النهج ليس مضمونا، ولكنه قد يكون سياسة مفيدة للتخفيف من هجمات غمر المعاملات.
DON 事务执行框架
(DON-TEF) DONs 将为 oracle 内的第 2 层解决方案提供 oracle 和去中心化资源支持 我们称之为去中心化 Oracle 网络交易执行框架 (DONTEF) 或简称 TEF。 如今，DeFi 合约的更新频率受到主链延迟的限制， 例如，Ethereum [104] 中 10-15 秒的平均区块间隔，以及 在链上推送大量数据和有限的计算/交易吞吐量—— 激励扩展方法，例如分片 [148、158、232] 和第 2 层执行 [5、 12、121、141、169、186、187]。即使 blockchains 的交易时间要快得多， 例如，[120]，提出了涉及链外计算[168]的扩容策略。 TEF 旨在充当任何此类第 1 层/主链系统的第 2 层资源。 使用 TEF，DONs 可以支持主链合约中更快的更新，同时 保留主链提供的关键信任保证。 TEF可以支持 许多第 2 层执行技术和范例中的任何一种，包括 rollups,11 乐观的rollups、Validium等，以及阈值信任模型，其中DON 节点执行交易。 TEF 是 FSS 的补充，旨在为其提供支持。换句话说，任何 在 TEF 中运行的应用程序可以使用 FSS。 11通常称为“zk-rollups”，这是用词不当，因为它们不一定需要零知识证明。
6.1 TEF 概述 TEF 是一种用于构建和执行高性能混合体的设计模式 smart contract SC。 根据混合 smart contract 背后的主要思想，TEF 涉及 将 SC 分解为两部分： (1) 我们在 TEF 上下文中称之为锚点 MAINCHAIN 上的合约 SCa 和 (2) DON 逻辑要求我们调用 TEF 可执行文件。 我们这里用SC来表示SCa组合实现的逻辑合约 并执行。 （如上所述，我们期望开发编译器工具来分解 SC 自动收缩到这些组件中。） TEF可执行exec是SC中处理用户交易的引擎。它 可以以高性能的方式执行，因为它在 DON 上运行。它有几个功能： • 交易摄取：exec 接收或获取用户的交易。它可以这样做 直接，即通过 DON 上的交易提交，或通过主链 使用 MS 的内存池。 • 快速交易执行：exec 处理涉及以下资产的交易 SC。它在本地执行此操作，即在 DON 上。 • 快速且低成本的oracle /适配器访问：exec 具有对 oracle 报告的本机访问权限 和其他适配器数据，例如更快、更便宜和更准确的资产 定价高于主链执行。此外，链下 oracle 访问减少了 oracle 的运营成本，即使用该系统的成本，通过避免 昂贵的链上存储。 • 同步：exec 定期将更新从DON 推送到主链，更新SCa。 锚定合约是SC的主链前端。作为 SC 的更高信任组件，它有几个用途： • 资产托管：用户的资金存入、持有和提取于SCa。 • 同步验证：SCa 可以在执行时验证状态更新的正确性 同步，例如附加到 rollups 的 SNARK。 • 护栏：SCa 可能包括防止腐败或故障的规定 期待中。 （更多详情请参见第 7 节。） 在 TEF 中，用户的资金托管在主链上，这意味着 DON 本身是非托管的。根据同步机制的选择（见下文），用户可能需要 仅信任 DON 以获得准确的 oracle 报告并及时与主链同步。 由此产生的信任模型与基于订单簿的 DEX 非常相似，例如 [2]， 如今，它通常包括用于订单匹配的链下组件和用于清算和结算的链上组件。要使用支付系统的词汇，人们可能会认为 exct 是一个组件 SC负责清算，SCa负责结算。原理图见图 13 TEF 的描述。 图 13：TEF 原理图。在此示例中，交易通过内存池 通过 MS 到 DON 的主链。 TEF的好处： TEF 具有三个主要优势： • 高性能：SC 继承了DON 比 MAINCHAIN 高得多的吞吐量 对于交易和 oracle 报告。此外，与单独在 MAINCHAIN 上实现相比，exec 可以更快地处理交易并更及时地响应 oracle 报告。 • 费用更低：同步过程对时间的敏感性低于交易处理，并且交易可以批量从DON 发送到MAINCHAIN。 因此，这种方法的每笔交易链上费用（例如，gas 成本）比仅在主链上运行的合约低得多。 • 保密性：DON 的保密机制可用于 承担SC。
TEF 限制： TEF 的一个限制是它不支持瞬时 提款，因为它们仅发生在主链上：发送提款请求后 对于SCa，用户可能需要等待execute来执行状态更新，其中包括 在获得批准之前提款交易。我们讨论一些部分补救措施， 然而，在第 6.2 节中。 TEF 的另一个限制是它不支持 DeFi 的原子组合 主链上的合约，特别是通过多个 DeFi 路由资产的能力 单一交易中的合同。然而，TEF 可以支持这种原子性 DeFi 合约在同一个 DON 上运行。我们还讨论了一些解决这个问题的方法 6.2 节中的问题。 6.2 交易路由 SC 的交易可以由用户直接发送到 DON 或可以通过 MAINCHAIN 中的内存池（通过 FSS）。有四种不同的交易类型，每种类型 其中需要不同的处理： 合约内交易： 因为它回避了气体动力学的复杂性，TEF 为 SC 在处理交易方面提供了比普通 SC 更大的灵活性。 在第 1 层合约中可用。例如，当 Ethereum 中的内存池交易时 可以被更高 Gas 价格的新交易覆盖，SC 可以在 SC 内的资产上操作的交易一旦变得可见就视为权威交易 在内存池中。因此，SC不需要等待交易被确认 在一个块内，从而大大减少延迟。 代理： 用户可能希望通过钱包合约向 SC 发送交易 τ 或 主链上的其他合约。 DON 可以模拟执行 MAINCHAIN 上的 τ 来确定是否会导致 SC 的后续交易。 如果是这样，τ 可以与 SC 的其他交易一起排序。有几个 DON 如何识别此类交易的可能性： (1) DON 可以模拟 内存池中的所有交易（一种昂贵的方法）； (2) 某些合同或 可以列出合约类型，例如钱包，以供 DON 监控；或 (3) 用户可以 注释交易以供 DON 检查。 当单个事务与两个事务交互时，事情变得更加复杂 合约 SC1 和 SC2，两者都使用公平排序服务并且具有不兼容的排序策略。例如，DON 可能会在最晚的时间对 τ 进行排序 两者兼容。 存款： 将主链资产存入 SC 的交易需要在区块中得到确认，然后 SC 才能将其视为有效。当它检测到采矿 将资产（例如以太币）发送到SCa的交易，exec可以立即确认订金。例如，它可以将 DON 的当前 oracle 报告价格应用于 资产。 提款： 如上所述，TEF 的局限性在于提款不能总是立即执行。在 rollup 类型的执行模型中，提款 请求必须与其他事务一起排序，即汇总，以便安全地进行 已处理。然而，有一些针对此限制的部分补救措施。 如果 DON 可以快速计算出 rollup 的有效性证明直到提款交易，那么观察内存池中的用户交易 τ 可以以更高的 Gas 价格发送 τ 的状态更新交易 τ ′，这是一种有益的抢先交易。 假设 τ 在 τ ′ 到达内存池之前未被开采，则 τ ′ 将先于 τ，并且 τ 将影响批准的提款。 在 TEF 变体中，依赖 DON 来计算状态更新（请参阅 下面的阈值签名变体），DON 也可以确定链下 考虑到 SC 执行时的状态，是否应该批准 τ。 DON 然后可以发送一个交易 τ ′ 来批准提款 τ，而不影响完整的交易 状态更新。 如果此方法不可行，或者在不成功的情况下，则由 DON 启动 交易 τ ′ 可以响应 τ 向用户发送资金，这样用户就不需要 发起额外交易。 6.3 正在同步 TEF 可执行文件 exec 定期将更新从 DON 推送到 MAINCHAIN， 在我们称为同步的过程中更新 SCa 的状态。可以考虑同步 作为第 2 层交易到第 1 层的传播，因此 TEF 可以利用任意数字 用于此目的的现有技术，包括 rollups [5, 12, 16, 69]，乐观 rollups [10, 11, 141]，Validium [201]，或基本阈值签名，例如阈值 BLS， Schnorr，或 ECDSA [24,54,116,202]。原则上，可信执行环境 还可以证明状态更改的正确性，提供更高性能的 rollups 的替代方案，但具有依赖于硬件的信任模型。 （例如，参见 [80]。） 下面我们比较这些同步选项的三个关键属性 技术教育框架： • 数据可用性：SC 的状态存储在哪里？至少三个选项是 在 TEF 中可用：在主链上、在 DON 上或通过某些第三方存储 IPFS 等提供商。他们实现了不同的安全保证、可用性 级别和性能概况。简而言之，在主链上存储状态可以实现 链上可审计性并消除对任何一方的状态可用性的依赖； 另一方面，链下存储状态可以降低存储成本并提高 吞吐量，以信任存储提供商（DON 或第三方）为代价 数据可用性。当然，结合这些选项的灵活模型也可以 可能的。我们在表 1 中指出了所需的数据可用性形式。• 正确性保证：SCa 如何确定更新的正确性 由exec 推动？这会影响 exect 和 SCa 的计算负载以及 同步延迟（见下文）。 • 延迟：同步延迟有三个影响因素： (1) 所花费的时间 用于生成同步交易τsync； (2) τsync 所花费的时间 待主链确认； (3) τsync 生效的时间 SC。在 TEF 中，延迟对于提款尤为重要（但对于提款来说则不那么重要） 合约内交易）因为提款必然需要（至少 部分）状态同步。 正在同步 选项 数据 可用性 正确性 保证 延迟 汇总 [5, 12, 16, 69] 链上 有效性证明 生成所需时间 有效性证明（例如当前系统中的分钟数） 维迪乌姆 [201] 链下 有效性证明 与上面相同 乐观rollup [10， 11, 141] 链上 欺诈证明 挑战时长 期间 （例如， 天 或 周） 门槛签名 [24, 54、116、202] 灵活 DON 的阈值签名 瞬时 可信执行环境 [80] 灵活 基于硬件 证明 瞬时 表 1：TEF 中的各种同步选项及其属性。 表 1 总结了 TEF 中五个主要同步选项的这些属性。 （注 我们不打算将这些技术与独立的第 2 层扩展进行比较 解决方案。为此，我们建议读者参考 [121]。） 现在我们讨论每个同步选项。 汇总： rollup [69] 是一个协议，其中状态转换由 一批交易是在链外计算的。 然后传播状态变化 到主链上。 为了实现 rollups，锚点 smart contract SCa 存储实际状态的紧凑表示 Rstate（例如 Merkle 根）。要同步，exec 发送 τsync = (T,R′ 状态）到 SCa，其中 T 是自上次以来处理的事务集同步和R′ state 是通过应用计算出的新状态的紧凑表示 T 中的交易到先前状态 Rstate。 有两种流行的变体，它们在 SCa 验证 τsync 中状态更新的方式上有所不同。 第一个，(zk-)rollups，附加一个简洁的正确性论证，有时称为 有效性证明，用于转换 Rstate →R′ 状态。要实现此变体，请执行 计算并提交有效性证明（例如，zk-SNARK 证明）以及 τsync， 证明R′ state 是将 T 应用到 SCa 当前状态的结果。锚 合约仅在验证证明后才接受状态更新。 乐观的 rollup 不包括正确性的论点，但有 staking 和 促进状态转换的分布式验证的挑战程序。为此 rollup 变体，SCa 暂时接受 τsync 假设它是正确的（因此乐观） 但 τsync 直到挑战期结束后才生效，在此期间任何一方 监控 MAINCHAIN 可以识别错误的状态更新并通知 SCa 采取措施 必要的行动（例如，回滚状态并对exec施加惩罚。） 随着交易的发布，两个 rollup 变体都实现了链上数据可用性 链上，可以从中构建完整的状态。 zk-rollups 的延迟为 主要由生成有效性证明所需的时间决定，这通常是在 现有系统 [16] 中的分钟顺序，并且随着时间的推移可能会得到改进。 另一方面，乐观的 rollups 具有更高的延迟（例如，几天或几周） 因为挑战期需要足够长才能使欺诈证明发挥作用。的 缓慢确认的含义是微妙的，有时特定于该方案，因此 彻底的分析超出了范围。例如，某些计划考虑付款 在确认状态更新之前，交易作为“无信任最终”[109]，因为 普通用户可以比主链更快地验证 rollup。 有效： Validium 是 (zk-)rollup 的一种形式，使数据仅在链外可用 并且不维护主链上的所有数据。具体来说，exec 只发送新的 状态和证明，但不向 SCa 发送交易。使用 Validium 风格的同步，执行 并且执行它的 DON 是唯一存储完整状态和 执行交易。与 zk-rollups 一样，同步延迟主要由有效性决定 证明生成时间。然而，与 zk-rollups 不同的是，Validium 风格的同步减少了 存储成本并增加吞吐量。 DON 的阈值签名： 假设 DON 个节点的阈值是诚实的， 简单而快速的同步选项是让 DON 节点共同签署新状态。 这种方法可以支持链上和链下数据的可用性。请注意，如果 用户信任 DON 的 oracle 更新，他们不需要更信任它来接受 状态更新，因为它们已经处于阈值信任模型中。 另一个好处是 阈值签名是低延迟的。支持新的交易签名格式 EIP-2938 [70] 中提出并称为帐户抽象将产生阈值 签名更容易实施，因为它将消除门槛的需要 ECDSA，涉及相当复杂的协议（例如，[116,117,118]）比阈值 Schnorr [202] 或 BLS [55] 签名等替代方案更好。 可信执行环境 (TEE)： TEE是隔离的执行环境（通常由硬件实现），旨在提供强大的安全保护 用于内部运行的程序。一些 TEE（例如 Intel SGX [84]）可以生成证明， 称为证明，输出是由特定程序正确计算的 特定的输入12。 TEF 同步的基于 TEE 的变体可以通过以下方式实现 使用技术将 (zk-)rollups 或 Validium 中的证明替换为 TEE 证明 来自 [80]。 与 rollups 和 Validium 中使用的零知识证明相比，TEE 更 性能更高。与阈值签名相比，TEE 消除了以下复杂性： 生成阈值 ECDSA 签名，因为原则上只需要一个 TEE 参与。然而，使用 TEE 确实会引入额外的依赖于硬件的信任假设。人们还可以将 TEE 与阈值签名结合起来以创建弹性 防止一小部分 TEE 实例受到损害，尽管这种保护措施 重新引入了生成阈值 ECDSA 签名的复杂性。 额外的灵活性： 可以通过以下方式改进这些同步选项以提供更大的灵活性。 • 灵活的触发：TEF 应用程序可以确定触发条件 同步被触发。例如，同步可以是基于批处理的，例如，在 每 N 个交易、基于时间的交易（例如每 10 个区块）或基于事件的交易（例如）发生 每当目标资产价格大幅变动时。 • 部分同步：这是可能的，并且在某些情况下是可取的（例如，对于 rollups， 部分同步可以减少延迟）以提供小数据的快速同步 状态量，可能仅定期执行完全同步。例如， exect 可以通过更新 SCa 中用户的余额来批准提款请求 无需另外更新 MAINCHAIN 状态。 6.4 重组 由于网络不稳定甚至 51% 攻击而导致的区块链重组 可能对主链的完整性构成威胁。在实践中，对手已经使用了 他们发起双花攻击[34]。虽然此类针对主要区块链的攻击 安装具有挑战性，但它们对于某些链条 [88] 仍然可行。 因为它独立于主链运行，所以 DON 提供了有趣的功能 观察并提供一些针对与相关重组相关的保护的可能性 攻击。 例如，DON 可以向主链上的依赖合约 SC 报告某个阈值长度 τ 的竞争分叉的存在。 DON 还可以 12 补充细节可见附录 B.2.1。他们不需要理解。
在 PoW 或 PoS 设置中提供此类分叉存在的证据。的 合约 SC 可以实施适当的防御行动，例如在一段时间内暂停进一步的交易执行（例如，允许交易所将双花列入黑名单） 资产）。请注意，尽管对手发起 51% 攻击可以寻求审查 来自 DON 的报告，SC 的一项对策是要求来自 DON 的定期报告 DON 为了处理交易（即心跳）或需要新的报告 验证高价值交易。 虽然此类分叉警报原则上是 DON 可以提供的一般服务 出于多种目的中的任何一个，我们的计划是将它们纳入 TEF。
إطار عمل تنفيذ المعاملات DON
(DON-TEF) ستوفر DONs oracle ودعم الموارد اللامركزية لحلول الطبقة الثانية داخل ما نسميه إطار عمل تنفيذ المعاملات لشبكة أوراكل اللامركزية (DONTEF) أو TEF للاختصار. اليوم، أصبح تكرار التحديثات لعقود DeFi محدودًا بزمن استجابة السلسلة الرئيسية، على سبيل المثال، متوسط الفاصل الزمني للكتلة 10-15 ثانية في Ethereum [104] - بالإضافة إلى تكلفة دفع كميات كبيرة من البيانات على السلسلة وإنتاجية حسابية/إرسالية محدودة— تحفيز أساليب التوسع مثل التجزئة [148، 158، 232] وتنفيذ الطبقة الثانية [5، 12، 121، 141، 169، 186، 187]. حتى blockchains تتميز بأوقات معاملات أسرع بكثير، على سبيل المثال، [120]، اقترحوا إستراتيجيات قياس تتضمن عمليات حسابية خارج السلسلة [168]. والمقصود من TEF هو أن يكون بمثابة مورد الطبقة الثانية لأي من أنظمة الطبقة الأولى / MAINCHAIN. باستخدام TEF، يمكن لـ DONs دعم التحديثات الأسرع في عقد MAINCHAIN أثناء الاحتفاظ بضمانات الثقة الرئيسية التي تقدمها السلسلة الرئيسية. TEF يمكن أن تدعم أي عدد من تقنيات ونماذج تنفيذ الطبقة الثانية، بما في ذلك rollups,11 متفائل rollups، Validium، وما إلى ذلك، بالإضافة إلى نموذج عتبة الثقة الذي DON العقد تنفذ المعاملات. يعتبر TEF مكملاً للخدمة الثابتة الساتلية ويهدف إلى دعمها. وبعبارة أخرى، أي يمكن للتطبيق الذي يعمل في TEF استخدام FSS. 11غالبًا ما يطلق عليها "zk-rollups"، وهي تسمية خاطئة، لأنها لا تحتاج بالضرورة إلى إثباتات المعرفة الصفرية.
6.1 نظرة عامة على TEF TEF هو نمط تصميمي لبناء وتنفيذ سيارة هجينة عالية الأداء smart contract SC. وفقًا للفكرة الرئيسية وراء الهجين smart contracts، يتضمن TEF أ تحلل SC إلى قطعتين: (1) ما نسميه في سياق TEF مرساة عقد SCa على MAINCHAIN و(2) DON المنطق باستثناء أننا نطلق على TEF القابل للتنفيذ. نستخدم SC هنا للإشارة إلى العقد المنطقي الذي يتم تنفيذه من خلال الجمع بين SCa ونتوقع. (كما هو مذكور أعلاه، نتوقع تطوير أدوات التحويل البرمجي لتحليل ملف التعاقد مع SC تلقائيًا في هذه المكونات.) إن الملف القابل للتنفيذ TEF هو المحرك الذي يعالج معاملات المستخدمين في SC. ذلك يمكن تنفيذه بطريقة فعالة، لأنه يعمل على DON. لديها عدة وظائف: • استيعاب المعاملات: يتم استلام أو جلب معاملات المستخدمين. يمكنها أن تفعل ذلك مباشرة، أي من خلال تقديم المعاملة على DON، أو عبر MAINCHAIN mempool باستخدام MS. • تنفيذ المعاملات بسرعة: تنفيذ المعاملات التي تنطوي على الأصول داخل SC. ويتم ذلك محليًا، أي على DON. • وصول سريع ومنخفض التكلفة إلى oracle / الوصول إلى المحول: يتمتع بإمكانية الوصول الأصلي إلى تقارير oracle وبيانات المحول الأخرى التي تؤدي، على سبيل المثال، إلى أصول أسرع وأرخص وأكثر دقة التسعير من تنفيذ MAINCHAIN. علاوة على ذلك، يتم تقليل الوصول خارج السلسلة oracle التكلفة التشغيلية لـ oracle، وبالتالي تكلفة استخدام النظام، عن طريق تجنب تخزين باهظ الثمن على السلسلة. • المزامنة: يتم إرسال التحديثات بشكل دوري من DON إلى MAINCHAIN، وتحديث SCa. عقد التثبيت هو الواجهة الأمامية لـ MAINCHAIN لـ SC. وباعتباره عنصر الثقة الأعلى في SC، فإنه يخدم عدة أغراض: • حفظ الأصول: يتم إيداع أموال المستخدمين والاحتفاظ بها وسحبها من SCA. • التحقق من المزامنة: قد تتحقق SCa من صحة تحديثات الحالة عند الضرورة عمليات المزامنة، على سبيل المثال، SNARKs المرفقة بـ rollups. • حواجز الحماية: قد تتضمن SCa أحكامًا للحماية من الفساد أو الفشل في التنفيذ. (انظر القسم 7 لمزيد من التفاصيل.) في TEF، يتم حفظ أموال المستخدمين على MAINCHAIN، مما يعني أن DON هو في حد ذاته غير وصاية. اعتمادا على اختيار آلية المزامنة (انظر أدناه)، قد يحتاج المستخدمون للوثوق في DON فقط للحصول على تقارير oracle الدقيقة والمزامنة في الوقت المناسب مع MAINCHAIN. نموذج الثقة الناتج مشابه جدًا لنموذج DEXes القائم على دفتر الطلبات، على سبيل المثال، [2]، والتي تشتمل اليوم بشكل عام على مكون خارج السلسلة لمطابقة الطلبات ومكون onchain للمقاصة والتسوية.لاستخدام مفردات أنظمة الدفع، يمكن للمرء أن يفكر في "التوقع" باعتباره المكون SC مسؤولة عن المقاصة، في حين تتولى SCA التسوية. انظر الشكل 13 للحصول على رسم تخطيطي تصوير TEF. الشكل 13: تخطيطي TEF. في هذا المثال، تمر المعاملات عبر مجمع الذاكرة من MAINCHAIN عبر MS إلى DON. فوائد TEF: يحمل TEF ثلاث فوائد رئيسية: • الأداء العالي: يرث SC إنتاجية DON الأعلى بكثير من MAINCHAIN لكل من المعاملات وتقارير oracle. بالإضافة إلى ذلك، يمكن لـ Exect معالجة المعاملات بشكل أسرع والاستجابة لتقارير oracle بطريقة أكثر توقيتًا من التنفيذ على MAINCHAIN وحده. • رسوم أقل: تعتبر عملية المزامنة أقل حساسية للوقت من معالجة المعاملات، ويمكن إرسال المعاملات من DON إلى MAINCHAIN على دفعات. وبالتالي، فإن الرسوم لكل معاملة على السلسلة (على سبيل المثال، تكاليف الغاز) مع هذا النهج أقل بكثير من العقد الذي يتم تشغيله فقط على MAINCHAIN. • السرية: يمكن جلب آليات السرية الخاصة بـ DON إلى تحمل على SC.
قيود TEF: أحد قيود TEF هو أنه لا يدعم اللحظية عمليات السحب، حيث أنها تتم فقط على شبكة MAINCHAIN: عند إرسال طلب السحب إلى SCa، قد يحتاج المستخدم إلى الانتظار حتى يتم إجراء تحديث الحالة الذي يتضمن معاملة السحب قبل أن تتم الموافقة عليها. نناقش بعض العلاجات الجزئية، ومع ذلك، في القسم 6.2. هناك قيود أخرى على TEF وهي أنه لا يدعم التركيب الذري لـ DeFi العقود على MAINCHAIN، وتحديدًا القدرة على توجيه الأصول عبر عدة DeFi العقود في صفقة واحدة. ومع ذلك، يمكن لـ TEF دعم هذه الذرية بين DeFi العقود التي تعمل على نفس DON. نناقش أيضًا بعض الطرق لمعالجة هذا الأمر المشكلة في القسم 6.2. 6.2 توجيه المعاملات يمكن للمستخدمين إرسال المعاملات الخاصة بـ SC مباشرة إلى DON أو يمكن توجيهها عبر مجمع الذاكرة في MAINCHAIN (عبر FSS). هناك أربعة أنواع مختلفة من المعاملات، لكل منها والتي تتطلب معالجة مختلفة: المعاملات ضمن العقد: ونظرًا لأنه يتجنب تعقيدات ديناميكيات الغاز، فإن TEF يوفر لشركة SC مرونة أكبر في التعامل مع المعاملات مما قد تكون عليه متوفر في عقد الطبقة الأولى. على سبيل المثال، أثناء معاملة mempool في Ethereum يمكن استبدالها بمعاملة جديدة بسعر غاز أعلى، يمكن لـ SC التعامل مع المعاملة التي تعمل على الأصول داخل SC باعتبارها معاملة موثوقة بمجرد أن تصبح مرئية في المذكرة. وبالتالي، لا تحتاج SC إلى الانتظار حتى يتم تأكيد المعاملة داخل كتلة، مما أدى إلى انخفاض كبير في زمن الوصول. الوكيل: قد يرغب المستخدم في إرسال معاملة τ إلى SC عبر عقد محفظة أو عقد آخر على MAINCHAIN. من الممكن أن يقوم DON بمحاكاة تنفيذ τ على MAINCHAIN لتحديد ما إذا كان سيؤدي إلى معاملة متابعة إلى SC. إذا كان الأمر كذلك، فيمكن تسلسل τ مع معاملات أخرى لـ SC تقوم بذلك. هناك عدد قليل إمكانيات كيفية تحديد DON لمثل هذه المعاملات: (1) يمكن لـ DON محاكاة جميع المعاملات في mempool (نهج مكلف)؛ (2) بعض العقود أو يمكن إدراج أنواع العقود، على سبيل المثال، المحافظ، للمراقبة بواسطة DON؛ أو (3) يمكن للمستخدمين قم بإضافة تعليق توضيحي للمعاملات الخاصة بفحص DON. تصبح الأمور أكثر تعقيدًا عندما تتفاعل معاملة واحدة مع اثنتين العقود، SC1 وSC2، وكلاهما يستخدم خدمات التسلسل العادل ولديهما سياسات طلب غير متوافقة. قد يقوم DON، على سبيل المثال، بالتسلسل τ في آخر وقت الذي يتوافق مع كليهما. الودائع: يجب تأكيد المعاملة التي تقوم بإيداع أصل MAINCHAIN في SC في كتلة قبل أن تتمكن SC من التعامل معها على أنها صالحة. عندما يكتشف التعدين أ المعاملة التي ترسل الأصول (على سبيل المثال، الأثير) إلى SCa، يمكن أن تؤكد على الفورإيداع. على سبيل المثال، يمكن تطبيق السعر الحالي الذي تم الإبلاغ عنه oracle على DON على الأصول. عمليات السحب: كما هو مذكور أعلاه، فإن أحد قيود TEF هو أنه لا يمكن دائمًا تنفيذ عمليات السحب على الفور. في نموذج التنفيذ من النوع rollup، يتم السحب يجب أن يكون الطلب متسلسلًا مع المعاملات الأخرى، أي أن يتم تجميعه، حتى يكون آمنًا معالجتها. ومع ذلك، هناك بعض العلاجات الجزئية لهذا القيد. إذا كان DON يمكنه حساب إثبات صحة rollup بسرعة حتى معاملة السحب، فإن مراقبة معاملة المستخدم τ في مجموعة الذاكرة باستثناء يمكن أن ترسل معاملة تحديث الحالة τ ′ لـ τ بسعر غاز أعلى، وهو نوع من التشغيل المسبق المفيد. بشرط ألا يتم تعدين τ قبل أن تصل τ ′ إلى مجمع الذاكرة، فإن τ ′ ستسبق τ، و τ سوف يؤدي إلى انسحاب معتمد. في متغير TEF حيث يتم الاعتماد على DON لحساب تحديثات الحالة (راجع متغير توقيع العتبة أدناه)، يمكن لـ DON تحديد خارج السلسلة بدلاً من ذلك ما إذا كان يجب الموافقة على τ نظرًا لحالة SC عند تنفيذها. DON يمكن بعد ذلك إرسال معاملة τ ′ توافق على السحب τ — دون إجراء كامل تحديث الدولة. إذا لم يكن هذا النهج ممكنًا، أو في الحالات التي لم ينجح فيها، فسيتم بدء DON يمكن للمعاملة τ ′ إرسال أموال إلى المستخدم ردًا على τ بحيث لا يحتاج المستخدم بدء معاملة إضافية. 6.3 المزامنة يقوم الملف القابل للتنفيذ TEF بدفع التحديثات بشكل دوري من DON إلى MAINCHAIN، تحديث حالة SCa في عملية نشير إليها بالمزامنة. يمكن التفكير في المزامنة كانتشار لمعاملات الطبقة الثانية إلى الطبقة الأولى، لذلك يمكن لـ TEF الاعتماد على أي رقم التقنيات الموجودة لهذا الغرض، بما في ذلك rollups [5، 12، 16، 69]، متفائلة rollups [10، 11، 141]، Validium [201]، أو توقيع الحد الأساسي، على سبيل المثال، عتبة BLS، شنور، أو ECDSA [24، 54، 116، 202]. من حيث المبدأ، بيئات التنفيذ الموثوقة يمكن أيضًا أن يشهد على صحة تغييرات الحالة، مما يوفر أداءً أفضل بكثير بديل لـ rollups، ولكن مع نموذج ثقة يعتمد على الأجهزة. (انظر، على سبيل المثال، [80].) نقارن أدناه خيارات المزامنة هذه فيما يتعلق بثلاث خصائص رئيسية في تيف: • توفر البيانات: أين يتم تخزين حالة SC؟ هناك ثلاثة خيارات على الأقل متوفر في TEF: على MAINCHAIN، أو على DON، أو عن طريق وحدة تخزين خارجية مقدمي الخدمات مثل IPFS. إنها تحقق ضمانات أمنية وتوافرًا مختلفًا المستويات وخصائص الأداء. باختصار، يتم تمكين حالة التخزين على MAINCHAIN إمكانية التدقيق على السلسلة ويلغي الاعتماد على أي طرف فيما يتعلق بتوفر الحالة؛ من ناحية أخرى، يمكن أن يؤدي تخزين الحالة خارج السلسلة إلى تقليل تكلفة التخزين وتحسينه الإنتاجية، على حساب موفري خدمات التخزين الموثوقين (DON أو الجهات الخارجية). توفر البيانات. وبطبيعة الحال، هناك أيضًا نماذج مرنة تجمع بين هذه الخيارات ممكن. نشير إلى الشكل المطلوب لتوافر البيانات في الجدول 1.• ضمانات الصحة: كيف تتأكد هيئة الرقابة المالية من صحة التحديثات مدفوعة بالتنفيذ؟ يؤثر هذا على الحمل الحسابي على exect وSCa و مزامنة الكمون (انظر أدناه). • الكمون: هناك ثلاثة عوامل مساهمة في زمن الاستجابة للمزامنة: (1) الوقت المستغرق لتوقع إنشاء معاملة مزامنة τsync؛ (2) الوقت المستغرق لـ τsync للتأكيد على MAINCHAIN؛ و (3) الوقت المناسب لتفعيل المزامنة SCA. في TEF، يعد زمن الوصول مهمًا بشكل خاص لعمليات السحب (لكنه أقل أهمية بالنسبة لعمليات السحب). المعاملات ضمن العقد) لأن عمليات السحب تتطلب بالضرورة (على الأقل جزئي) مزامنة الحالة. المزامنة خيارات البيانات التوفر صحة الضمانات الكمون التراكمي [5، 12، 16، 69] على السلسلة إثباتات الصلاحية الوقت المستغرق لتوليد إثباتات الصلاحية (على سبيل المثال، الدقائق في الأنظمة الحالية) فاليديوم [201] خارج السلسلة إثباتات الصلاحية نفس ما ورد أعلاه متفائل rollup [10، 11، 141] على السلسلة أدلة الاحتيال طول التحدي فترة (على سبيل المثال، أيام أو أسابيع) توقيع العتبة [24، 54، 116، 202] مرنة توقيعات العتبة بواسطة DON لحظية بيئات التنفيذ الموثوقة [80] مرنة على أساس الأجهزة الشهادات لحظية الجدول 1: خيارات المزامنة المختلفة في TEF وخصائصها. يلخص الجدول 1 هذه الخصائص في خيارات المزامنة الرئيسية الخمسة في TEF. (ملاحظة أننا لا ننوي مقارنة هذه التقنيات كقياس مستقل للطبقة الثانية الحلول. ولهذا نحيل القراء إلى، على سبيل المثال، [121].) الآن نناقش كل خيار من خيارات المزامنة. التجميعات: rollup [69] هو بروتوكول يتم فيه انتقال الحالة بواسطة يتم حساب مجموعة المعاملات خارج السلسلة. ثم يتم نشر تغيير الحالة على مينشين. لتنفيذ rollups، يقوم المرساة smart contract SCa بتخزين تمثيل مضغوط Rstate (على سبيل المثال، جذر Merkle) للحالة الفعلية. للمزامنة، يرسل exext τsync = (ت، ر' State) إلى SCa حيث T هي مجموعة المعاملات التي تمت معالجتها منذ آخر مرةالمزامنة وR' الحالة هي التمثيل المضغوط للحالة الجديدة المحسوبة عن طريق التطبيق المعاملات في T إلى الحالة السابقة Rstate. هناك نوعان مختلفان شائعان يختلفان في كيفية قيام SCa بالتحقق من تحديثات الحالة في τsync. الأول، (zk-)rollups، يرفق حجة موجزة للصحة، تسمى أحيانًا دليل صحة للانتقال Rstate →R′ الدولة. لتنفيذ هذا البديل، توقع يحسب ويقدم إثبات الصلاحية (على سبيل المثال، إثبات zk-SNARK) مع τsync، إثبات أن R' الحالة هي نتيجة تطبيق T على الحالة الحالية لـ SCa. المرساة لا يقبل العقد تحديث الحالة إلا بعد التحقق من الدليل. لا تتضمن rollups المتفائلة حجج الصحة، ولكنها تحتوي على staking و إجراءات التحدي التي تسهل التحقق الموزع من تحولات الحالة. لهذا متغير rollup، يقبل SCa مبدئيًا τsync على افتراض أنه صحيح (وبالتالي التفاؤل) لكن τsync لا يصبح ساري المفعول إلا بعد فترة التحدي التي يستطيع خلالها أي طرف يمكن لمراقبة MAINCHAIN تحديد تحديثات الحالة الخاطئة وإبلاغ SCa لاتخاذها الإجراءات الضرورية (على سبيل المثال، التراجع عن الحالة وإيقاع عقوبة على التنفيذ.) يحقق كلا المتغيرين rollup توفر البيانات على السلسلة، حيث يتم ترحيل المعاملات على السلسلة، والتي يمكن من خلالها بناء الحالة الكاملة. زمن الوصول لـ zk-rollups هو يهيمن عليها الوقت اللازم لإنشاء أدلة الصلاحية، والتي عادةً ما تكون على ترتيب الدقائق في الأنظمة الحالية [16] ومن المرجح أن تشهد تحسينات بمرور الوقت. من ناحية أخرى، تتمتع rollups المتفائلة بزمن وصول أعلى (على سبيل المثال، أيام أو أسابيع) لأن فترة التحدي يجب أن تكون طويلة بما يكفي حتى تنجح إثباتات الاحتيال. ال إن الآثار المترتبة على التأكيد البطيء تكون خفية وفي بعض الأحيان خاصة بالمخطط، لذلك التحليل الشامل خارج النطاق. على سبيل المثال، بعض المخططات تأخذ بعين الاعتبار الدفع المعاملات باعتبارها "نهائية غير موثوق بها" [109] قبل تأكيد تحديث الحالة، نظرًا لأن يمكن للمستخدم العادي التحقق من rollup بسرعة أكبر بكثير من MAINCHAIN. فاليديوم: Validium هو شكل من أشكال (zk-)rollup الذي يجعل البيانات متاحة خارج السلسلة فقط ولا يحتفظ بجميع البيانات الموجودة على MAINCHAIN. على وجه التحديد، exect يرسل الجديد فقط الدولة والدليل ولكن ليس المعاملات إلى SCa. مع المزامنة على غرار Validium، توقع وDON الذي ينفذها هما الطرفان الوحيدان اللذان يخزنان الحالة الكاملة و التي تنفذ المعاملات. كما هو الحال مع zk-rollups، تهيمن الصلاحية على زمن وصول المزامنة وقت توليد الإثبات. على عكس zk-rollups، فإن مزامنة نمط Validium تقلل من تكلفة التخزين ويزيد من الإنتاجية. توقيع الحد بواسطة DON: بافتراض أن عتبة العقد DON صادقة، أ خيار المزامنة البسيط والسريع هو جعل العقد DON توقع بشكل جماعي على الحالة الجديدة. يمكن أن يدعم هذا النهج توفر البيانات على السلسلة وخارجها. لاحظ أنه إذا يثق المستخدمون في DON لتحديثات oracle، ولا يحتاجون إلى الوثوق بها أكثر لقبولها تحديثات الحالة، لأنها موجودة بالفعل في نموذج ثقة العتبة. فائدة أخرى من توقيع العتبة هو الكمون المنخفض. دعم تنسيقات توقيع المعاملات الجديدة مثل المقترح في EIP-2938 [70] والمعروف باسم تجريد الحساب من شأنه أن يجعل العتبة التوقيع أسهل بكثير في التنفيذ، لأنه من شأنه أن يلغي الحاجة إلى العتبة ECDSA، والذي يتضمن بروتوكولات أكثر تعقيدًا إلى حد كبير (على سبيل المثال، [116، 117، 118])من البدائل مثل عتبة Schnorr [202] أو BLS [55] التوقيعات. بيئات التنفيذ الموثوقة (TEEs): TEEs هي بيئات تنفيذ معزولة (يتم تحقيقها عادةً بواسطة الأجهزة) تهدف إلى توفير حماية أمنية قوية للبرامج التي تعمل بالداخل. يمكن لبعض TEEs (على سبيل المثال، Intel SGX [84]) إنتاج أدلة، المعروفة باسم الشهادات، والتي يتم حساب المخرجات بشكل صحيح بواسطة برنامج محدد مدخلات معينة12. يمكن تنفيذ متغير قائم على TEE لمزامنة TEF بواسطة استبدال البراهين في (zk-)rollups أو Validium بشهادات TEE باستخدام التقنيات من [80]. بالمقارنة مع براهين المعرفة الصفرية المستخدمة في rollups وValidium، فإن TEEs أكثر أهمية أكثر أداء. بالمقارنة مع توقيع العتبة، فإن TEEs تزيل التعقيد توليد توقيعات عتبة ECDSA حيث يلزم من حيث المبدأ أن يكون هناك TEE واحد فقط المعنية. ومع ذلك، فإن استخدام TEEs يقدم افتراضات ثقة إضافية تعتمد على الأجهزة. يمكن للمرء أيضًا الجمع بين TEEs وتوقيع العتبة لخلق المرونة ضد التنازل عن جزء صغير من حالات TEE، على الرغم من أن هذا الإجراء الوقائي يعيد تقديم تعقيد إنشاء توقيعات عتبة ECDSA. مرونة إضافية: يمكن تحسين خيارات المزامنة هذه لتوفير المزيد من المرونة بالطرق التالية. • التشغيل المرن: يمكن لتطبيق TEF تحديد الظروف التي يتم بموجبها يتم تشغيل المزامنة. على سبيل المثال، يمكن أن تكون المزامنة مبنية على دفعات، على سبيل المثال، يمكن أن تتم بعد ذلك كل N من المعاملات، على أساس الوقت، على سبيل المثال، كل 10 كتل، أو على أساس الحدث، على سبيل المثال، تحدث كلما تحركت أسعار الأصول المستهدفة بشكل كبير. • المزامنة الجزئية: من الممكن، وفي بعض الحالات، مرغوبة (على سبيل المثال، مع rollups، يمكن أن تؤدي المزامنة الجزئية إلى تقليل زمن الوصول) لتوفير مزامنة سريعة للملفات الصغيرة كميات من الحالة، وإجراء المزامنة الكاملة ربما بشكل دوري فقط. على سبيل المثال، يمكن الموافقة على طلب السحب عن طريق تحديث رصيد المستخدم في SCa دون تحديث حالة MAINCHAIN. 6.4 يعيد التنظيم عمليات إعادة تنظيم Blockchain الناتجة عن عدم استقرار الشبكة أو حتى من هجمات 51٪ يمكن أن يشكل تهديدًا لسلامة السلسلة الرئيسية. ومن الناحية العملية، استخدم الخصوم لهم لشن هجمات الإنفاق المزدوج [34]. في حين أن مثل هذه الهجمات على السلاسل الرئيسية هي من الصعب تركيبها، تظل ممكنة بالنسبة لبعض السلاسل [88]. نظرًا لأنه يعمل بشكل مستقل عن MAINCHAIN، فإن DON يقدم الميزات المثيرة للاهتمام إمكانية مراقبة وتوفير بعض الحماية ضد عمليات إعادة التنظيم المرتبطة بها الهجمات. على سبيل المثال، يمكن لـ DON أن يبلغ عقدًا معتمدًا SC على MAINCHAIN بوجود شوكة منافسة بطول حد معين τ. يمكن لـ DON بالإضافة إلى ذلك 12يمكن الاطلاع على التفاصيل التكميلية في الملحق ب.2.1. ليست مطلوبة للتفاهم.
تقديم دليل - سواء في إعداد إثبات العمل (PoW) أو إثبات الحصة (PoS) - على وجود مثل هذه الشوكة. ال يمكن لعقد SC تنفيذ إجراءات دفاعية مناسبة، مثل تعليق تنفيذ المزيد من المعاملات لفترة من الوقت (على سبيل المثال، للسماح للتبادلات بإدراج عمليات الإنفاق المزدوج في القائمة السوداء الأصول). لاحظ أنه على الرغم من أن الخصم الذي يشن هجومًا بنسبة 51% يمكنه أن يسعى إلى فرض الرقابة التقارير من DON، الإجراء المضاد في SC هو طلب تقارير دورية من DON لمعالجة المعاملات (أي نبضات القلب) أو لطلب تقرير جديد التحقق من صحة صفقة ذات قيمة عالية. في حين أن تنبيهات التفرع هذه هي من حيث المبدأ خدمة عامة يمكن أن يقدمها DON ولأي عدد من الأغراض، فإن خطتنا هي دمجها مع TEF.
信任最小化
作为一个由一组异构实体参与的去中心化系统， Chainlink 网络在活性（可用性）和安全性（报告完整性）方面提供了针对故障的强大保护。然而，大多数去中心化系统在以下方面有所不同： 它们的组成部分本身分散的程度。这个 即使对于大型系统也是如此，矿工之间的权力下放有限 [32] 和 中介 [51] 早已存在。 任何去中心化努力的目标都是信任最小化：我们寻求减少 Chainlink 网络内系统性腐败或故障的不利影响，即使如此 由于恶意 DON。我们的指导原则是最小特权原则 [197]。 系统内的系统组件和参与者应具有严格范围内的权限 只允许成功完成分配给他们的角色。 这里我们列出了 Chainlink 在其驱动中采用的几种具体机制 走向更大程度的信任最小化。我们用以下术语来描述这些机制 基因座，即它们所扎根的系统组件，如图 14 所示。 解决相应小节中的每个基因座。 7.1 数据源认证 oracles 当前的操作模型受到以下事实的限制：数据源很少 对他们忽略的数据进行数字签名，很大程度上是因为 TLS 本身并不签名 数据。 TLS 确实在其“握手”协议中使用了数字签名（以建立 服务器和客户端之间的共享密钥）。因此启用 HTTPS 的服务器拥有证书 原则上可以用于签署数据的公钥，但它们通常不使用 这些证书支持数据签名。因此，DON 的安全性为 在当今的 oracle 网络中，依赖于 oracle 节点忠实地从数据中继数据 合同来源。 我们在 Chainlink 中实现信任最小化愿景的一个重要长期组成部分涉及通过支持数据签名工具和标准来加强数据源身份验证。数据签名可以帮助实施端到端的完整性保证。 原则上，如果合约接受由数据直接签名的一段数据 D 作为输入
图 14：本节讨论的信任最小化机制的轨迹。 1⃝数据 源向 2⃝DON 提供数据，该 2⃝DON 将数据功能中继到依赖项 3⃝smart contract。 此外，DON 或 oracle 网络包括 4⃝节点 主链上的管理 smart contracts，例如补偿节点、保护 导轨等。 源，则 oracle 网络无法切实篡改 D. 各种鼓励 实现此类数据签名的努力已经出现，其中包括 OpenID Connect，它 主要设计用于用户身份验证[9]，TLS-N，一个学术项目，旨在 通过重新利用 TLS 证书和 TLS 证据扩展 [63] 来扩展 TLS [191]。 尽管 OpenID Connect 已经得到了一些采用，但是 TLS 证据扩展 和 TLS-N 尚未得到采用。 数据源身份验证的另一个潜在途径是使用发布者自己的 签名 HTTP 交换 (SXG) [230]，它们可以将其缓存在内容交付网络上，作为加速移动页面 (AMP) 协议 [225] 的一部分。 Chrome 移动浏览器显示 AMP 缓存的 SXG 中的内容，就好像它们是从 他们的发布者自己的网络域而不是缓存服务器域。这种品牌激励，加上使用 CloudFlare 的 Real URL [83] 和 Google 的 amppackager [124] 等服务相对容易地启用它，可能会导致 SXG 在缓存的新闻内容中得到广泛采用，这将实现简单、防篡改的功能。 Chainlink oracles 触发有效 SXG 中报告的有新闻价值的事件的方式。 虽然来自新闻出版商的 AMP 缓存 SXG 对于快节奏内容没有用 像交易数据报告这样的应用程序，它们可以成为自定义的安全来源 与极端天气或选举结果等现实世界事件相关的合同。 我们相信简单的部署、成熟的工具和灵活性对于 加速数据源签名。使数据提供者能够使用 Chainlink 节点作为 经过身份验证的 API 前端似乎是一种很有前途的方法。我们打算创建一个节点在此模式下运行的选项，无论是否参与网络 作为一个成熟的oracle。我们将此功能称为经过身份验证的数据源 （阿杜）。通过将 Chainlink 节点与 ADO 结合使用，数据源将能够受益 来自 Chainlink 社区在添加数字方面的经验和开发的工具 为其现有的链外 API 套件提供签名功能。他们是否应该选择跑步 他们的节点为 oracles，他们还可以开辟潜在的新收入来源 与现有数据提供商采用相同的模型，例如 Kraken [28]、Kaiko [140]，以及 其他运行 Chainlink 节点来在链上出售 API 数据。 7.1.1 经过身份验证的数据来源的局限性 数据源的数字签名虽然可以帮助加强身份验证，但其本身不足以实现 oracle 的所有自然安全或操作目标 网络。 首先，给定的数据 D 仍必须以稳健且及时的方式中继 从数据源到 smart contract 或其他数据使用者的方式。也就是说，即使在 理想的设置，其中所有数据都使用预编程为依赖项的密钥进行签名 合同，仍然需要 DON 来可靠地从来源传递数据 到合同。 此外，在许多情况下，合同或其他 oracle-数据 消费者希望访问经过身份验证的各种函数计算的输出 源数据主要有两个原因： • 保密性：数据源 API 可能提供敏感或专有数据 在链上公开可见之前需要对其进行编辑或清理。 然而，对签名数据的任何修改都会使签名无效。再放一个 这样，简单的 ADO 和数据清理是不兼容的。我们在示例 3 中展示 如何通过增强形式的 ADO 协调两者。 • 数据源故障：错误和故障都会影响数据源，而数字签名无法解决这两个问题。自 [98] 成立以来，Chainlink 已 已经包含了一种修复此类故障的机制：冗余。 oracle 网络发布的报告通常代表多个网络的组合数据 来源。 现在我们讨论在 ADO 设置中探索的方案，以增强源数据的机密性并安全地组合来自多个源的数据。 7.1.2 保密性 数据源可能无法预测并提供所需的全部 API 由用户。 具体来说，用户可能希望访问预处理的数据以帮助确保 保密性。下面的例子说明了这个问题。示例 3. Alice 希望获得去中心化身份 (DID) 凭证 她已年满 18 岁（例如，因此可以申请贷款）。要做的事 因此，她需要向 DID 凭证颁发者证明有关她年龄的事实。 Alice 希望使用她所在州机动车辆管理局 (DMV) 的数据 网站为此目的。 DMV 有她的出生日期记录，并将发出 其上的数字签名证明 A 的形式如下： A = {姓名：Alice，DoB：02/16/1999}。 在此示例中，证明 A 可能足以让 Alice 向 DID 证明 凭证颁发者表示她已超过 18 岁。但这不必要地泄露了敏感信息：Alice 的 确切的 DoB。理想情况下，Alice 希望 DMV 提供的是在 简单陈述 A'，“Alice 已年满 18 岁”。换句话说，她想要的是 函数 G 在她的生日 X 上的输出，其中（非正式地），A′ = G(X) = True if 当前日期−X ≥18 年；否则，G(X) = False。 概括而言，Alice 希望能够从数据源请求签名的 证明 A′ 的形式： A′ = {名称：Alice，功能：G(X)，结果：True}， 其中 G(X) 表示函数 G 及其输入 X 的规范。我们设想 用户应该能够提供所需的 G(X) 作为她的请求的输入 相应的证明A′。 请注意，数据源的证明 A′ 必须包含规范 G(X) 确保 A′ 被正确解释。在上面的例子中，G(X)定义了含义 A′ 中的布尔值，因此 True 表示证明的主题 已年满 18 岁。 我们将用户可以指定 G(X) 的灵活查询称为函数查询。 为了支持示例 3 中的用例以及涉及查询的用例 直接来自合约，我们打算包括对涉及的功能查询的支持 作为 ADO 一部分的简单函数 G。 7.1.3 合并源数据 为了降低链上成本，合约通常被设计为消耗组合数据 来自多个来源，如以下示例所示。 示例 4（价格数据中值化）。提供价格信息，即一个的价值 资产（例如，ETH）相对于另一种资产（例如，美元），oracle 网络通常会 从多种来源（例如交易所）获取当前价格。 oracle 网络 通常将这些值的中值发送给从属合约 SC。 在具有数据签名的环境中，正常运行的 oracle 网络可以获得 来自数据源 S = {S1, . 。 。 , SnS} 值序列 V = {v1, v2, . 。 。 , vnS} 来自 带有特定源签名的 nS 源 Σ = {σ1, σ2, . 。 。 ，σnS}。之上 验证签名后，它将价格 v = mid(V ) 传输给 SC。不幸的是，没有简单的方法让 oracle 网络传输中值 将示例 4 中的 v 值传递给 SC，并提供 v 计算正确的简洁证明 σ 过度签名的输入。 一种简单的方法是在 SC 中对所有 nS 数据源的公钥进行编码。 然后 oracle 网络将中继 (V, Σ) 并允许 SC 计算 V 的中值。 然而，这将导致证明 σ 的大小为 O(nS)，即 σ 不会简洁。 它还会给 SC 带来高昂的 Gas 成本，因为 SC 需要验证中的所有签名 Σ。 相比之下，使用 SNARK 可以简洁地证明正确组合的经过身份验证的源值。在实践中可能可行，但要求相当高 证明者的计算成本，以及链上较高的天然气成本。使用 Town Crier 也是一种可能性，但需要使用 TEE，这并不适合所有人 用户的信任模型。 一个有用的概念是一种称为功能签名的加密工具，它可以解决对来自源的组合数据进行签名的一般问题。 [59, 132]。 简而言之，功能签名允许签名者委托签名能力，这样 受委托者只能对签名者选择的函数F范围内的消息进行签名。 我们在附录 D 中展示了这个功能约束如何用于限制范围 DON 发出的报告值作为数据源签名值的函数。 我们还引入了一种新的原语，称为离散函数签名，它包括对准确性的宽松要求，但可能具有更高的性能 比 SNARK 等方法更有效。 以包括源身份验证的方式组合数据源的问题 输出也适用于数据聚合器，例如 CoinCap、CoinMarketCap、CoinGecko、 CryptoCompare 等，它们从多个交易所获取数据， 基于体积的重量，使用他们在某些情况下公开的方法 在其他情况下是专有的。希望发布值的聚合器 源认证面临与节点聚合相同的挑战 源数据。 7.1.4 处理源数据 复杂的 smart contract 可能依赖于自定义聚合统计数据 主要数据源，例如许多资产近期价格历史的波动性，或 相关事件新闻中的文字和照片。 由于 DON 中的计算和带宽相对便宜，因此这些统计数据 — 即使是具有许多输入的复杂机器学习模型，也可以经济地进行处理，只要指定给 blockchain 的任何输出值都足够简洁。 对于计算密集型工作，DON 参与者可能有不同的 对于复杂输入的看法，可能需要 DON 参与者之间进行额外的沟通，以便在计算结果之前就输入达成共识。 只要最终值完全由输入决定，一旦建立输入共识，每个参与者就可以简单地计算该值并将其广播给其他参与者参与者的部分签名，或将其发送给聚合器。 7.2 DON 信任最小化 我们设想了两种主要方法来最大限度地减少对 DON 组件的信任： 故障转移客户端和少数派报告。 7.2.1 故障转移客户端 密码学和分布式系统文献中的对抗模型通常 考虑一个能够破坏（即损害）节点子集的对手， 例如，对于许多 BFT 协议来说，不到三分之一。然而，人们普遍观察到， 如果所有节点都运行相同的软件，那么识别出致命漏洞的对手就可以 原则上或多或少同时危害所有节点。这个设置经常 称为软件单一文化 [47]。 为了解决这个问题，已经提出了自动多样化软件和软件配置的各种建议，例如[47, 113]。如 [47] 中所述， 然而，软件多样性是一个复杂的问题，需要仔细考虑。例如，如果软件多样化，可能会导致比单一文化更糟糕的安全性 增加系统的攻击面，从而增加其可能的攻击向量 它提供的安全优势。 我们相信，对强大的故障转移客户端（即节点的客户端）的支持 可以在面对灾难性事件时进行转换——是一种特别有吸引力的形式 软件多样化。故障转移客户端不会增加潜在向量的数量 攻击，因为它们没有部署为主线软件。他们提供了明显的好处， 然而，作为第二道防线。我们打算在 DONs 中支持故障转移客户端 减少安全对单个客户端的依赖的关键方法。 Chainlink 已经建立了一个强大的故障转移客户端系统。我们的方法 涉及维护以前的、经过实战检验的客户端版本。例如，今天，以链外报告（OCR）作为主要客户端的 Chainlink 节点包括支持 如果需要，可用于 Chainlink 之前的 FluxMonitor 系统。已经使用了一些 目前，FluxMonitor 已经接受了安全审核和现场测试。它提供了相同的 OCR 等功能，只是成本较高——仅根据需要产生成本。 7.2.2 少数派报告 给定足够大的少数集 Ominority（观察到大多数人不法行为的诚实节点的一小部分），这对他们生成少数派可能会有所帮助 报告。这是一个并行报告或标志，转发到链上的依赖合约 SC 由少数派。 SC 可以根据其自己的合约特定策略来使用该标志。 例如，对于安全性比活性或响应性更重要的合同，少数报告可能会导致合同要求补充报告 来自另一个 DON，或触发断路器（请参阅下一节）。即使大多数人是诚实的，少数派报告也可以发挥重要作用， 因为任何报告聚合方案，即使它使用功能签名，也必须 以阈值方式操作，以确保针对 oracle 或数据故障的恢复能力。在 换句话说，必须能够根据以下人员的输入生成有效的报告： kS < nS oracles，对于某个阈值 kS。 这意味着损坏的 DON 有一些 通过在其中选择首选 kS 值来操纵报告值的自由度 nS 在 V 中由全套 oracle 报告，即使所有来源都是诚实的。 例如，假设在使用泛函的系统中 nS = 10 且 kS = 7 签名以验证 ETH 美元价格 V 上中位数的计算。 假设五个来源报告的价格为 \(500, while the other five report \)1000。 然后通过对最低 7 个报告进行中值化，DON 可以输出有效值 v = $500， 通过对最高值进行中值化，可以输出 v = $1000。 通过增强 DON 协议，使所有节点都知道哪些数据是 以及哪些数据用于构建报告，节点可以检测并标记 倾向于一组报告而不是另一组报告的统计显着趋势，并产生 结果是一份少数派报告。 7.3 护栏 我们针对 DON 的信任模型将主链视为更高安全性、更高特权 系统比DONs。 （虽然这种信任模型可能并不总是成立，但它更容易 使生成的机制适应 DON 具有更高安全性的情况 平台，反之亦然。） 因此，自然的信任最小化策略涉及在 smart contract 中实施监控和故障安全机制——无论是在主链前端 对于 DON 或直接在从属合同 SC 中。我们将这些机制称为 护栏，并在此列举一些最重要的： • 断路器：SC 可以根据状态更新本身的特征（例如，顺序更新之间的较大差异）暂停或停止状态更新。 报告）或基于其他输入。例如，断路器可能会跳闸 oracle 报告随时间变化令人难以置信的情况。断路器可能 也会被少数派报告绊倒。因此，断路器可以防止 DONs 以免做出严重错误的报告。 断路器可以为考虑额外干预措施提供时间 或锻炼。其中一种干预措施是逃生舱口。 • 逃生舱口：在不利情况下，由一组托管人、社区 token 持有者或其他受托人团体确定，合同可以援引 有时称为逃生舱口 [163] 的紧急设施。逃生舱口 导致 SC 以某种方式关闭和/或终止挂起，并且可能 未来的交易。例如，它可能会将托管资金返还给用户[17])，可以终止合同条款[162]，或者可以取消待处理和/或未来的交易[173]。逃生舱口可以部署在任何类型的合同中，而不仅仅是 依赖于 DON 的一个，但它们作为潜在的缓冲区很有趣 DON 渎职行为。 • 故障转移：在 SC 依赖 DON 提供基本服务的系统中，SC 可以提供故障转移机制来确保服务连续性，即使 在 DON 失败或行为不当的情况下。例如，在 TEF（第 6 节）中， 锚定合约SCa可以提供双接口，链上和链上都可以 某些关键操作支持链外执行接口（例如， 提款），或对于普通交易，有适当的延迟以防止 DON 交易的抢先交易。在数据源签署数据的情况下，用户可以 当 DON 未能这样做时，还需向 SCa 提供报告。 欺诈证明，如针对各种形式的乐观 rollup 所提议的（参见第 6.3 节）， 与我们上面列举的机制相似且互补。他们 也提供了一种形式的链上监控和保护，防止潜在的故障 链下系统组件。 7.4 信任最小化治理 与所有去中心化系统一样，Chainlink 网络需要治理机制 随着时间的推移调整参数、响应紧急情况并指导其演变。 其中一些机制目前驻留在主链上，并且可能会继续存在 即使部署了 DONs，也要这样做。支付机制就是一个例子 对于 oracle 节点提供商（DON 节点）。 DON 主链上的前端合约 包含额外的机制，例如护栏，可能会受到定期检查 修改。 我们预见了两类治理机制：进化机制和紧急机制。 进化治理： 对 Chainlink 生态系统的许多修改是 这样它们的实施就不是一个紧迫的问题：性能改进， 功能增强、（非紧急）安全升级等。随着 Chainlink 逐渐吸引更多参与者参与其治理，我们预计许多或 大多数此类更改均需由受这些影响的特定 DON 社区批准 变化。在此期间，也许最终作为一个并行机制，我们相信 暂时最小特权的概念可以成为实施进化治理的有用手段。很简单，这个想法是逐步部署变革，确保 社区有机会回应他们。例如，迁移到新的 MAINCHAIN 合约可以受到约束，因此必须部署新合约 激活前至少三十天。应急治理： MAINCHAIN 中可利用或被利用的漏洞 合同或其他形式的活动或安全故障可能需要立即干预，以确保避免灾难性后果。我们的目的是支持多重签名 干预机制，以确保防止任何组织的不当行为， 签名者将分散在各个组织中。确保签名者的一致性可用性 并及时联系适当的指挥系统以授权紧急情况 变革显然需要仔细的运营规划和定期审查。这些 挑战与测试其他网络安全事件响应所涉及的挑战类似 能力 [134]，具有类似的需要来解决常见问题，例如警惕性降低 [223]。 DONs 的治理不同于许多去中心化系统的治理 潜在的异质性程度。每个 DON 可能具有不同的数据源、可执行文件、服务级别要求（例如正常运行时间）和用户。 Chainlink 网络的 治理机制必须足够灵活，以适应这些变化 运营目标和参数。我们正在积极探索设计思路并计划 将来发表有关该主题的研究。 7.5 公钥基础设施 随着权力下放的逐步推进，将需要对 网络参与者，包括 DON 节点。特别是，Chainlink 需要强大的 公钥基础设施 (PKI)。 PKI 是将密钥与身份绑定的系统。对于 例如，PKI 巩固了互联网的安全连接系统 (TLS)： 您通过 HTTPS（例如 https://www.chainlinklabs.com）连接到网站，并且 浏览器中出现锁，这意味着域所有者的公钥已被锁定 已通过权威机构（具体来说，通过数字签名）与该所有者绑定 所谓的证书。证书颁发机构 (CA) 的分层系统，其顶级根颁发机构硬连线到流行的浏览器中，有助于确保证书 仅颁发给域名的合法所有者。 我们预计 Chainlink 最终将使用去中心化的名称服务， 最初是 Ethereum 名称服务 (ENS) [22]，作为我们 PKI 的基础。作为 顾名思义，ENS 类似于 DNS，即映射的域名系统 （人类可读的）域名到互联网上的 IP 地址。然而，ENS 将人类可读的 Ethereum 名称映射到 blockchain 地址。因为ENS 在 Ethereum blockchain 上运行，禁止密钥泄露、篡改其 原则上命名空间与篡改管理它的合约一样困难 和/或底层 blockchain。 （相比之下，DNS 历史上一直很脆弱 欺骗、劫持和其他攻击。） 我们已在 Ethereum 主网上向 ENS 注册了 data.eth，并打算 将其建立为根命名空间，在该根命名空间下 oracle 数据服务和 其他 Chainlink 网络实体驻留。 ENS 中的域是分层的，这意味着每个域都可能包含引用 其下的其他名称。 ENS 中的子域名可以作为组织和委托信任。 data.eth 的主要作用是作为链上目录服务 数据馈送。传统上，oracle 的开发者和用户使用链外资源 （例如，docs.chain.link 或 data.chain.link 等网站，或社交网络，例如 Twitter）发布并获取 oracle 数据源地址（例如 ETH-USD 价格 饲料）。使用高度可信的根命名空间（例如 data.eth），可以建立 eth-usd.data.eth 到例如 smart contract 地址的映射 用于 ETH-USD 价格反馈的链上 oracle 网络聚合器。这会 为任何人创建一条安全路径，将 blockchain 作为事实来源 该价格/名称对 (ETH-USD) 的数据源。因此，ENS 的这种使用 实现了链下数据源无法实现的两个好处： • 强大的安全性：对域的所有更改和更新都被永久记录 并以加密方式进行保护，而不是网站上的文本地址，这 不享有这两个安全属性。 • 自动链上传播：更新数据源的 smart contract 的底层地址可以触发传播到依赖智能的通知。 合同，例如可以自动更新相关合同 新地址.13 然而，像 ENS 这样的命名空间不会自动验证合法所有权 断言的名称。因此，例如，如果名称空间包含条目 ⟨“Acme Oracle Node Co.”，addr⟩， 那么用户就可以保证 addr 属于名称为 Acme 的声明者 Oracle Node Co. 没有围绕命名空间管理的额外机制， 然而，她无法保证该名称合法属于某个实体 在现实世界中，我们将其称为 Acme Oracle Node Co.。 我们验证名称的方法，即确保相应的、合法的现实世界实体拥有它们的所有权，依赖于几个组件。今天，Chainlink 实验室 实际上充当 Chainlink 网络的 CA。虽然 Chainlink 实验室将继续 为了验证名称，我们的 PKI 将通过两种方式演变成更加去中心化的模型： • 信任网络模型：分层 PKI 的去中心化版本通常被称为信任网络。14 自 20 世纪 90 年代以来就已经提出了各种变体， 例如，[98]，并且许多研究人员观察到 blockchain 可以通过以全局一致的方式记录证书来促进该想法的使用，例如 [227] 分类帐。我们正在探索该模型的变体来验证实体的身份 以更加去中心化的方式存在于 Chainlink 网络中。 13从属合同可以选择包括预定的延迟，以允许手动检查 以及依赖合同管理员的干预。 14 Phil Zimmermann 为 PGP [238] 创造的术语。• 与验证数据的链接：如今，大量oracle 节点性能数据在链上可见，因此存档绑定到节点地址。 此类数据可被视为通过提供其（可靠）参与网络的历史证据来丰富 PKI 中的身份。另外，工具 用于基于 DECO 和 Town Crier [160] 启用节点的去中心化身份 积累来自现实世界数据的凭证。仅举一个例子， 节点操作员可以将凭证附加到其 PKI 身份以证明拥有权 邓白氏评级。这些补充形式的验证可以 补充 staking 以确保网络安全。具有既定现实世界身份的 oracle 节点可能被视为拥有权益 在一个源于其声誉的系统中。 （参见第 4.3 节和第 9.6.3 节。） Chainlink PKI 的最终要求是安全引导，即安全地 发布 Chainlink 网络的根名称，当前为 data.eth （类似地 到浏览器中顶级域的硬连线）。换句话说，Chainlink 用户如何 确定 data.eth 确实是与 Chainlink 关联的顶级域 项目？ Chainlink 网络解决这个问题的方法是多管齐下的 可能涉及： • 将 TXT 记录 [224] 添加到指定的 chain.link 域记录中 data.eth 作为 Chainlink 生态系统的根域。 （Chainlink 因此隐式利用互联网域的 PKI 来验证其根 ENS 域。） • 从 Chainlink 的现有网站链接到 data.eth，例如来自 https://docs.chain.link. （另一种隐式使用 PKI 的互联网域。） • 通过各种文档（包括本白皮书）让人们了解 data.eth 的使用。 • 在我们的社交媒体渠道（例如 Twitter）上公开发布 data.eth，以及 Chainlink 博客 [18]。 • 将大量LINK置于同一注册者地址的控制之下 作为 data.eth。
التقليل من الثقة
باعتباره نظامًا لا مركزيًا بمشاركة مجموعة غير متجانسة من الكيانات، فإن توفر شبكة Chainlink حماية قوية ضد حالات الفشل في كل من الحيوية (التوفر) والسلامة (تكامل التقرير). ومع ذلك، تختلف معظم الأنظمة اللامركزية الدرجة التي تكون فيها المكونات المكونة لها هي نفسها لا مركزية. هذا وهذا ينطبق حتى على الأنظمة الكبيرة، حيث اللامركزية محدودة بين القائمين بالتعدين [32] و الوسطاء [51] موجودون منذ فترة طويلة. الهدف من أي جهد لتحقيق اللامركزية هو تقليل الثقة: نسعى إلى تقليل الثقة الآثار السلبية للفساد النظامي أو الفشل داخل شبكة Chainlink، حتى تلك بسبب DON الخبيثة. المبدأ التوجيهي لدينا هو مبدأ الامتياز الأقل [197]. يجب أن تتمتع مكونات النظام والجهات الفاعلة داخل النظام بامتيازات محددة النطاق بشكل صارم للسماح فقط بإكمال الأدوار المخصصة لهم بنجاح. نعرض هنا العديد من الآليات الملموسة التي يجب على Chainlink اعتمادها في مسيرتها نحو تقليل الثقة بشكل أكبر من أي وقت مضى. نحن نميز هذه الآليات من حيث للمواقع، أي مكونات النظام، التي تتجذر فيها، كما هو موضح في الشكل 14. نحن معالجة كل موضع في القسم الفرعي المعني. 7.1 مصادقة مصدر البيانات نماذج التشغيل الحالية لـ oracles مقيدة بحقيقة قلة مصادر البيانات قم بالتوقيع رقميًا على البيانات التي حذفوها، ويرجع ذلك إلى حد كبير إلى أن TLS لا يوقع أصلاً data. يستخدم TLS التوقيعات الرقمية في بروتوكول "المصافحة" الخاص به (لتأسيس مفتاح مشترك بين الخادم والعميل). وبالتالي فإن الخوادم التي تدعم HTTPS لديها شهادات على المفاتيح العامة التي يمكن من حيث المبدأ أن تعمل على توقيع البيانات، لكنها لا تستخدم بشكل عام هذه الشهادات لدعم توقيع البيانات. وبالتالي، فإن أمان DON، مثل في شبكات oracle اليوم، يعتمد على oracle العقد التي تنقل البيانات بأمانة من البيانات مصدر للعقد. يتضمن أحد المكونات المهمة طويلة المدى لرؤيتنا لتقليل الثقة في Chainlink مصادقة أقوى لمصدر البيانات من خلال دعم الأدوات والمعايير لتوقيع البيانات. يمكن أن يساعد توقيع البيانات في فرض ضمانات السلامة الشاملة. من حيث المبدأ، إذا كان العقد يقبل كمدخل قطعة من البيانات D موقعة مباشرة بواسطة البيانات
الشكل 14: مواقع آليات تقليل الثقة التي تمت مناقشتها في هذا القسم. 1⃝البيانات توفر المصادر البيانات إلى 2⃝DON، الذي ينقل وظيفة البيانات إلى تابع 3⃝smart contract. بالإضافة إلى ذلك، تتضمن شبكة DON أو oracle 4⃝ عقدة إدارة smart contracts على MAINCHAIN، على سبيل المثال، العقد التعويضية، والحماية القضبان، وما إلى ذلك. المصدر، فإن شبكة oracle لا يمكنها التلاعب بـ D. العديد من المشجعات وقد ظهرت جهود لتمكين مثل هذا التوقيع على البيانات، بما في ذلك OpenID Connect، الذي تم تصميمه بشكل أساسي لمصادقة المستخدم [9]، TLS-N، وهو مشروع أكاديمي يهدف إلى قم بتمديد TLS [191] عن طريق إعادة استخدام شهادات TLS وامتدادات أدلة TLS [63]. على الرغم من أن OpenID Connect قد شهد بعض التبني، إلا أن TLS Evidence Extensions و TLS-N لم يتم اعتمادهما بعد. هناك طريقة أخرى محتملة للتحقق من مصدر البيانات وهي استخدام مصادر البيانات الخاصة بالناشرين تبادلات HTTP الموقعة (SXG) [230]، والتي يمكنهم تخزينها مؤقتًا على شبكات تسليم المحتوى كجزء من بروتوكول Accelerated Mobile Pages (AMP) [225]. يعرض متصفح Chrome للجوال المحتوى من SXGs المخزنة مؤقتًا لـ AMP كما لو تم تقديمها منه مجالات الشبكة الخاصة بالناشرين بدلاً من مجال خادم ذاكرة التخزين المؤقت. قد يؤدي حافز العلامة التجارية هذا، إلى جانب السهولة النسبية لتمكينه باستخدام خدمات مثل عنوان URL الحقيقي الخاص بـ CloudFlare [83] وGoogle amppackager [124]، إلى اعتماد واسع النطاق لـ SXGs في محتوى الأخبار المخزن مؤقتًا، مما قد يؤدي إلى تمكين عملية بسيطة ومقاومة للتلاعب طريقة لـ Chainlink oracles لتشغيل الأحداث الجديرة بالنشر التي تم الإبلاغ عنها في SXGs الصالحة. في حين أن ملفات SXG المخزنة مؤقتًا لـ AMP من ناشري الأخبار لن تكون مفيدة للإيقاع العالي التطبيقات مثل التقارير الخاصة ببيانات التداول، يمكن أن تكون مصدرًا آمنًا للتخصيص العقود المتعلقة بأحداث العالم الحقيقي مثل الطقس القاسي أو نتائج الانتخابات. نحن نؤمن بأن النشر البسيط والأدوات الناضجة والمرونة ستكون أمرًا حيويًا تسريع توقيع مصدر البيانات. تمكين موفري البيانات من استخدام العقد Chainlink كـ تبدو الواجهة الأمامية لواجهة برمجة التطبيقات (API) المصادق عليها بمثابة نهج واعد. نحن نعتزم إنشاءخيار للعقد للعمل في هذا الوضع، مع أو بدون المشاركة في الشبكة باعتباره oracle كاملًا. ونحن نشير إلى هذه القدرة على أنها إنشاء بيانات موثقة (أدو). باستخدام عقد Chainlink مع ADO، ستتمكن مصادر البيانات من الاستفادة من الخبرة والأدوات التي طورها مجتمع Chainlink في الإضافة الرقمية إمكانات التوقيع على مجموعتهم الحالية من واجهات برمجة التطبيقات خارج السلسلة. هل يجب أن يختاروا الركض؟ عقدها كـ oracles، يمكنها بالإضافة إلى ذلك فتح مصادر دخل جديدة محتملة وفقًا لنفس النموذج مثل موفري البيانات الحاليين، على سبيل المثال، Kraken [28]، Kaiko [140]، و والبعض الآخر، الذي يقوم بتشغيل Chainlink العقد لبيع بيانات API على السلسلة. 7.1.1 القيود المفروضة على إنشاء البيانات المصادق عليها التوقيع الرقمي من خلال مصادر البيانات، على الرغم من أنه يمكن أن يساعد في تعزيز المصادقة، إلا أنه لا يكفي في حد ذاته لتحقيق جميع الأهداف الأمنية أو التشغيلية الطبيعية لـ oracle شبكة. للبدء، يجب أن يتم نقل جزء معين من البيانات بطريقة قوية وفي الوقت المناسب من مصدر البيانات إلى smart contract أو مستهلك بيانات آخر. أي حتى في إعداد مثالي يتم فيه توقيع جميع البيانات باستخدام مفاتيح مبرمجة مسبقًا لتصبح تابعة العقود، ستظل هناك حاجة إلى DON لتوصيل البيانات بشكل موثوق من المصادر إلى العقود. بالإضافة إلى ذلك، هناك عدد من الحالات التي تكون فيها العقود أو بيانات oracle الأخرى يريد المستهلكون الوصول إلى المخرجات المصادق عليها لمختلف الوظائف المحسوبة مصدر البيانات لسببين رئيسيين: • السرية: قد توفر واجهة برمجة تطبيقات مصدر البيانات بيانات حساسة أو خاصة التي يجب تنقيحها أو تطهيرها قبل أن تصبح مرئية للعامة على السلسلة. ومع ذلك، فإن أي تعديل على البيانات الموقعة يبطل التوقيع. ضع آخر الطريقة، ADO السذاجة وتعقيم البيانات غير متوافقة. نعرض في المثال 3 كيف يمكن التوفيق بين الاثنين من خلال نموذج محسّن من ADO. • أخطاء مصدر البيانات: يمكن أن تؤثر الأخطاء والفشل على مصادر البيانات، ولا تعالج التوقيعات الرقمية أي مشكلة. منذ بدايتها [98]، Chainlink لديها لقد أدرجت بالفعل آلية لمعالجة مثل هذه الأخطاء: التكرار. عادةً ما تمثل التقارير الصادرة عن شبكات oracle البيانات المجمعة المتعددة مصادر. نناقش الآن المخططات التي نستكشفها في إعداد ADO لتعزيز سرية البيانات المصدر ودمج البيانات من مصادر متعددة بشكل آمن. 7.1.2 السرية قد لا تتوقع مصادر البيانات النطاق الكامل لواجهات برمجة التطبيقات المطلوبة وتتيحه من قبل المستخدمين. وعلى وجه التحديد، قد يرغب المستخدمون في الوصول إلى البيانات المعالجة مسبقًا للمساعدة في ضمان ذلك السرية. يوضح المثال التالي المشكلة.مثال 3. ترغب أليس في الحصول على بيانات اعتماد الهوية اللامركزية (DID). أن عمرها يتجاوز 18 عامًا (وبالتالي يمكنها، على سبيل المثال، الحصول على قرض). للقيام به لذا، فهي بحاجة إلى إثبات هذه الحقيقة المتعلقة بعمرها إلى جهة إصدار أوراق اعتماد اضطراب الشخصية الانفصامية. تأمل أليس في استخدام البيانات من إدارة المركبات الآلية (DMV) في ولايتها موقع الكتروني لهذا الغرض. لدى DMV سجل بتاريخ ميلادها وسوف ينبعث منها ملف شهادة موقعة رقميا (أ) عليها بالنموذج التالي: أ = {الاسم: أليس، DoB: 16/02/1999}. في هذا المثال، قد تكون الشهادة A كافية لإثبات أليس لاضطراب الشخصية الانفصامية مصدر أوراق الاعتماد أن عمرها يزيد عن 18 عامًا. لكنها تسرب معلومات حساسة بلا داعٍ: معلومات أليس DoB بالضبط. من الناحية المثالية، ما تريده أليس من DMV بدلاً من ذلك هو التوقيع على ملف عبارة بسيطة أ′ مفادها أن "عمر أليس يزيد عن 18 عامًا." وبعبارة أخرى، فهي تريد إخراج الدالة G في تاريخ ميلادها X، حيث (بشكل غير رسمي)، A′ = G(X) = True if التاريخ الحالي −X ≥18 سنة؛ وبخلاف ذلك، G(X) = خطأ. للتعميم، تود أليس أن تكون قادرة على طلب توقيع من مصدر البيانات الإقرار "أ" من النموذج: A′ = {الاسم: أليس، الوظيفة:G(X)، النتيجة: صحيح}، حيث تشير G(X) إلى مواصفات الدالة G ومدخلاتها (مدخلاتها) X. نحن نتصور أن المستخدم يجب أن يكون قادرًا على تقديم G(X) المطلوب كمدخل مع طلبه للحصول على الشهادة المقابلة أ'. لاحظ أن شهادة مصدر البيانات A′ يجب أن تتضمن المواصفات G(X) الخاصة بها تأكد من تفسير A′ بشكل صحيح. في المثال أعلاه، يحدد G(X) المعنى للقيمة المنطقية في A′ وبالتالي فإن True يدل على موضوع الشهادة يزيد عمره عن 18 عامًا. نشير إلى الاستعلامات المرنة التي يمكن للمستخدم من خلالها تحديد G(X) كاستعلامات وظيفية. من أجل دعم حالات الاستخدام مثل تلك الموجودة في المثال 3، بالإضافة إلى تلك التي تتضمن استعلامات مباشرة من العقود، نعتزم تضمين الدعم للاستفسارات الوظيفية التي تنطوي على وظائف بسيطة G كجزء من ADO. 7.1.3 الجمع بين بيانات المصدر لتقليل التكاليف على السلسلة، تم تصميم العقود بشكل عام لاستهلاك البيانات المجمعة من مصادر متعددة، كما هو موضح في المثال التالي. المثال 4 (توسيط بيانات الأسعار). لتوفير تغذية الأسعار، أي قيمة واحدة الأصل (على سبيل المثال، ETH) فيما يتعلق بأصل آخر (على سبيل المثال، الدولار الأمريكي)، فإن شبكة oracle ستتم بشكل عام الحصول على الأسعار الحالية من عدد من المصادر، مثل البورصات. شبكة oracle يرسل عادةً إلى العقد التابع SC متوسط هذه القيم. في بيئة تحتوي على توقيع البيانات، يتم الحصول على شبكة oracle تعمل بشكل صحيح من مصادر البيانات S = {S1, . . . , SnS} سلسلة من القيم V = {v1, v2, . . . ، vnS} من مصادر nS المصاحبة للتوقيعات الخاصة بالمصدر Σ = {σ1, σ2, . . . ، σnS}. على التحقق من التوقيعات، فإنه ينقل السعر v = الوسيط (V ) إلى SC.لسوء الحظ، لا توجد طريقة بسيطة لشبكة oracle لنقل الوسيط القيمة v في المثال 4 إلى SC مع دليل موجز σ∗ أنه تم حساب v بشكل صحيح على المدخلات الموقعة. قد يكون النهج الساذج هو تشفير المفاتيح العامة لجميع مصادر بيانات nS في SC. ستقوم الشبكة oracle بعد ذلك بترحيل (V, Σ) وتسمح لـ SC بحساب متوسط V . ومع ذلك، قد يؤدي هذا إلى إثبات σ للحجم O(nS) — أي أن σ∗ لن يكون موجزًا. كما أنه سيتكبد تكاليف غاز عالية بالنسبة لشركة SC، والتي ستحتاج إلى التحقق من جميع التوقيعات فيها Σ. في المقابل، يتيح استخدام SNARKs دليلاً موجزًا لقيم المصدر الموثقة المدمجة بشكل صحيح. قد يكون الأمر قابلاً للتطبيق في الممارسة العملية، لكنه يفرض نسبة عالية إلى حد ما التكاليف الحسابية على المُثبِّت، وتكاليف الغاز المرتفعة إلى حدٍ ما على السلسلة. استخدام يعد Town Crier أيضًا احتمالًا، ولكنه يتطلب استخدام TEEs، وهو ما لا يناسب الجميع نماذج ثقة المستخدمين. أحد المفاهيم المفيدة التي يمكن من خلالها وضع حلول للمشكلة العامة المتمثلة في توقيع البيانات المجمعة من المصادر هو أداة التشفير المعروفة باسم التوقيعات الوظيفية [59، 132]. باختصار، تسمح التوقيعات الوظيفية للموقّع بتفويض القدرة على التوقيع، على هذا النحو يمكن للمفوض فقط التوقيع على الرسائل في نطاق الوظيفة F التي اختارها الموقع. نوضح في الملحق د كيف يمكن لهذا القيد الوظيفي أن يعمل على تقييد النطاق لقيم التقرير المنبعثة من DON كدالة للقيم الموقعة بواسطة مصادر البيانات. نقدم أيضًا بدائيًا جديدًا، يُسمى التوقيع الوظيفي المنفصل، والذي يتضمن متطلبًا مريحًا للدقة، ولكنه من المحتمل أن يكون أكثر أداءً من الأساليب مثل SNARKs. مشكلة دمج مصادر البيانات بطريقة تتضمن توثيق المصدر من المخرجات تنطبق أيضًا على مجمعي البيانات، على سبيل المثال، CoinCap، وCoinMarketCap، وCoinGecko، CryptoCompare، وما إلى ذلك، التي تحصل على البيانات من عدد كبير من البورصات، والتي تقوم بها الوزن على أساس المجلدات، باستخدام المنهجيات التي يعلنونها في بعض الحالات وتكون في حالات أخرى مملوكة. المجمع الذي يرغب في نشر قيمة معه تواجه مصادقة المصدر نفس التحدي الذي تواجهه مجموعة من العقد المجمعة بيانات المصدر. 7.1.4 معالجة بيانات المصدر من المرجح أن تعتمد smart contracts المتطورة على إحصائيات مجمعة مخصصة مصادر البيانات الأولية، مثل التقلبات في تاريخ الأسعار الحديث على العديد من الأصول، أو النصوص والصور من الأخبار حول الأحداث ذات الصلة. نظرًا لأن الحساب وعرض النطاق الترددي رخيصان نسبيًا في DON، فإن هذه الإحصائيات — حتى نماذج التعلم الآلي المعقدة التي تحتوي على العديد من المدخلات - يمكن معالجتها اقتصاديًا، طالما أن أي قيمة مخرجات مخصصة لـ blockchain موجزة بدرجة كافية. بالنسبة للمهام الحسابية المكثفة حيث قد يختلف المشاركون في DON وجهات النظر حول المدخلات المعقدة، قد تكون هناك حاجة إلى جولات إضافية من الاتصال بين المشاركين في DON للتوصل إلى توافق في الآراء حول المدخلات قبل حساب النتيجة. وطالما تم تحديد القيمة النهائية بالكامل من خلال المدخلات، بمجرد التوصل إلى إجماع على المدخلات، يمكن لكل مشارك ببساطة حساب القيمة وبثها إلى الآخرالمشاركين مع توقيعهم الجزئي، أو إرساله إلى المجمع. 7.2 DON تقليل الثقة نحن نتصور طريقتين رئيسيتين لتقليل الثقة الموضوعة في مكونات DON: عملاء تجاوز الفشل وتقارير الأقلية. 7.2.1 عملاء تجاوز الفشل النماذج العدائية في علم التشفير وأدبيات الأنظمة الموزعة عادةً النظر في وجود خصم قادر على إفساد (أي المساومة) مجموعة فرعية من العقد، على سبيل المثال، أقل من الثلث للعديد من بروتوكولات BFT. ومع ذلك، فمن الملاحظ عادة، أنه إذا كانت جميع العقد تشغل برنامجًا متطابقًا، فإن الخصم الذي يتعرف على استغلال مميت يمكن أن يفعل ذلك من حيث المبدأ، فإنه يؤدي إلى تسوية جميع العقد بشكل أو بآخر في وقت واحد. هذا الإعداد في كثير من الأحيان يشار إليها باسم الثقافة الأحادية البرمجية [47]. تم طرح مقترحات مختلفة للتنويع التلقائي للبرامج وتكوينات البرامج لمعالجة المشكلة، على سبيل المثال، [47، 113]. كما هو مذكور في [47]، ومع ذلك، يعد تنوع البرامج مسألة معقدة وتتطلب دراسة متأنية. على سبيل المثال، قد يؤدي تنويع البرمجيات إلى ظروف أمنية أسوأ من الثقافة الأحادية يزيد من سطح هجوم النظام وبالتالي يزيد من ناقلات الهجوم المحتملة المزايا الأمنية التي تقدمها. نحن نؤمن بأن دعم عملاء تجاوز الفشل الأقوياء — أي العملاء الذين تنتمي إليهم العقد يمكن أن يتحول في مواجهة حدث كارثي - وهو شكل جذاب بشكل خاص تنويع البرمجيات. لا يقوم عملاء تجاوز الفشل بزيادة عدد المتجهات المحتملة للهجوم، حيث لم يتم نشرها كبرامج رئيسية. أنها توفر فوائد واضحة، ومع ذلك، كخط دفاع ثان. نعتزم دعم عملاء تجاوز الفشل في DONs كـ وسيلة رئيسية لتقليل اعتمادهم على عميل واحد للأمان. Chainlink لديه بالفعل نظام قوي لعملاء تجاوز الفشل. نهجنا يتضمن الحفاظ على إصدارات العميل السابقة التي تم اختبارها في المعركة. اليوم، على سبيل المثال، Chainlink العقد مع التقارير خارج السلسلة (OCR) كعميلها الأساسي تتضمن الدعم لنظام FluxMonitor السابق الخاص بـ Chainlink إذا لزم الأمر. وقد تم استخدامها لبعض بمرور الوقت، تلقت FluxMonitor عمليات تدقيق أمنية واختبارات ميدانية. وهو يوفر نفس الشيء وظيفة مثل التعرف الضوئي على الحروف، بتكلفة أعلى - وهي تكلفة يتم تكبدها فقط على أساس الحاجة. 7.2.2 تقارير الأقليات بالنظر إلى وجود أقلية كبيرة بما فيه الكفاية في مجموعة "الأهمية" - وهي جزء صغير من العقد الصادقة التي تراقب المخالفات من قبل الأغلبية - فقد يكون من المفيد بالنسبة لهم إنشاء أقلية تقرير. هذا عبارة عن تقرير أو علامة موازية، يتم ترحيلها إلى عقد تابع لـ SC على السلسلة بواسطة الأومية. يمكن للجنة العليا الاستفادة من هذا العلم وفقًا لسياستها الخاصة بالعقد. على سبيل المثال، بالنسبة للعقد الذي تكون فيه السلامة أكثر أهمية من الحيوية أو الاستجابة، قد يؤدي تقرير الأقلية إلى مطالبة العقد بتقارير تكميلية من DON آخر، أو قم بتشغيل قاطع الدائرة الكهربائية (انظر القسم التالي).يمكن لتقارير الأقلية أن تلعب دوراً هاماً حتى عندما تكون الأغلبية صادقة، لأن أي نظام لتجميع التقارير، حتى لو كان يستخدم التوقيعات الوظيفية، يجب أن يكون كذلك تعمل بطريقة عتبة، لضمان المرونة ضد oracle أو فشل البيانات. في وبعبارة أخرى، يجب أن يكون من الممكن إنتاج تقرير صالح بناءً على مدخلات kS < nS oracles، بالنسبة لبعض العتبات kS. وهذا يعني أن DON تالف به بعض خط العرض في معالجة قيم التقرير عن طريق تحديد قيم kS المفضلة له من بين تم الإبلاغ عن nS في V بواسطة المجموعة الكاملة من oracles، حتى لو كانت جميع المصادر صادقة. على سبيل المثال، لنفترض أن nS = 10 وkS = 7 في نظام يستخدم وظيفة التوقيع لمصادقة حساب الوسيط على V لسعر ETH بالدولار الأمريكي. لنفترض أن خمسة مصادر أبلغت عن سعر \(500, while the other five report \)1000. ثم من خلال توسط التقارير السبعة الأدنى، يمكن لـ DON إخراج قيمة صالحة v = $500، ومن خلال توسط الأعلى، يمكن إخراج v = 1000 دولار. من خلال تعزيز بروتوكول DON بحيث تكون جميع العقد على علم بالبيانات الموجودة المتاحة، والبيانات التي تم استخدامها لإنشاء تقرير، يمكن للعقد اكتشافها ووضع علامة عليها ميول ذات دلالة إحصائية لتفضيل مجموعة واحدة من التقارير على أخرى، وإنتاجها تقرير أقلية نتيجة لذلك. 7.3 قضبان الحراسة نموذج الثقة الخاص بنا لـ DONs يعامل MAINCHAIN باعتباره أمانًا أعلى وامتيازًا أعلى النظام من DONs. (على الرغم من أن نموذج الثقة هذا قد لا يكون صحيحًا دائمًا، إلا أنه أسهل لتكييف الآلية الناتجة مع المواقف التي يكون فيها DON هو الأمان الأعلى منصة وليس العكس.) وبالتالي، تتضمن إستراتيجية تقليل الثقة الطبيعية تنفيذ آليات المراقبة والتأمين من الفشل في smart contracts — إما في الواجهة الأمامية لـ MAINCHAIN لـ DON أو مباشرة في عقد تابع SC. ونشير إلى هذه الآليات باسم قضبان الحماية، ونذكر بعضًا من أهمها هنا: • قواطع الدائرة: قد تقوم SC بإيقاف تحديثات الحالة مؤقتًا أو إيقافها كوظيفة لأي من خصائص تحديثات الحالة نفسها (على سبيل المثال، التباين الكبير عبر التسلسل التقارير) أو بناءً على مدخلات أخرى. على سبيل المثال، قد يتعطل قاطع الدائرة الكهربائية الحالات التي تختلف فيها تقارير oracle بشكل غير معقول بمرور الوقت. قد يكون قاطع الدائرة الكهربائية أيضا أن تتعثر من خلال تقرير الأقلية. وبالتالي، يمكن أن تمنع قواطع الدائرة DONs من تقديم تقارير خاطئة بشكل صارخ. يمكن أن توفر قواطع الدائرة الوقت اللازم للنظر في تدخلات إضافية أو تمارس. أحد هذه التدخلات هو فتحات الهروب. • فتحات الهروب: في ظل الظروف المعاكسة، كما تحددها مجموعة من الأمناء أو أصحاب token المجتمع أو هيئات الأمناء الأخرى، قد يتم استدعاء العقد منشأة الطوارئ تسمى أحيانًا فتحة الهروب [163]. فتحة الهروب يتسبب في إغلاق SC بطريقة ما و/أو إنهاء الأمر المعلق وربما المعاملات المستقبلية. على سبيل المثال، قد تقوم بإرجاع الأموال المحفوظة إلى المستخدمين [17])،يجوز له إنهاء شروط العقد [162]، أو يجوز له إلغاء المعاملات المعلقة و/أو المعاملات المستقبلية [173]. يمكن نشر فتحات الهروب في أي نوع من العقود، وليس فقط واحدة تعتمد على DON، ولكنها ذات أهمية كمنطقة عازلة محتملة ضد DON المخالفات. • تجاوز الفشل: في الأنظمة التي تعتمد فيها SC على DON للخدمات الأساسية، من الممكن أن توفر SC آليات تجاوز الفشل التي تضمن استمرار الخدمة حتى في حالة DON الفشل أو سوء السلوك. على سبيل المثال، في TEF (القسم 6)، قد يوفر عقد الارتساء SCa واجهات مزدوجة حيث يمكن لكل من السلسلة و يتم دعم واجهات التنفيذ خارج السلسلة لبعض العمليات الهامة (على سبيل المثال، السحب)، أو للمعاملات العادية، مع تأخير مناسب لمنع التشغيل الأولي لمعاملات DON. في الحالات التي تقوم فيها مصادر البيانات بالتوقيع على البيانات، يمكن للمستخدمين ذلك قم أيضًا بتقديم التقارير إلى SCa عندما يفشل DON في القيام بذلك. أدلة الاحتيال، كما هو مقترح لأشكال مختلفة من التفاؤل rollup (انظر القسم 6.3)، متشابهة في النكهة ومكملة للآليات التي ذكرناها أعلاه. هم توفر أيضًا شكلاً من أشكال المراقبة والحماية على السلسلة ضد الأعطال المحتملة في مكونات النظام خارج السلسلة. 7.4 الحوكمة قليلة الثقة مثل كافة الأنظمة اللامركزية، تتطلب شبكة Chainlink آليات حوكمة لضبط المعلمات مع مرور الوقت، والاستجابة لحالات الطوارئ، وتوجيه تطورها. بعض هذه الآليات موجودة حاليًا على MAINCHAIN، وقد تستمر افعل ذلك حتى مع نشر DONs. أحد الأمثلة على ذلك هو آلية الدفع لموفري العقد oracle (DON العقد). DON العقود الأمامية على MAINCHAIN تحتوي على آليات إضافية، مثل حواجز الحماية، التي قد تخضع للفحص الدوري التعديل. نتوقع فئتين من آليات الحكم: التطورية والطارئة. الحكم التطوري: العديد من التعديلات على النظام البيئي Chainlink موجودة بحيث لا يكون تنفيذها مسألة ملحة: تحسينات الأداء، تحسينات الميزات، وترقيات الأمان (غير العاجلة)، وما إلى ذلك. مع تحرك Chainlink تدريجيًا نحو المزيد من المشاركين في إدارتها، نتوقع وجود عدد كبير أو يجب أن يتم التصديق على معظم هذه التغييرات من قبل مجتمع DON المحدد المتأثر بتلك التغييرات التغييرات. في هذه الأثناء، وربما في نهاية المطاف كآلية موازية، نعتقد أن فكرة الامتياز الزمني الأقل يمكن أن تكون وسيلة مفيدة لتنفيذ الحكم التطوري. بكل بساطة، الفكرة هي نشر التغييرات تدريجيًا، وضمان ذلك فرصة للمجتمع للرد عليها. على سبيل المثال، الهجرة إلى مكان جديد يمكن تقييد عقد MAINCHAIN بحيث يجب نشر العقد الجديد قبل ثلاثين يومًا على الأقل من التنشيط.إدارة الطوارئ: نقاط الضعف القابلة للاستغلال أو المستغلة في MAINCHAIN قد تتطلب العقود أو غيرها من أشكال الفشل في الحياة أو السلامة تدخلاً فوريًا لضمان عدم حدوث نتائج كارثية. هدفنا هو دعم multisig آلية التدخل التي من خلالها، لضمان ضد المخالفات من قبل أي منظمة، سيتم توزيع الموقعين عبر المنظمات. ضمان التوافر المستمر للموقعين والوصول في الوقت المناسب إلى التسلسل القيادي المناسب للتصريح بحالات الطوارئ من الواضح أن التغييرات ستتطلب تخطيطًا تشغيليًا دقيقًا ومراجعة منتظمة. هذه التحديات مماثلة لتلك المشاركة في اختبار الاستجابة لحوادث الأمن السيبراني الأخرى القدرات [134]، مع حاجة مماثلة لمكافحة المشاكل الشائعة مثل انخفاض اليقظة [223]. تختلف إدارة DONs عن العديد من الأنظمة اللامركزية في الدرجة المحتملة من عدم التجانس. قد يحتوي كل DON على مصادر بيانات مميزة، وملفات قابلة للتنفيذ، ومتطلبات مستوى الخدمة مثل وقت التشغيل، والمستخدمين. شبكة Chainlink ويجب أن تكون آليات الإدارة مرنة بما يكفي لاستيعاب مثل هذه الاختلافات الأهداف والمعايير التشغيلية. نحن نستكشف بنشاط أفكار التصميم ونخطط لذلك نشر بحث حول هذا الموضوع في المستقبل. 7.5 البنية التحتية للمفتاح العام ومع اللامركزية التقدمية ستأتي الحاجة إلى تحديد قوي لـ المشاركون في الشبكة، بما في ذلك العقد DON. على وجه الخصوص، Chainlink يتطلب قويًا البنية التحتية للمفتاح العام (PKI). PKI هو نظام يربط المفاتيح بالهويات. ل على سبيل المثال، تدعم البنية التحتية للمفاتيح العمومية (PKI) نظام الاتصالات الآمنة (TLS) على الإنترنت: متى تتصل بموقع ويب عبر HTTPS (على سبيل المثال، https://www.chainlinklabs.com) و يظهر القفل في متصفحك، وهذا يعني أن المفتاح العام لمالك النطاق موجود تم ربطها بهذا المالك من خلال سلطة ما - على وجه التحديد، من خلال التوقيع الرقمي في ما يسمى بالشهادة. يساعد النظام الهرمي للمراجع المصدقة (CAs)، التي تم ربط سلطاتها الجذرية ذات المستوى الأعلى في المتصفحات الشائعة، على ضمان أن الشهادات يتم إصدارها فقط للمالكين الشرعيين للنطاقات. نتوقع أن يستفيد Chainlink في النهاية من خدمات الأسماء اللامركزية، في البداية Ethereum خدمة الأسماء (ENS) [22]، كأساس لبنية المفاتيح العمومية الخاصة بنا. كما يشير اسمها إلى أن ENS يشبه DNS، وهو نظام اسم المجال الذي يقوم بالتخطيط (يمكن قراءتها بواسطة الإنسان) إلى عناوين IP على الإنترنت. ومع ذلك، يقوم ENS بدلاً من ذلك بتعيين أسماء Ethereum القابلة للقراءة بواسطة الإنسان إلى عناوين blockchain. لأن إنس يعمل على Ethereum blockchain، باستثناء التسوية الرئيسية، والتلاعب به تعتبر مساحة الاسم من حيث المبدأ صعبة مثل التلاعب بالعقد الذي يديرها و/أو blockchain الأساسي. (في المقابل، كان نظام أسماء النطاقات (DNS) عرضة للخطر تاريخياً للانتحال والاختطاف والهجمات الأخرى.) لقد قمنا بتسجيل data.eth مع ENS على الشبكة الرئيسية Ethereum، ونعتزم القيام بذلك قم بتأسيسها كمساحة اسم جذر يتم بموجبها تحديد هويات خدمات البيانات oracle و توجد كيانات شبكة Chainlink أخرى. المجالات في ENS هرمية، مما يعني أن كل مجال قد يحتوي على مراجع إلى غير ذلك من الأسماء تحته. يمكن أن تكون النطاقات الفرعية في ENS بمثابة وسيلة لتنظيم وتفويض الثقة. سيكون الدور الرئيسي لـ data.eth هو العمل كخدمة دليل على السلسلة خلاصات البيانات. تقليديًا، استخدم مطورو ومستخدمو oracles مصادر خارج السلسلة (على سبيل المثال، مواقع الويب مثل docs.chain.link أو data.chain.link، أو الشبكات الاجتماعية مثل Twitter) لنشر والحصول على عناوين خلاصة البيانات oracle (مثل سعر ETH-USD تغذية). باستخدام مساحة اسم جذر جديرة بالثقة للغاية مثل data.eth، من الممكن بدلاً من ذلك إنشاء تعيين لـ eth-usd.data.eth، على سبيل المثال، العنوان smart contract لمجمع شبكة oracle على السلسلة لموجز أسعار ETH-USD. هذا من شأنه إنشاء مسار آمن لأي شخص للإشارة إلى blockchain كمصدر الحقيقة تغذية البيانات الخاصة بزوج السعر/الاسم (ETH-USD). ونتيجة لذلك، مثل هذا الاستخدام لـ ENS يحقق فائدتين غير متوفرتين في مصادر البيانات خارج السلسلة: • أمان قوي: يتم تسجيل كافة التغييرات والتحديثات التي يتم إجراؤها على المجال بشكل ثابت وتأمينها بطريقة مشفرة، على عكس العناوين النصية الموجودة على موقع الويب، والتي لا تتمتع بأي من هاتين الخاصيتين الأمنيتين. • النشر الآلي على السلسلة: يمكن أن تؤدي التحديثات على العنوان الأساسي لملف البيانات smart contract إلى تشغيل إشعارات تنتشر إلى الأجهزة الذكية التابعة العقود، ويمكنه، على سبيل المثال، تحديث العقود التابعة تلقائيًا باستخدام العناوين الجديدة.13 ومع ذلك، فإن مساحات الأسماء مثل ENS لا تتحقق تلقائيًا من صحة الملكية الشرعية من الأسماء المؤكدة. وبالتالي، على سبيل المثال، إذا كانت مساحة الاسم تتضمن الإدخال ⟨"شركة Acme Oracle Node Co."، العنوان⟩، ثم يحصل المستخدم على تأكيد بأن العنوان ينتمي إلى المدعي بالاسم Acme Oracle Node Co. بدون آليات إضافية حول إدارة مساحة الاسم، ومع ذلك، فهي لا تحصل على تأكيد بأن الاسم ينتمي إلى كيان بشكل قانوني تسمى Acme Oracle Node Co. بالمعنى الحقيقي للمعنى. يعتمد نهجنا في التحقق من صحة الأسماء، أي ضمان ملكيتها من قبل كيانات العالم الحقيقي الشرعية المقابلة، على عدة مكونات. اليوم، Chainlink مختبرات يعمل بشكل فعال كمرجع مصدق لشبكة Chainlink. بينما ستستمر Chainlink المختبرات وللتحقق من صحة الأسماء، ستتطور البنية التحتية للمفاتيح العمومية (PKI) الخاصة بنا إلى نموذج أكثر لامركزية بطريقتين: • نموذج شبكة الثقة: يُشار غالبًا إلى النظير اللامركزي لبنية المفاتيح العمومية الهرمية باسم شبكة الثقة. وقد تم اقتراح متغيرات منذ التسعينيات، على سبيل المثال، [98]، وقد لاحظ عدد من الباحثين أن blockchains يمكنها تسهيل استخدام الفكرة، على سبيل المثال، [227] من خلال تسجيل الشهادات بطريقة متسقة عالميًا دفتر الأستاذ. نحن نستكشف المتغيرات لهذا النموذج للتحقق من هويات الكيانات في شبكة Chainlink بطريقة أكثر لامركزية. يمكن أن يتضمن العقد التابع 13A بشكل اختياري تأخيرًا محددًا مسبقًا للسماح بالفحص اليدوي والتدخل من قبل مسؤولي العقود التابعة. 14مصطلح صاغه فيل زيمرمان لـ PGP [238].• الارتباط بالتحقق من صحة البيانات: اليوم، هناك قدر كبير من بيانات أداء العقدة oracle مرئية على السلسلة، وبالتالي مرتبطة أرشيفيًا بعناوين العقد. يمكن النظر إلى مثل هذه البيانات على أنها إثراء للهوية في البنية التحتية للمفاتيح العمومية من خلال تقديم دليل تاريخي على مشاركتها (الموثوقة) في الشبكة. بالإضافة إلى الأدوات للهوية اللامركزية المستندة إلى DECO وTown Crier [160] تمكين العقد لتجميع بيانات الاعتماد المستمدة من بيانات العالم الحقيقي. وكمثال واحد فقط، أ يمكن لمشغل العقدة إرفاق بيانات اعتماد بهوية PKI الخاصة به والتي تثبت الحيازة من تصنيف دون وبرادستريت. يمكن لهذه الأشكال التكميلية من التحقق من الصحة ملحق staking في إنشاء ضمان أمان الشبكة. قد يُنظر إلى العقدة oracle ذات الهوية الواقعية الراسخة على أنها تمتلك حصة في نظام مستمد من سمعتها. (انظر القسم 4.3 والقسم 9.6.3.) الشرط النهائي لـ Chainlink PKI هو التمهيد الآمن، أي بشكل آمن نشر اسم الجذر لشبكة Chainlink، حاليًا data.eth (قياسيًا لتوصيل نطاقات المستوى الأعلى في المتصفحات). بمعنى آخر، كيف يفعل مستخدمو Chainlink تحديد أن data.eth هو بالفعل نطاق المستوى الأعلى المرتبط بـ Chainlink المشروع؟ الحل لهذه المشكلة لشبكة Chainlink متعدد الجوانب و قد تشمل: • إضافة سجل TXT [224] إلى سجل النطاق الخاص بنا لـ chain.link الذي يحدد data.eth باعتباره المجال الجذر للنظام البيئي Chainlink. (Chainlink وبالتالي يعزز ضمنيًا البنية التحتية للمفاتيح العامة (PKI) لنطاقات الإنترنت للتحقق من صحة مجال ENS الجذري الخاص به.) • الارتباط بـ data.eth من موقع Chainlink الحالي، على سبيل المثال، من https://docs.chain.link. (استخدام ضمني آخر لـ PKI لنطاقات الإنترنت.) • جعل استخدام data.eth معروفًا من خلال وثائق مختلفة، بما في ذلك هذه الوثيقة التقنية. • نشر data.eth علنًا على قنوات التواصل الاجتماعي الخاصة بنا، مثل Twitter و المدونة Chainlink [18]. • وضع كمية كبيرة من LINK تحت سيطرة نفس عنوان المسجل مثل data.eth.
DON 部署注意事项
虽然不是我们核心设计的一部分，但有几个重要的技术考虑因素 实现 DON 值得在这里处理。
8.1 推出方法 本文提出了先进 Chainlink 功能的雄心勃勃的愿景，其 实现这一目标需要解决沿途的许多挑战。本白皮书 指出了一些挑战，但肯定会出现意想不到的挑战。 我们计划以渐进的方式实施这一愿景的要素 延长的一段时间。 我们的期望是 DONs 最初将与 支持由内部团队协作构建的特定预构建组件 Chainlink 社区。目的是更广泛地使用 DONs，例如能够 启动任意可执行文件，稍后会看到支持。 如此谨慎的原因之一是 smart contract 的组成可能会产生复杂的、意想不到的和危险的副作用，因为最近基于闪电贷的攻击已经 例如[127, 189]所示。同样，smart contract、适配器和 可执行文件需要格外小心。 在 DONs 的初始部署中，我们计划仅包含一组预构建的模板化可执行文件和适配器。这将使成分安全性的研究成为可能 使用形式化方法 [46, 170] 和其他方法来构建这些功能。它将 还简化了定价：功能定价可以由 DON 节点在功能基础上建立，而不是通过通用计量（采用的一种方法） 例如，[156]。我们还期望 Chainlink 社区参与创建 额外的模板，将各种适配器和可执行文件组合成越来越多的 有用的去中心化服务可以由数百甚至数千个人运行 DONs。 此外，这种方法可以帮助防止状态膨胀，即需要 DON 节点在工作内存中保留无法工作的状态量。这个问题是 已经在无许可的 blockchain 中出现，激励诸如“无状态 客户”（例如，参见 [206]）。在吞吐量较高的系统中，它可能会更加严重，从而激励 DON 仅部署状态大小优化的可执行文件的方法。 随着 DON 的发展和成熟，并包括第 7 节中讨论的强大护栏、第 9 节中讨论的加密经济和基于声誉的安全机制，以及为 DON 用户提供高度保证的其他功能，我们 还期望开发一个框架和工具，以促进更广泛的启动和使用 社区的 DONs。理想情况下，这些工具将支持节点运营商的集合 作为一个 oracle 网络聚集在一起，并在未经许可的情况下启动他们自己的 DON 或自助服务方式，这意味着他们可以单方面这样做。 8.2 动态 DON 会员资格 运行给定 DON 的节点集可能会随时间而变化。有两种方法 给定 O 中的动态成员资格的 skL 的密钥管理。 第一个是在成员资格发生变化时更新节点持有的 skL 份额， 同时保持 pkL 不变。 [41,161,198]中探讨的这种方法具有以下优点 不要求依赖方更新 pkL。[122] 中介绍的共享重新共享的经典技术提供了一种简单的方法 以及实现此类共享更新的有效方法。它可以传输秘密 在一组节点 O(1) 和第二组节点之间，可能与一个 O(2) 相交。在这个 方法，每个节点 O(1) 我 执行 (k(2), n(2)) 秘密共享其秘密共享 n(2) = |O(2)| 的 O(2) 中的节点和期望的（可能是新的）阈值 k(2)。各种可验证秘密共享 (VSS) 方案 [108] 可以针对以下对手提供安全保护： 主动破坏节点，即在协议中引入恶意行为。 [161] 中的技术旨在做到这一点，同时降低通信复杂性并提供 针对密码硬度假设失败的弹性。 第二种方法是更新账本密钥 pkL。这样做的好处是可以向前推进 安全性：pkL 的旧份额（即前委员会节点）不会受到损害 导致当前密钥的泄露。然而，pkL 的更新有两个缺点： (1) 在 pkL 下加密的数据需要在密钥刷新期间重新加密，并且 (2) 密钥更新需要传播给依赖方。 我们打算探索这两种方法以及两者的混合。 8.3 DON 责任 与现有的 Chainlink oracle 网络一样，DON 将包括问责机制，即记录、监控和强制执行正确的节点行为。 DONs 将有 比许多现有的无需许可的 blockchain 拥有更多的数据容量， 特别是考虑到它们连接到外部分散存储的能力。因此，他们将能够详细记录节点的性能历史记录，从而允许 更细粒度的问责机制。例如，链外计算 资产价格可能涉及在发送中值结果之前被丢弃的输入 链。在 DON 中，可以记录这些中间结果。因此，DON 中各个节点的不当行为或性能失误可以在 DON 以细粒度的方式。我们还讨论了构建方法 第 7.3 节中的防护栏解决了系统故障的特定于合约的影响。 然而，为 DON 本身提供故障安全机制也很重要， 即针对系统性、潜在灾难性 DON 故障的保护，特别是 正如我们现在所解释的，分叉/模棱两可和服务级别协议 (SLA) 失败。 分叉/模棱两可： 给定足够多的故障节点，DON 可以分叉 或模棱两可，在 L 中产生两个不同的、不一致的块或块序列。 然而，因为 DON 对 L 的内容进行数字签名，所以可以利用 主链 MAINCHAIN 来防止和/或惩罚模棱两可。 DON 可以定期检查主链上审计合约中 L 的状态。 如果其未来状态偏离检查点状态，用户/审计员可以提供证据 审计合同中的这种不当行为。此类证据可用于生成警报 或者通过合约中的削减来惩罚 DON 节点。后一种方法引入了 类似于特定 oracle feed 的激励设计问题，并且可以建立在 我们的工作在第 9 节中概述。执行服务级别协议： 虽然 DONs 并不一定意味着 无限期运行，遵守服务级别协议 (SLA) 非常重要 与他们的用户。在主链上可以执行基本的 SLA。例如， DON 节点可能承诺维护 DON 直到某个日期，或提前提供服务终止通知（例如，提前三个月通知）。合同于 MAINCHAIN 可以提供基本的加密经济 SLA 执行。 例如，如果检查点是，SLA 合约可以削减 DON 存入的资金 未按要求的时间间隔提供。用户可以存入资金并质疑 DON 证明检查点正确地表示一系列有效块（以某种方式 类似于，例如[141])。当然，出块并不等于交易 处理，但 SLA 合同也可以用于执行后者。例如，在 FSS 的传统兼容版本，其中交易从内存池中获取（参见第 5.2 节），交易最终被挖掘并放置在链上。一个用户 可以通过向 SLA 合约提供以下交易来证明 DON 渎职行为： 已开采，但未由 DON 传输以供目标合约处理 在适当的时间间隔内。15 还可以证明更细粒度的 SLA 的存在并对其进行惩罚 失败，包括使用可执行文件的计算错误（例如，通过机制 用于证明第 6.3 节中概述的正确的链下状态交易）或运行失败 基于 DON 上可见的启动器的可执行文件，无法将 DON 上的数据中继到 及时进行MAINCHAIN等等。
DON اعتبارات النشر
على الرغم من أنها ليست جزءًا من تصميمنا الأساسي، إلا أن هناك العديد من الاعتبارات الفنية المهمة في تحقيق DONs التي تستحق العلاج هنا.
8.1 نهج الطرح تضع هذه الورقة رؤية طموحة لوظيفة Chainlink المتقدمة التي وسيتطلب تحقيق ذلك حلولاً للعديد من التحديات على طول الطريق. هذه الورقة البيضاء يحدد بعض التحديات، ولكن من المؤكد أن تظهر تحديات غير متوقعة. ونحن نخطط لتنفيذ عناصر هذه الرؤية بطريقة تدريجية على مدار فترة زمنية فترة زمنية ممتدة. توقعاتنا هي أن DONs سيتم إطلاقه في البداية مع دعم لمكونات محددة معدة مسبقًا تم إنشاؤها بشكل تعاوني بواسطة فرق داخل Chainlink المجتمع. والقصد من ذلك هو أن الاستخدامات الأوسع لـ DONs، على سبيل المثال، القدرة على إطلاق الملفات التنفيذية التعسفية، وسوف نرى الدعم في وقت لاحق. أحد أسباب هذا الحذر هو أن تكوين smart contracts يمكن أن يكون له آثار جانبية معقدة وغير مقصودة وخطيرة، كما حدث مؤخرًا مع الهجمات المعتمدة على القروض السريعة على سبيل المثال هو مبين [127، 189]. وبالمثل، فإن تكوين smart contracts، والمحولات، و سوف تتطلب الملفات التنفيذية عناية فائقة. في النشر الأولي لـ DONs، نخطط لتضمين فقط مجموعة معدة مسبقًا من الملفات التنفيذية والمحولات النموذجية. وهذا سيمكن من دراسة الأمن التركيبي من هذه الوظائف باستخدام الأساليب الرسمية [46، 170] وغيرها من الأساليب. سوف تبسيط التسعير أيضًا: يمكن تحديد تسعير الوظائف من خلال DON العقد على أساس الأداء الوظيفي، وليس من خلال القياس العام، وهو النهج المعتمد في، على سبيل المثال، [156]. نتوقع أيضًا أن يشارك مجتمع Chainlink في الإنشاء من القوالب الإضافية، والجمع بين مختلف المحولات والملفات التنفيذية في شكل متزايد خدمات لامركزية مفيدة يمكن تشغيلها بواسطة مئات، إن لم يكن الآلاف من الأفراد DONs. بالإضافة إلى ذلك، يمكن أن يساعد هذا الأسلوب في منع انتفاخ الحالة، أي الحاجة إلى DON العقد للاحتفاظ بكمية غير قابلة للتطبيق من الحالة في الذاكرة العاملة. هذه المشكلة تنشأ بالفعل في blockchains غير المسموح بها، مما يحفز الأساليب مثل "عديمي الجنسية". العملاء" (راجع، على سبيل المثال، [206]). يمكن أن يكون أكثر حدة في أنظمة الإنتاجية العالية، مما يحفز أسلوب يقوم من خلاله DON بنشر الملفات التنفيذية المحسنة لحجم الحالة فقط. نظرًا لأن DON تتطور وتنضج وتتضمن حواجز حماية قوية، كما تمت مناقشته في القسم 7، وآليات الأمان المستندة إلى الاقتصاد المشفر والسمعة كما تمت مناقشتها في القسم 9، والميزات الأخرى التي توفر درجة عالية من الضمان لمستخدمي DON، فإننا ونتوقع أيضًا تطوير إطار عمل وأدوات لتسهيل إطلاقه واستخدامه على نطاق أوسع DONs من قبل المجتمع. ومن الناحية المثالية، ستمكن هذه الأدوات مجموعة من مشغلي العقد للاجتماع معًا كشبكة oracle وإطلاق DONs الخاصة بهم بطريقة غير مسموح بها أو بطريقة الخدمة الذاتية، مما يعني أنه يمكنهم القيام بذلك من جانب واحد. 8.2 العضوية الديناميكية DON قد تتغير مجموعة العقد التي تعمل على DON مع مرور الوقت. هناك نهجان للإدارة الرئيسية لـ skL نظرًا للعضوية الديناميكية في O. الأول هو تحديث حصص skL التي تحتفظ بها العقد عند حدوث تغييرات في العضوية، مع الحفاظ على pkL دون تغيير. وهذا النهج، الذي تم استكشافه في [41، 161، 198]، له ميزة عدم مطالبة الأطراف المعتمدة بتحديث pkL.توفر التقنية الكلاسيكية لإعادة مشاركة المشاركة، والتي تم تقديمها في [122]، طريقة بسيطة وطريقة فعالة لتحقيق تحديثات المشاركة هذه. أنها تمكن من نقل سر بين مجموعة واحدة من العقد O(1) والثانية، وربما تتقاطع مع O(2). في هذا النهج، كل عقدة O(1) أنا ينفذ (k(2), n(2)) مشاركة سرية لحصته السرية عبر العقد في O(2) لـ n(2) = |O(2)| والعتبة المطلوبة (ربما الجديدة) k (2). يمكن لأنظمة المشاركة السرية المختلفة (VSS) التي يمكن التحقق منها [108] أن توفر الأمان ضد الخصم الذي يفسد العقد بشكل فعال، أي يقدم سلوكًا ضارًا في البروتوكول. تهدف التقنيات الموجودة في [161] إلى القيام بذلك مع تقليل تعقيد الاتصال وتوفيره المرونة ضد الفشل في افتراضات صلابة التشفير. الطريقة الثانية هي تحديث مفتاح دفتر الأستاذ pkL. وهذا له فائدة للأمام الأمان: لن يتم التنازل عن الأسهم القديمة لـ pkL (أي عقد اللجنة السابقة). يؤدي إلى اختراق المفتاح الحالي. ومع ذلك، فإن تحديثات pkL تحمل عيبين: (1) تحتاج البيانات المشفرة بموجب pkL إلى إعادة تشفيرها أثناء تحديث المفتاح و(2) يجب نشر التحديثات الرئيسية إلى الأطراف المعتمدة. ونحن نعتزم استكشاف كلا النهجين، فضلا عن التهجين بين الاثنين. 8.3 DON المساءلة كما هو الحال مع شبكات Chainlink oracle الحالية، ستتضمن DONs آليات للمساءلة، أي تسجيل سلوك العقدة الصحيح ومراقبته وإنفاذه. DONs سيكون لها سعة بيانات أكبر بكثير من العديد من blockchains الموجودة غير المسموح بها، خاصة بالنظر إلى قدرتها على الاتصال بالتخزين اللامركزي الخارجي. وبالتالي، سيكونون قادرين على تسجيل تاريخ أداء العقد بالتفصيل، مما يسمح بذلك المزيد من آليات المساءلة الدقيقة. على سبيل المثال، حساب خارج السلسلة قد تتضمن أسعار الأصول مدخلات يتم التخلص منها قبل إرسال النتيجة المتوسطة سلسلة. في DON، يمكن تسجيل هذه النتائج المتوسطة. وبالتالي يمكن معالجة سوء السلوك أو هفوات الأداء من قبل العقد الفردية في DON أو معاقبتها على DON بطريقة دقيقة الحبيبات. لقد ناقشنا أيضًا طرق البناء قضبان الحماية في القسم 7.3 والتي تتناول التأثير المحدد للعقد الناتج عن الأعطال النظامية. ومع ذلك، فمن المهم أيضًا وجود آليات آمنة للفشل في DONs نفسها، على سبيل المثال، الحماية ضد حالات الفشل النظامية، والتي قد تكون كارثية DON، على وجه التحديد فشل التفرع/المراوغة واتفاقية مستوى الخدمة (SLA)، كما نوضح الآن. التشعب/ المراوغة: نظرًا لوجود عدد كافٍ من العقد المعيبة، يمكن أن يتفرع DON أو المراوغة، مما يؤدي إلى إنتاج كتلتين أو تسلسلتين متميزتين وغير متناسقتين من الكتل في L. نظرًا لأن DON يوقع رقميًا على محتويات L، فمن الممكن الاستفادة من السلسلة الرئيسية MAINCHAIN لمنع و/أو معاقبة المراوغة. يمكن لـ DON التحقق من الحالة بشكل دوري من L في عقد التدقيق على MAINCHAIN. إذا انحرفت حالتها المستقبلية عن حالة نقطة التفتيش، فيمكن للمستخدم/المدقق تقديم دليل عن هذا السلوك السيئ في عقد التدقيق. يمكن استخدام هذا الدليل لإنشاء تنبيه أو معاقبة DON العقد عن طريق القطع في العقد. يقدم هذا النهج الأخير مشكلة تصميم الحوافز مشابهة لتلك الخاصة بخلاصات oracle المحددة، ويمكن البناء عليها عملنا المبين في القسم 9.إنفاذ اتفاقيات مستوى الخدمة: في حين أن DONs ليس المقصود منه بالضرورة تشغيلها إلى أجل غير مسمى، فمن المهم أن تلتزم باتفاقيات مستوى الخدمة (SLAs) مع مستخدميها. تطبيق SLA الأساسي ممكن على السلسلة الرئيسية. على سبيل المثال، قد تلتزم العقد DON بالحفاظ على DON حتى تاريخ معين، أو بتقديم إشعار مسبق بإنهاء الخدمة (على سبيل المثال، إشعار لمدة ثلاثة أشهر). عقد على يمكن أن توفر MAINCHAIN تطبيقًا أساسيًا لاتفاقية مستوى الخدمة (SLA) للاقتصاد المشفر. على سبيل المثال، يمكن لعقد SLA أن يخفض DON الأموال المودعة إذا كانت نقاط التفتيش لم يتم توفيرها على فترات زمنية مطلوبة. يمكن للمستخدم إيداع الأموال والطعن في DON لإثبات أن نقطة التفتيش تمثل بشكل صحيح سلسلة من الكتل الصالحة (بطريقة مماثل ل، على سبيل المثال [141]). وبطبيعة الحال، إنتاج الكتلة لا يعني المعاملة المعالجة، ولكن عقد SLA يمكن أن يعمل أيضًا على إنفاذ الأخير. على سبيل المثال، في الإصدار المتوافق مع التراث من الخدمة الثابتة الساتلية (FSS) والذي يتم فيه جلب المعاملات من مجمع الذاكرة (انظر القسم 5.2)، ويتم في النهاية استخراج المعاملات ووضعها في السلسلة. مستخدم يمكن إثبات DON المخالفات من خلال تزويد عقد SLA بمعاملة تم تعدينه ولكن لم يتم إرساله بواسطة DON للمعالجة بواسطة العقد المستهدف خلال الفترة الزمنية المناسبة.15 ومن الممكن أيضًا إثبات وجود المزيد من جيش تحرير السودان (SLA) الدقيق والمعاقبة عليه حالات الفشل، بما في ذلك الأخطاء في الحساب باستخدام الملفات التنفيذية (عبر، على سبيل المثال، الآليات لإثبات معاملات الحالة الصحيحة خارج السلسلة الموضحة في القسم 6.3) أو الفشل في التشغيل الملفات التنفيذية المستندة إلى البادئات المرئية على DON، الفشل في ترحيل البيانات على DON إلى MAINCHAIN في الوقت المناسب، وما إلى ذلك.
经济学和加密经济学
为了让 Chainlink 网络在去中心化信任模型中实现强大的安全性， 节点共同表现出正确的行为至关重要，这意味着它们遵守 大多数时候完全符合 DON 协议。在本节中，我们讨论方法 通过经济激励（又名加密经济）来帮助实施这种行为 激励措施。 这些激励分为两类：显性激励和隐性激励 分别通过 staking 和未来费用机会 (FFO)。 质押： 与其他 blockchain 系统一样，在 Chainlink 中进行质押涉及网络参与者，即 oracle 节点，以 LINK token 的形式存入锁定资金。这些 资金，我们也称为股权或显性股权，是一种显性激励。他们 因节点故障或不当行为而被没收。在 blockchain 上下文中， 这个过程通常被称为削减。 然而，Chainlink 中 oracle 节点的质押与 staking 有根本不同 由 validators 在未经许可的 blockchains 中编写。验证者可能会通过模棱两可或对抗性地排序交易来做出不当行为。 底层共识协议 15由于用户可以替换内存池中的交易，因此需要注意确保挖掘的交易和 DON 提交的交易之间的正确对应。不过，无需许可的 blockchain 使用严格快速的块验证规则和加密原语来防止 validator 生成无效块。相比之下， 程序保护无法阻止作弊 oracle 网络生成 无效报告。原因是两种类型的系统之间的一个关键区别：blockchains 中的事务验证是内部一致性的属性，而正确性 关于 blockchain 的 oracle 报告是外部数据（即链下数据）的属性。 我们为基于 Chainlink 的网络设计了初步的 staking 机制 基于可能使用外部数据的 oracle 节点之间的交互协议。这个 机制使用明确的奖励和措施为正确的行为创造经济激励 处罚（削减）。由于该机制是经济的，因此旨在防止节点 对手使用金融资源通过以下方式腐败节点： 贿赂。 （这样的对手是非常普遍的，并且可以扩展到例如与 从他们的集体不当行为中获取价值。） 我们设计的Chainlink staking机制具有一些强大且新颖的功能 16 主要的此类特征是超线性 staking 影响（具体来说，二次影响）。 对手所拥有的资源必须远远超过节点存入的资金 从而达到颠覆机制的目的。我们的 staking 机制还提供了针对比之前在类似系统中考虑的更强大对手的保护，即 一个可以根据节点未来行为进行贿赂的对手。此外，我们还讨论了 Chainlink 工具（例如 DECO）如何帮助加强我们的 staking 通过在节点行为出现故障的情况下促进正确裁决的机制。 未来费用机会（FFO）： 两个 PoW 的未经许可的 blockchains 和 PoS 多样性——如今严重依赖我们所说的隐性激励。这些是 对诚实行为的经济激励不是来自明确的奖励，而是来自 从平台参与本身来看。例如，Bitcoin 矿工社区受到激励，不会发起 51% 攻击，因为这可能会破坏人们对比特币的信心。 Bitcoin，压低其价值，从而侵蚀其集体的价值 采矿基础设施资本投资[150]。 Chainlink 网络受益于我们提到的类似隐性激励 作为未来费用机会（FFO）。具有良好性能历史记录的 Oracle 节点或 声誉会吸引用户付费。 oracle 节点的不当行为会危及未来 费用支付，从而以潜在的机会成本来惩罚节点 通过参与网络获得的收入。与显性权益类比， FFO 可以被视为一种隐性股权形式，是对诚实行为的激励， 源于对平台保持信心的共同利益 节点运营商的业务取决于节点运营商的积极绩效和声誉 网络。这种激励是 Chainlink 网络所固有的，但没有明确表达 协议。在 Bitcoin 中，维持上述采矿作业的价值 16我们在此描述的 staking 机制目前仅旨在强制提供正确的报告 由 oracle 网络提供。我们希望在未来的工作中对其进行扩展，以确保许多任务的正确执行 DONs 将提供的其他功能。同样可以被视为隐性股权的一种形式。 我们强调 FFO 已存在于 Chainlink 中并有助于保护网络 今天。我们对 Chainlink 进一步发展的主要贡献将是一种有原则的、经验驱动的方法，通过以下方式评估 FFO 等隐性激励： 我们称之为隐性激励框架（IIF）。估计数量，例如 节点未来的收费机会，IIF将持续借鉴综合 Chainlink 网络收集的绩效和付款数据。这样的估计 将启用反映节点激励的 staking 系统基于 IIF 的参数化 比当前的启发式和/或静态模型具有更高的准确性。 总结一下，正确的 oracle 节点的两个主要经济激励措施 正在发展的 Chainlink 网络中的行为将是： • 质押（存入的质押） 哦 明确的激励 • 未来收费机会 (FFO) 哦 隐性激励 这两种形式的激励是相辅相成的。 Oracle节点可以同时 参与 Chainlink staking 协议，享受持续的收入来源 用户，并从他们持续的良好行为中集体受益。因此这两种激励措施 为 oracle 网络提供的加密经济安全做出贡献。另外， 这两种激励措施可以相互加强和/或相互抵消。例如， 没有业绩历史记录和收入来源的新 oracle 运营商可以抵押 大量的LINK作为诚实行为的保证，从而吸引用户 和费用。相反，一个已建立的 oracle 运算符具有长且相对无故障的 性能历史记录可能会向大量用户收取大量费用，因此依赖 更重视 FFO 作为隐性激励的一种形式。 一般来说，我们在这里考虑的方法旨在实现给定量的 oracle-网络 资源以在 Chainlink 中创造最大可能的经济激励 代理——即最大化其财务效用的节点——诚实行事。再放一个 方式，目标是最大化对手攻击所需的金融资源 网络成功。通过数学上良好地制定 staking 协议 定义经济安全并使用 IIF，我们的目标是衡量经济实力 Chainlink 的激励措施尽可能准确。依赖合约的创建者将 然后能够充满信心地确定 oracle 网络是否满足 他们所需的加密经济安全级别。 经济安全的良性循环： 我们在本节中讨论的激励措施 staking 和 FFO 的影响超出了其增强安全性的范围 DONs。它们承诺会引发我们所说的经济安全的良性循环。 超线性 staking 影响（和其他规模经济）导致运营成本降低 随着 DON 安全性的增长而增加成本。较低的成本吸引更多用户使用 DON，增加费用支付。费用支付的增加继续刺激行业的增长 网络，形成良性循环。 我们认为，经济安全的良性循环只是一个例子 规模经济和网络效应等，我们将在本节后面讨论。 部门组织：质押给以下组织带来了显着的技术和概念挑战 我们设计了一种具有新颖功能的机制。因此，质押将是 我们本节的主要重点。 我们在第 9.1 节中概述了本文中介绍的 staking 方法，然后在第 9.2 节到第 9.5 节中进行了详细讨论。我们介绍 IFF 在第 9.6 节中。我们在第 9.7 节中总结了 Chainlink 网络激励措施。 在第 9.8 节中，我们讨论了我们提出的 staking 方法可以给 oracle 网络带来的经济安全的良性循环。最后，我们简单描述一下其他的潜力 影响第 9.9 节中 Chainlink 网络的增长。 9.1 质押概览 如上所述，我们在这里介绍的 staking 机制设计涉及 oracle 节点之间的交互协议，允许解决 外部数据报告。质押旨在确保理性 oracle 节点的诚实行为。因此，我们可以将攻击 staking 协议的对手建模为 行贿者：对手的策略是利用经济激励来腐蚀 oracle 节点。 对手可能会通过成功篡改来获取未来的金融资源 带有 oracle 报告，例如，提出与损坏的节点分享由此产生的利润。 我们的 staking 机制设计同时致力于实现两个雄心勃勃的目标： 1. 抵御强大的对手：staking机制旨在保护 oracle 网络针对广泛的对手，这些对手能够进行复杂的、 有条件的贿赂策略，包括提供贿赂的预期贿赂 至 oracle ，其身份是在事后确定的（例如，向 随机选择 oracles 进行高优先级警报）。而其他 oracle 设计 考虑了一组狭窄的攻击，但没有实际的全部功能 对手，据我们所知，我们引入的对抗机制 这是第一个明确阐述一系列广泛的贿赂策略并表明 该模型中的电阻。我们的模型假设除了攻击者之外的节点 经济上理性的（相对于诚实的），我们假设存在一个 对于典型使用来说价格昂贵但可用的事实来源 如有分歧（下文进一步讨论）。 2. 实现超线性staking影响： 我们的目标是确保由理性代理组成的 oracle 网络报告 即使存在预算超线性的攻击者，也能如实进行整个网络存入的总权益。在现有的 staking 系统中，如果 每个 n 个节点都持有 $d，攻击者可以发出可信的贿赂请求 节点以不诚实的行为换取略高于 \(d to each node, using a total budget of about \)dn。这已经是一个很高的标准了 攻击者必须拥有相当于存款总和的流动预算 网络中的所有利益相关者。我们的目标是更强的经济安全 这已经是一个很大的障碍了。我们的目标是设计第一个 staking 系统 可以通过 n 的预算超线性实现一般攻击者的安全性。 虽然实际考虑可能会产生较小的影响，但正如我们下面讨论的， 我们的初步设计达到了对抗性预算要求大于 $dn2/2，即以 n 为单位进行二次缩放，即使行贿行为在很大程度上也是不切实际的 当节点仅抵押适量时。 实现这两个目标需要激励设计的创新组合 和密码学。 主要想法： 我们的 staking 方法取决于我们称之为“看门狗优先”的想法。 由 Chainlink oracle 网络生成并发送到依赖合约的报告 （例如，资产价格）是从参与节点贡献的各个报告中汇总的（例如，通过取中位数）。通常是服务级别协议 (SLA) 指定报告偏差的可接受范围，即节点的报告可以走多远 与汇总报告的偏差以及应允许汇总报告的偏差程度 偏离真实值才被认为是正确的。 在我们的 staking 系统中，对于给定的报告轮次，每个 oracle 节点可以充当 如果监管机构认为汇总报告不正确，则会发出警报。在每个 在报告轮中，每个 oracle 节点都被分配一个公共优先级，该优先级决定了 其警报（如果有）的处理顺序。我们的机制旨在奖励 集中度，这意味着发出警报的最高优先级的看门狗将获得 没收故障节点的存款所产生的全部奖励。 我们的 staking 系统设计涉及两层：第一层，默认层，第二层， 后挡板层。第一层是 oracle 网络本身，一组 n 个节点。 （为简单起见， 我们假设 n 是奇数。）如果大多数节点报告不正确的值，则 第一层有强烈的动机发出警报。如果发出警报，则报告 然后网络的决策被升级到第二层——一个高成本、最大可靠性的系统，可以由用户在网络服务级别协议中指定。 例如，这可能是一个仅由具有强大功能的节点组成的系统 历史可靠性分数，或者其数量级大于 oracles 第一层。此外，如第 9.4.3 节中所述，DECO 或 Town Crier 可以服务 作为强大的工具，帮助确保第二层的高效和结论性裁决。 为了简单起见，我们假设第二层系统得出了正确的报告 值。 虽然仅依靠第二层来生成所有报告似乎很有吸引力， 我们设计的好处是它始终如一地实现了在典型情况下，只需支付第二层系统的运营成本 第一层系统。 看门狗优先级会通过以下方式产生超线性 staking 影响：如果 第一层 oracle 网络输出错误结果和多个看门狗节点 警报，staking 激励机制奖励最高优先级的看门狗 从（大多数）行为不当节点的存款中提取的金额超过 $dn/2。的 因此，总奖励集中在这个单一看门狗手中，因此 确定对手必须承诺潜在看门狗的最低限度 激励它不发出警报。由于我们的机制确保每个 oracle 都获得 如果更高优先级的监管机构接受了贿赂，则有机会担任监管机构 （并且选择不发出警报），因此对手必须提供超过 $dn/2 到每个节点以防止引发任何警报。由于有n个节点， 对手成功行贿所需的预算超过 dn2/2 美元，其中 是网络中节点数量 n 的二次方。 9.2 背景 我们对 staking 的方法借鉴了博弈论和机制领域的研究 设计 (MD)（有关教科书参考，请参阅 [177]）。博弈论是数学上的 战略互动的正式研究。在这种情况下，游戏就是这样的模型 一种交互，通常是在现实世界中，将可用的操作集编纂成 游戏的参与者，称为玩家。博弈还指定了所获得的收益 由个别玩家决定——奖励取决于玩家选择的行动和 其他玩家的行动。也许是游戏中研究的最著名的游戏例子 理论是囚徒困境[178]。博弈论学家通常旨在理解 给定博弈中所代表的均衡或均衡（如果有）。平衡是 一组策略（每个玩家一个），这样没有一个玩家可以获得更高的分数 单方面偏离其战略所带来的回报。 与此同时，机制设计是设计激励措施的科学，使得 交互（及其相关博弈）的平衡具有一些理想的特性。 MD 可以被视为博弈论的逆：博弈中的典型问题 理论是，“给定激励和模型，均衡将会是什么？”在马里兰州， 相反，问题是“什么激励措施会导致博弈达到理想的均衡？” 机制设计者的一个典型目标是创建一个“激励兼容”机制，这意味着该机制的参与者（例如，拍卖或其他信息） 启发系统[228]）被激励去报告某些事情的真相（例如，如何 他们非常看重某个特定的物品）。维克里（第二价）拍卖也许是 最著名的激励兼容机制，其中参与者提交密封投标 对于某件商品，出价最高者赢得该商品，但支付第二高的价格 [214]。加密经济学是 MD 的一种特定领域形式，它利用密码学 在去中心化系统中创造理想平衡的技术。 贿赂和共谋给整个医学博士领域带来了重大挑战。几乎所有的机制都会在共谋的存在下崩溃，共谋被定义为附带合同。参与机制的各方之间 [125, 130]。贿赂是指外部一方在游戏中引入新颖的激励措施，这提出了一个更棘手的问题 比串通更重要；串通可以被视为游戏行贿的特例 参与者。 区块链系统通常可以被概念化为具有货币（基于加密货币）回报的游戏。一个简单的例子是工作量证明挖矿：矿工有一个行动空间 他们可以选择 hash 速率来开采区块。挖矿的回报是有保证的负奖励（电力和设备成本）加上随机 正奖励（挖矿补贴）取决于其他活跃矿工的数量 [106, 172] 和交易费用。像 SchellingCoin [68] 这样的众包 oracle 是另一个例子：操作空间是 oracle 可能发送的一组可能的报告，而 收益是 oracle 机制指定的奖励，例如，付款可能取决于 oracle 的报告与其他报告的中位数有多接近 [26, 68, 119, 185]。 区块链游戏为串通和贿赂攻击提供了成熟的机会；确实， smart contracts 甚至可以促进此类攻击 [96, 165]。也许最有名的 对众包 oracle 的贿赂攻击是 p-plus-epsilon 攻击 [67]。这次攻击 出现在类似 SchellingCoin 的机制中，在该机制中，玩家提交布尔值报告（即假或真），如果他们同意，则获得 p 奖励 多数提交。 在 p-plus-epsilon 攻击中，攻击者可信地承诺： 例如，当且仅当多数提交为真时，才向投票错误的用户支付 $p + ϵ 费用。 结果是一种均衡，其中所有参与者都被激励报告虚假信息 无论其他玩家做什么；因此，行贿者可以诱导节点 通过其承诺的贿赂举报虚假信息，而无需实际支付贿赂（！）。 然而，在 oracle 背景下（特别是非众包的 oracle ）对其他贿赂策略的探索仅限于相当弱的对抗性 模型。例如，在 PoW 环境中，研究人员研究了结果偶然性 贿赂，即只有在目标消息被成功审查并且没有被审查的情况下才行贿。 出现在一个区块中，无论单个矿工的行为如何[96, 165]。在这种情况下 然而，除了 p-plus-epsilon 攻击之外，我们只知道 oracles 中的工作 一种严格限制的贿赂模式，其中行贿者以以下条件进行贿赂： 个人玩家的行动，而不是最终的结果。 在这里，我们概述了保持激励的信息获取机制的设计 即使在强对抗模型中也是兼容的，如下一小节所述。 9.3 建模假设 在本小节中，我们将解释如何对玩家的行为和能力进行建模 我们的系统，特别是第一层 oracle 节点，第二层节点（裁决） 层和对手。9.3.1 第一层激励模型：理性参与者 许多 blockchain 系统的安全性依赖于一定数量诚实的假设 参与节点。如果节点遵循协议，则被定义为诚实的 当这样做不符合他们的经济利益时。通常是工作量证明系统 需要大多数 hash 权力才能诚实，权益证明系统通常需要所有参与权益的 2/3 或更多才能诚实，甚至像这样的第 2 层系统 仲裁 [141] 需要至少一个诚实的参与者。 在我们的 staking 机制建模中，我们做出了一个更弱的假设。 （成为 清晰、较弱的假设意味着更强的安全属性，因此更可取。）我们假设对手已经腐败，即控制了一些（少数） 第一层 oracle 节点的一部分。我们将其余节点建模为不诚实的代理， 而是作为理性预期效用最大化者。这些节点完全根据自利的财务激励措施行事，选择导致预期财务的行动 增益。例如，如果一个节点收到的贿赂金额大于其所获得的奖励 行为诚实，就会收受贿赂。 关于对抗节点的注意事项： 根据常见的信任建模 去中心化系统中，我们假设所有节点都是理性的，即寻求最大化 净收入，而不是被恶意对手控制。然而我们的主张—— 特别是超线性或二次 staking 影响——渐近地保持 对于某些正的情况，对抗性控制的节点集至多为 (1/2 −c)n 常数 c. 9.3.2 第二层裁决模型：假设的正确性 回想一下，我们的 staking 机制的一个关键功能有助于实现安全性 对抗理性节点的是它的第二层系统。 在我们提出的 staking 机制中，任何 oracle 都可能发出警报，表明 它认为该机制的输出是不正确的。警报会带来高度信任 第二层系统激活并报告正确的结果。因此，关键建模 我们的方法的要求是正确的裁决，即正确的报告 第二层系统。 我们的 staking 模型假设第二层系统充当廉洁、最可靠的事实来源。这样的系统可能既昂贵又缓慢，因此 不适合用于典型情况。然而，在平衡情况下，即当 第一层系统正常工作，第二层系统不会被调用。 相反，它的存在通过提供一个增强了整个 oracle 系统的安全性 高保证的后盾。 使用高信任度、高成本的裁决层类似于上诉流程 大多数司法系统的核心。它在 oracle 的设计中也很常见 系统，例如[119, 185]。我们简要讨论第二层的实现方法 在我们第 9.4.3 节的机制中。我们的 staking 协议使用第二层系统的假设正确裁决作为可信威胁，强制执行 oracle 节点的正确报告。协议 没收 oracle 节点的部分或全部权益，这些节点生成由 第二层系统不正确。从而阻止 Oracle 节点出现不当行为 由此产生的经济处罚。这种方法在风格上类似于 乐观的 rollups，例如 [141, 10]。 9.3.3 对抗模型 我们的 staking 机制旨在获取真实信息，同时实现针对广泛、明确类别的对手的安全。它改进了以前的作品， 它要么省略明确的对抗模型，要么专注于对手的狭窄子类，例如上面讨论的 p+epsilon 对手。我们的目标是设计一个 staking 具有正式证明的安全机制，可以抵御各种对手 实践中会遇到。 我们将对手建模为具有固定（可参数化）预算，表示为 $B。对手可以与每个 oracle 进行单独且保密的通信 网络，并可以秘密向任何个人 oracle 提供贿赂保证 取决于该机制的可公开观察的结果。结果决定 例如，贿赂可以包括 oracle 报告的价值、任何公共消息 由任何 oracle 发送到该机制（例如，警报），其他报告的值 oracles，以及机制输出的值。 没有任何机制可以抵御具有无限能力的攻击者。因此，我们认为某些行为不切实际或超出范围。我们假设我们的攻击者 不能破坏标准加密原语，并且如上所述，有一个固定的（如果 可能很大）预算$B。我们进一步假设对手无法控制 oracle 网络中的通信，特别是它不能大幅延迟 第一层和/或第二层节点之间的流量。 （对手是否可以观察到这种通信取决于特定的机制，我们将在下面解释。） 然而，非正式地，如上所述，我们假设对手可以： (1) 腐败 oracle 节点的一部分（(1/2 −c)-某个常数 c 的分数），即完全控制 (2) 向任何想要的节点提供贿赂，并保证付款 如上所述，取决于对手指定的结果。 虽然我们没有提供对手完整的正式模型或完整分类 本白皮书中列出了一系列贿赂能力，以下是各种类型的示例 我们的模型涵盖了行贿者。为了简单起见，我们假设 oracles 发出布尔值 报告其正确值 (w.l.o.g.) 为 true，并且最终结果计算为 消费 smart contract 使用的这些报告的汇总。行贿者的 目标是最终结果不正确，即错误。 • 无条件贿赂者：贿赂者向任何报告虚假信息的oracle 提供贿赂$b。 • 概率贿赂者：贿赂者以某种概率 q 向任何 oracle 提供贿赂 $b 报告错误。• 以虚假结果为条件的行贿者：行贿者向任何报告虚假信息的oracle 行贿$b，只要最终结果是虚假的。 • 无警报条件的行贿者：行贿者向任何举报的oracle 提供贿赂$b 只要没有发出警报，就为 false。 • p-plus-epsilon 贿赂者：贿赂者向任何报告错误的 oracle 提供贿赂 $b 只要大多数 oracle 不报告虚假信息即可。 • 潜在行贿者：行贿者提前向选定的 oracle 行贿 $b 对于随机角色并报告错误。在我们提出的 staking 协议中，所有 节点充当潜在的看门狗，我们能够证明随机化 监管机构的优先事项并不适合潜在的贿赂。许多工作量证明、proof-of-stake 和许可系统都容易受到预期影响 然而，贿赂表明了在我们的对手中考虑这一问题的重要性 模型并确保我们的 staking 协议能够适应它。参见附录E 了解更多详情。 9.3.4 多少加密经济安全才足够？ 理性的对手只有在能够获取利润的情况下才会花钱攻击系统 大于其支出。 因此，对于我们的对抗模型和提议的 staking 机制中，$B 可以被视为对手能够获得的潜在利润的衡量标准 通过破坏 oracle 网络并导致其从依赖 smart contract 中提取 生成不正确的报告或一组报告。在决定是否存在 oracle 网络时 为其目的提供足够程度的加密经济安全性，用户应该 从这个角度来评估网络。 对于实际环境中看似合理的对手，我们预计 $B 通常会是 远小于依赖 smart contract 的总资产。在大多数情况下，它 对手不可能全部提取这些资产。 9.4 质押机制：草图 在这里，我们介绍了staking机制的主要思想和总体结构。 目前正在考虑。 为了便于演示，我们描述了一个简单但缓慢的 本小节中的（多轮）协议。但我们注意到，这个方案相当 实用。鉴于该机制提供的经济保证，即对故障节点的惩罚和随之而来的激励，许多用户可能愿意 乐观地接受报告。换句话说，此类用户可以在之前接受报告 可能由第二层进行裁决。 不愿意乐观接受报告的用户可以选择等待协议 执行终止，即直到发生任何潜在的升级到第二层的情况。这个， 然而，这会大大减慢报告的确认时间。因此我们简单地图 15：带警报的 staking 方案示意图。在这个例子中，1⃝多数 的节点被损坏/贿赂并发出不正确的值〜r，而不是正确的值 报告值河看门狗节点2⃝向二级委员会发送警报， 3⃝确定并发出正确的报告值r，导致节点损坏 没收他们的存款——每 d 美元交给看门狗节点 4⃝。 概述一些优化，这些优化会导致更快（单轮）（如果更多的话） 第 9.5 节中的复杂设计。 回想一下，我们的 staking 机制中的第一层由基本的 oracle 组成。 网络本身。 如上所述，我们机制的主要结构是在每一轮中， 每个节点都可以充当具有一定优先级的“看门狗”，因此它有能力 如果该机制得到不正确的输出，而不是正确的输出，则发出警报 奥恩河此警报会导致第二层解决方案，我们假设达到了正确的结果 报告。报告不正确的节点会受到惩罚，因为他们的权益 削减并奖励给监管机构。这种基本结构在 oracle 系统中很常见， 例如，[119, 185]。 我们设计中的关键创新，如上面简要提到的，是每个节点都是 在潜在看门狗的排序中分配了不同的优先级。也就是看门狗 有机会按优先顺序发出警报。回想一下，如果一个节点有 发出警报的最高优先级，每次不当行为都会收到减少的押金 $d 节点，总共超过 \(dn/2 = \)d × n/2，因为不正确的报告意味着 大多数坏节点。因此，对手必须至少支付这个奖励 贿赂任意节点。因此，要贿赂大多数节点，对手必须支付 对大多数节点进行大额贿赂，即严格超过 $dn2/2。 我们在图 15 中示意性地展示了警报和看门狗升级的工作原理。9.4.1 进一步的机制细节 我们现在更详细描述的反贿赂系统是一个简化的草图 我们打算建造的两层建筑。我们的大部分重点将放在描述 第一层网络（以下简称“网络”，从上下文中可以清楚地看出） 及其激励机制和升级到第二层的程序。 考虑一个由 n 个 oracle 节点组成的 Chainlink 网络，这些节点负责 定期（例如，每分钟一次）报告布尔值（例如，市场是否 BTC 的市值超过了 ETH）。作为 staking 机制的一部分，节点 必须提供两笔押金：押金 $d 如有分歧，将被削减 多数和看门狗押金 $dw 会在出现故障时被削减 升级。我们假设节点无法复制其他节点的提交，例如， 通过第 5.3 节中讨论的提交-显示方案。每轮中，节点优先 提交他们的报告，一旦所有节点都已提交（或超时已过期）， 节点公布他们的报告。 对于要生成的每个报告，每个节点还被赋予随机选择的 1 到 n 之间的看门狗优先级，其中 1 为最高优先级。该优先级使 奖励集中在一个看门狗手中。所有报告公开后， 随后进入警报阶段。在一系列 n（同步）轮中，节点 优先级 i 有机会在第一轮中发出警报。 让我们考虑一下节点揭示后该机制可能产生的结果 他们的报告。再次假设二进制报告，假设正确的值为 true 并且 不正确的是假的。还假设第一层机制输出 节点输出的多数值作为最终报告r。 该机制可能产生三种结果： • 完全一致：在最好的情况下，节点完全一致：所有节点 可用并已提供相同值 r 的及时报告（无论是真实的 或假）。在这种情况下，网络只需将 r 转发给依赖合约 并用固定的每轮支付 $p 奖励每个节点，该支付要小得多 比 $d。 • 部分一致：有可能某些节点处于离线状态，或者对于哪个值正确存在分歧，但大多数节点报告真实，并且只有一个 少数报告虚假。这个案例也很简单。多数值 (true) 被计算，产生正确的报告 r。所有报告 r 的节点都是 奖励 $p，而报告错误的 oracle 则拥有存款 适度削减，例如削减 10 美元。 • 警报：如果看门狗认为网络输出不正确， 它公开触发警报，将该机制升级到第二层网络。 那么就有两种可能的结果： – 正确警报：如果第二层网络确认图 16：通过集中警报奖励放大行贿者的成本。行贿 对手必须用超过其通过警报获得的奖励来贿赂每个节点 （显示为红色条）。如果警报奖励是共享的，那么这个奖励可能会相对 小。集中的警报奖励增加了任何单个节点可能获得的奖励 获得（高红色条）。因此，对手为可行的贿赂支付的总金额 （灰色区域）集中的警报奖励比共享的警报奖励大得多。 第一层网络错误，报警看门狗节点获得奖励 包括所有削减的存款，因此超过 $dn/2。 – 错误警报：如果第二层和第一层 oracle 一致，则升级 被认为有故障，并且警报节点失去 $dw 押金。 在乐观接受报告的情况下，看门狗警报不会导致 依赖合同执行的任何变化。对于旨在等待的合同 第二层委员会可能进行仲裁，监管机构发出延迟警报，但 不要冻结合同执行。合同也可以指定一个 裁决期间的故障转移 DON。 9.4.2 二次质押影响 每个节点都可以充当看门狗，并结合严格的节点优先级 确保集中奖励，使该机制实现二次staking 第 9.3.3 节中描述的每种贿赂攻击者的影响。回想一下，这个 具体来说，在我们的设置中，对于具有 n 个节点的网络，每个节点都有存款 $d，成功的贿赂者（上述任何一种）的预算必须大于 $dn2/2。 准确地说，行贿者必须至少破坏 (n+1)/2 个节点，因为行贿者必须 损坏大多数 n 个节点（对于奇数 n，根据假设）。因此，看门狗代表 获得 $d(n + 1)/2 的奖励。因此，行贿者必须向每个人支付这笔金额节点以确保没有人充当看门狗。我们正在努力正式证明，如果 行贿者的预算至多为 $d(n2 + n)/2，则子博弈完美均衡 行贿者和 oracle 之间的博弈——换句话说，平衡点为 游戏进行期间的任何一点——行贿者不得行贿，并且 每个 oracle 诚实地报告其真实值。 我们在上面已经解释了成功的行贿者如何可能需要 预算明显大于节点存款总和。为了说明这一点 直观的结果，图 16 以图形方式显示了集中警报奖励的影响。 正如我们所看到的，如果监管机构警报的奖励——即受贿的存款 报告错误的节点）—分为所有潜在警报，即警报的总量 任何单独的警报节点预计都会相对较小，大约为 $d。 行贿者知道不可能支付超过 d 美元的款项，因此可以使用 一个虚假结果的有条件贿赂，贿赂 n 个节点中的每一个节点，其金额略高于 $d + ϵ。 与直觉相反，图 16 显示了一个广泛分配奖励的系统 发出警报的节点之间的强度远弱于集中奖励的节点 单一看门狗的手中。 参数示例： 考虑一个（第一层）网络，其中 n = 100 个节点，每个节点 存入 \(d = \)20K。该网络将总共存入 200 万美元，但 免受预算为 \(100M = \)dn2/2 的贿赂。增加数量 当然，oracles 比增加 $d 更有效，并且可以产生戏剧性的效果： 具有 n = 300 个节点和存款 \(d = \)20K 的网络将受到保护 预算高达 9 亿美元的行贿者。 请注意，staking 系统在许多情况下可以保护代表 smart contract 的 比提供的贿赂保护水平更有价值。这是因为对手 在许多情况下，攻击这些合约并不能获取全部价值。例如，一个 Chainlink 支持价值 10 亿美元的合约可能只需要针对 拥有 1 亿美元资源的贿赂者，因为这样的对手可以切实地获取利润 仅占合同价值的10%。 注意： 网络的价值可以呈二次方增长的想法表达为 众所周知的梅特卡夫定律 [167, 235]，该定律指出网络的价值 连接实体的数量呈二次方增长。然而，梅特卡夫定律 来自潜在成对网络连接数量的增长，这是与我们激励中潜在的二次 staking 影响不同的现象 机制。 9.4.3 第二层的实现 两个操作特性有助于实现高可靠性第二层：(1) 二级裁决在 oracle 网络中应该是罕见的事件，因此可以 比第一层正常运行的成本要高得多，并且 (2) 假设乐观地接受的报告——或可以等待仲裁执行的合同—— 第二层不需要实时执行。 这些功能导致了一系列 第二层的配置选项以满足特定 DONs 的要求。 作为示例方法，第二层委员会可以由由 DON（即第一层）来自 Chainlink 中服务时间最长且最可靠的节点 网络。运营商除了拥有丰富的相关运营经验外， 的此类节点在 FFO 中具有相当大的隐性激励，从而激发了欲望 确保 Chainlink 网络保持高度可靠。他们还公开 可用的性能历史记录可提供其可靠性的透明度。值得注意的是，第二层节点不必是第一层网络的参与者，并且 可以裁决多个第一层网络的故障。 给定 DON 中的节点可以预先指定并公开提交一组 n' 这样的 节点构成该 DON 的第二级委员会。此外，DON 节点发布一个参数k′≤n′，该参数决定第二层投票的数量 需要惩罚第一层节点。当针对给定报告生成警报时， 第二层成员对每个人提供的值的正确性进行投票 第一层节点。任何收到 k′ 反对票的第一层节点将丧失其地位 存款到看门狗节点。 由于审判和延长执行时间的机会很少 如上所述，与第一层相比，第二层中的节点可以： 1. 因审判而获得高额报酬。 2. 利用额外的数据源，甚至超出第一层使用的各种数据源。 3. 依靠人工和/或专家检查和干预，例如识别和 协调源数据中的错误并区分诚实节点中继 错误的数据和行为不当的节点。 我们强调，我们刚才描述的选择第二层节点和政策管理裁决的方法仅代表了一个大问题中的一个点。 第二层可能实现的设计空间。我们的激励机制提供 关于如何实现第二层的完全灵活性。因此，各个 DON 可以 为满足特定要求的第二层制定并制定规则 以及参与节点和用户的期望。 DECO 和 Town Crier 作为裁决工具： 对于第二层来说这是必不可少的 在我们的机制中能够区分敌对的第一层节点 故意产生不正确的报告和无意中诚实的第一层节点 中继源处不正确的数据。只有这样第二层才能实现 削减是为了抑制作弊行为，这是我们机制的目标。德科和城市公告员 是强大的工具，可以使第二层节点做出这一关键区分 可靠。第二层节点在某些情况下可能能够直接查询所使用的数据源 由第一层节点或使用ADO第7.1节来检查是否有错误的报告 由错误的数据源导致。然而，在其他情况下，第二层节点可能缺乏 直接访问第一层节点的数据源。在这种情况下，正确的判决将 似乎不可行或需要依赖主观判断。上一页 oracle 争议系统依赖于低效且不断升级的投票来解决此类问题 挑战。 然而，使用 DECO 或 Town Crier，第一层节点可以证明正确的行为 到第二层节点。 （有关这两个系统的详细信息，请参见第 3.6.2 节。）具体来说，如果 第二层节点将第一层节点识别为输出了错误的报告值~r， 第一层节点可以使用DECO或Town Crier来生成防篡改证据 第二层节点正确地从（启用 TLS 的）源正确中继 〜r 被 DON 认可为权威。至关重要的是，第一层节点可以做到这一点 无需需要直接访问数据源的第二层节点。 17 因此， 对于任何所需的数据源，正确的裁决在 Chainlink 中都是可行的。 9.4.4 误报保险 我们的staking机制实现的强大反贿赂从根本上依赖于 削减奖励给警报者的资金。如果没有金钱奖励，警报者就会 没有拒绝贿赂的直接动机。然而，其结果是，削减的资金并没有 可用于补偿因错误报告而受到伤害的用户，例如损失金钱的用户 当错误的价格数据转发到 smart contract 时。 根据假设，如果报告被接受，不正确的报告不会造成问题。 仅在可能的裁决（即第二层采取行动）之后签订合同。正如所解释的 不过，为了实现最佳性能，合约可能会依赖 对执行正确报告的机制持乐观态度，这意味着他们接受 在潜在的二级裁决之前进行报告。 确实如此乐观的行为 在我们的模型中假设理性对手的预算不超过预算是安全的 staking 该机制的影响。 用户担心由于以下原因而导致的不太可能发生的机制故障： 例如，拥有压倒性金融资源的对手可能希望以误报保险的形式采用额外的经济安全层。我们知道 多家保险公司已经打算提供此类智能合约支持的保单 在不久的将来，针对 Chainlink 安全协议，包括通过 DAOs 等创新机制，例如 [7]。 Chainlink 的性能历史记录是否存在 节点和有关节点的其他数据（例如其权益金额）为风险精算评估提供了异常坚实的基础，从而可以为政策定价 以对投保人来说成本低廉但对保险公司来说可持续的方式。 17借助 Town Crier，第一层节点还可以在本地生成证明 他们输出的报告的正确性，并向网络上的第二层节点提供这些证明 按需基础上。误报保险的基本形式可以在值得信赖和 使用 smart contracts 的有效方式。举个简单的例子，参数保险 如果我们的激励机制有效，合同 SCins 可以自动补偿保单持有人 第二层标识第一层生成的报告中的错误。 希望购买保险的用户U，例如目标的创建者 SC 合约，可以向去中心化保险公司提交保单金额请求 合同金额为 M 美元。在批准 U 后，保险公司可以设置持续的（例如每月） SCins 中 $P 的溢价。当 U 支付保费时，她的保单仍然有效。 如果 SC 发生报告失败，结果将是一对 (r1, r2) 的发射 SC 的冲突报告，其中 r1 由我们机制中的第一层签名， r2，相应的更正报告，由第二层签署。如果U提供 这样一个有效的 SCins 对 (r1, r2)，合约会自动向她支付 M 美元，前提是 她的保费是最新的。 9.5 单轮变体 上一小节中描述的协议要求第二层委员会等待 n 轮以确定看门狗是否发出警报。 这个 即使在乐观的情况下，即当第一层运行时，要求也成立 正确。对于不愿意乐观地接受报告的用户，即在潜在的 裁决，与该方法相关的拖延是行不通的。 出于这个原因，我们也在探索只需要一个的替代协议 圆形。在这种方法中，所有 oracle 节点提交秘密位，指示是否 他们希望发出警报。然后，第二层委员会检查这些值 优先顺序。为了提供一个粗略的草图，这样的方案可能涉及以下内容 步骤： 1.看门狗位提交：每个节点Oi秘密共享一位看门狗值 对于它生成的每个报告，第二层中的节点之间 wi 属于{无警报，警报}。 2. 匿名提示：任何oracle节点都可以在提交看门狗位的同一轮中向二级委员会提交匿名提示α。这个提示α 是一条消息，指示已针对当前报告发出警报。 3. 看门狗位检查：第二层委员会揭示oracle节点的看门狗 按优先级顺序排列的位。 请注意，节点在不发出警报时不得发送警报看门狗位：否则，流量分析会显示所有节点的位。该协议确实显示无警报 优先级高于最高优先级警报看门狗的节点的看门狗位。 观察到所揭示的内容与我们的 n 轮协议相同。奖励的分配也与该方案相同，即第一个识别的看门狗 收到提交错误报告的节点的被削减的存款。使用匿名提示使二级委员会能够在没有发出警报的情况下保持非互动，从而降低沟通复杂性 在常见情况下。请注意，任何提出警报的监管机构都有提交匿名举报的经济动机：如果没有提交举报，则不会向任何人支付任何奖励 节点。 确保匿名提示 α 的发送者 Oi 不能被 根据网络数据，攻击者可以通过匿名方式发送匿名提示 通道，例如通过 Tor，或者更实际地，通过云服务提供商代理。至 验证 Tip 源自 O，Oi 可以使用环签名对 α 进行签名 [39, 192]。 或者，为了防止恶意 oracle 节点对第二层委员会进行不可归因的拒绝服务攻击，α 可以是一个匿名凭证， 可撤销的匿名[73]。 该协议虽然实际上是可以实现的，但具有一定的重量级工程 要求（我们正在探索减少的方法）。以第一层节点为例， 必须直接与第二层节点通信，需要维护目录。对匿名通道和环签名的需求增加了工程量 方案的复杂性。最后，简要讨论了一个特殊的信任要求 在下面的注释中。因此，我们也在探索更简单的方案，但仍能实现 超线性 staking 影响，但可能小于二次影响，例如，行贿者渐近需要至少 $n log n 的资源。以下的一些计划 考虑因素涉及随机选择节点的严格子集作为看门狗， 在这种情况下，潜在的贿赂就成为一种特别有力的攻击。 备注： 这种单轮 staking 机制的安全性需要不可攻克 oracle 和第二层节点之间的通道——这是抗强制系统的标准要求，例如投票 [82, 138]，并且在实践中是合理的。 然而，此外，寻求与行贿者合作的节点 Oi 可以构建 其秘密共享的方式是向行贿者表明它已对特定的内容进行了编码 值。例如，如果 Oi 不知道行贿者控制哪些节点，那么 Oi 可以 向所有委员会成员提交 0 值股票。然后行贿者可以验证 Oi 的 概率上的合规性。为了避免在任何单轮协议中出现这个问题，我们 要求 Oi 知道至少一个诚实的第二层节点的身份。 使用交互式协议，其中每个第二层节点添加随机化 股份的因素，行贿者能做的最好的事情就是强制 Oi 随机选择 看门狗位。 9.6 隐性激励框架（IIF） FFO 是对 Chainlink 网络中正确行为的隐性激励的一种形式。它 其功能类似于显性权益（即存款），因为它有助于加强经济安全 网络。换句话说，FFO 应包含在（有效）存款中 网络中节点的$d。问题是：我们如何衡量 FFO 和其他形式的隐性激励 在 Chainlink 网络内？ 隐性激励框架（IIF）是一套 我们计划为此目的开发的原则和技术。区块链系统 提供多种形式前所未有的透明度，以及节点的高信任记录 他们创造的业绩是我们实现 IIF 如何运作的愿景的跳板。 在这里，我们非常简要地概述了 IIF 关键要素的想法。 IIF 本身将包含一系列我们认为在评估中重要的因素 隐性激励，以及以高保证形式发布相关数据以供分析算法使用的机制。不同的 Chainlink 用户可能 希望以不同的方式使用 IIF，例如，对不同的因素给予不同的权重。 我们期望社区中出现分析服务，帮助用户应用 IIF 根据他们个人的风险评估偏好，我们的目标是促进 通过确保他们获得高可信度和及时的支持数据来提供此类服务， 正如我们下面讨论的（第 9.6.4 节）。 9.6.1 未来的收费机会 节点参与 Chainlink 生态系统，以赚取网络为我们在本文中描述的任何各种服务支付的费用的一部分，从 将普通数据馈送到高级服务，例如去中心化身份、公平排序、 和保密DeFi。 Chainlink 网络中的费用支持节点运营商的成本，例如运行服务器、获取必要的数据许可证和维护 全球员工确保高正常运行时间。 FFO 表示扣除费用后的服务费， 节点在未来会获得收益，或者如果表现出错误行为则会损失。 FFO 是一种有助于保护网络安全的权益形式。 FFO 的一个有用功能是链上数据（由链下数据补充） 数据）建立节点历史的高信任记录，从而实现 FFO 的计算 以透明的、经验驱动的方式。 FFO 的一个简单的一阶度量可以从一个企业的平均净收入中得出 一段时间内的节点（即总收入减去运营费用）。 FFO 可能 然后计算为，例如，累计未来净收入的净现值[114]， 换句话说，所有未来收益的时间贴现值。 然而，节点收入可能会波动，如图 17 所示。 更重要的是，节点收入可能不会遵循平稳的分布 随着时间的推移。因此，我们计划在估算 FFO 时探索的其他因素包括： • 绩效历史记录：操作员的绩效历史记录（包括其报告的正确性和及时性以及正常运行时间）提供了一个目标 为用户评价其可靠性的试金石。 因此，性能历史将 为用户选择 oracle 节点提供一个关键因素（或者，随着出现 DONs，他们选择的 DONs)。强劲的业绩历史可能会 与高额持续收入相关。18 18我们打算解决的一个重要研究问题是伪造服务量的检测。图 17：Chainlink 节点在单个数据源 (ETH-USD) 期间赚取的收入 2021 年 3 月具有代表性的一周。 • 数据访问：虽然oracles 可以从开放API 获取多种形式的数据， 某些形式的数据或某些高质量来源可能仅在 认购基础上或通过合同协议。对某些内容的特权访问 数据源可以在创造稳定的收入流方面发挥作用。 • DON 参与：随着 DON 的出现，节点社区将会出现 共同提供特定服务。我们预计许多 DON 将包括 选择性地运营商，参与信誉良好的 DONs 作为 优越的市场地位有助于确保稳定的收入来源。 • 跨平台活动：一些节点运营商可能在其他环境中拥有良好的存在和绩效跟踪记录，例如 PoS validators 或 非 blockchain 上下文中的数据提供者。它们在这些其他系统中的表现（当其数据以可信形式提供时）可以为评估提供信息 他们的表演历史。同样，Chainlink 网络中的错误行为 可能会通过赶走用户（即 FFO）来危及这些其他系统的收入 可以跨平台扩展。 9.6.2 投机性 FFO 节点运营商参与 Chainlink 网络不仅仅是为了从中获得收入 运营，而是创造并定位自己，以利用新的机会来开展工作。换句话说，网络中 oracle 节点的支出也是 关于 DeFi 和其他智能合约应用的未来的积极声明 域以及 oracle 网络的新兴非 blockchain 应用。如今，节点运营商赚取现有 Chainlink 网络上可用的费用，同时 这些与互联网网站上的虚假评论大致相似，只不过问题在 oracle 设置，因为我们有关于货物（即报告）是否已订购和是否已订购的最终记录。 交付——与在网上商店订购的实物商品不同。换句话说，在 oracle 中 即使无法验证客户的真实性，也可以验证性能。建立声誉、业绩历史和运营专业知识，以定位 他们有利于赚取未来网络中可用的费用（当然， 诚实行为）。今天在 Chainlink 生态系统中运行的节点将在此 感觉比新人在赚取额外 Chainlink 费用方面有优势 服务变得可用。这一优势适用于新运营商，以及享有盛誉的科技公司；例如，T-Systems，一个传统的 技术提供商（德国电信的子公司）和 Kraken（一家大型中心化公司） 交换，已在 Chainlink 生态系统中建立了早期存在 [28, 143]。 oracle 节点对未来机会的这种参与可能被视为本身 作为一种投机性 FFO，因此构成 Chainlink 的一种股权形式 网络。 9.6.3 外部声誉 正如我们所描述的，IIF 可以在严格假名的网络中运行 运营商，即不披露所涉及的人员或现实世界实体。 然而，用户选择提供商的一个潜在重要因素是外部因素。 声誉。外部声誉是指对现实世界身份而非假名的可信度的感知。声誉风险 现实世界的身份可以被视为隐性激励的一种形式。我们看信誉 通过 IIF 的视角，即在加密经济学意义上，作为建立 可能会纳入 FFO 估算的跨平台活动。 使用外部声誉作为 FFO 估计因素的好处，而不是 与假名链接相比，外部声誉不仅与绩效相关 运营商现有的活动，也包括未来的活动。例如，如果声誉不好 依附于一个人，它可能会污染这个人未来的企业。换句话说，与假名相比，外部声誉可以捕获更广泛的 FFO 绩效记录，作为个人或既定的不当行为的影响 与假名操作相比，公司更难逃脱。 Chainlink 与去中心化身份技术（第 4.3 节）兼容， 可以为 IIF 中外部声誉的使用提供支持。此类技术 可以验证并从而帮助确保运营商声称的现实世界的准确性 身份.19 9.6.4 开放 IIF 分析 正如我们所指出的，IIF 旨在为以下领域提供可靠的开源数据和工具： 隐性激励分析。 目标是使社区内的提供者能够 开发适合不同部门风险评估需求的分析 Chainlink 用户群。 19如果需要的话，去中心化的身份凭证还可以用经过验证的假名来修饰假名。 补充信息。例如，节点运营商原则上可以使用此类凭证来 证明它是一家财富 500 强公司，但没有透露是哪一家。大量关于节点收益和性能的历史数据 以高度信任、不可变的形式驻留在链上。然而，我们的目标是提供 最全面的可能数据，包括仅在外部可见的行为数据 链，例如链外报告 (OCR) 或 DON 活动。此类数据有可能 内容要丰富。存储它并确保其完整性的最佳方法，即保护它免受 我们相信，篡改将在 DONs 的帮助下，使用所讨论的技术 在第 3.3 节中。 有些激励措施适合直接的衡量形式，例如 staking 存款和基本 FFO。其他的，例如投机性 FFO 和声誉，则更难 以客观的方式进行衡量，但我们认为支持数据的形式，包括 Chainlink 生态系统的历史增长、社交媒体声誉指标等， 即使对于这些难以量化的元素，也可以支持 IIF 分析模型。 我们可以想象专门的 DON 专门用于监视、验证和 记录与节点的链外性能记录相关的数据，以及其他数据 在 IIF 中使用，例如经过验证的身份信息。这些 DON 可以为任何为 Chainlink 社区提供服务的分析提供商提供统一、高信任度的 IIF 数据。 他们还将提供黄金记录，让分析提供商声称 由社区独立验证。 9.7 综合起来：节点运营商激励 综合我们上面关于节点运营商的显性和隐性激励的讨论 提供节点运营商参与并从中受益的方式的整体视图 Chainlink 网络。 作为概念指南，我们可以通过给定的 Chainlink 来表示所涉及的总资产 节点运算符 $S 的粗略、程式化形式如下： \(S ≈\)D + \(F + \)FS + $R， 其中： • $D 是所有网络中所有明确存入的权益的总和，其中 经营者参与； • $F 是所有网络中所有 FFO 总和的净现值 运营商参与的； • $FS 是运营商的投机FFO 的净现值；和 • $R 是Chainlink 生态系统之外的运营商的声誉资产 其 oracle 节点中发现的不当行为可能会危及这一点。 虽然主要是概念性的，但这种粗略的等式有助于表明存在有多种经济因素有利于 Chainlink 节点的高可靠性性能。 除 $D 之外的所有这些因素都存在于当今的 Chainlink 网络中。9.8 经济安全的良性循环 超线性 staking 影响与费用支付表示的结合 因为 IIF 中的未来费用机会 (FFO) 可以带来我们所说的良性循环 oracle 网络中的经济安全。这可以看作是一种经济 规模。随着特定网络保护的总量增加， 增加固定数量的经济安全所需的额外股份会随着增加而减少 每个用户的平均成本。因此，就费用而言，用户加入更便宜 一个已经存在的网络比实现同样的网络经济增长 通过创建新网络来确保安全。重要的是，每个新用户的添加都会降低 该网络所有先前用户的服务成本。 给定特定的费用结构（例如，质押金额的特定收益率）， 如果网络赚取的总费用增加，就会刺激额外的流量 投入网络以更高的速度保护网络。具体来说，如果总权益 单个节点在系统中的持有量是有上限的，那么当新的费用支付时 进入系统，提高其FFO，节点数n将增加。感谢 超线性 staking 我们激励制度设计的影响，经济安全 系统将比 n 上升得更快，例如，我们在第 9.4 节中概述的机制中为 n2。 因此，经济安全的平均成本，即贡献的股份数量 一美元的经济安全——将会下降。因此，网络可以向用户收费 较低的费用。假设对 oracle 服务的需求是有弹性的（例如，参见 [31] 了解简要信息） 解释），需求将会上升，产生额外费用和 FFO。 我们用下面的例子来说明这一点。 示例 5. 由于 oracle 网络在我们的激励下具有经济安全性 方案为\(dn2 for stake \)dn，一美元的权益所贡献的经济安全 是 n，因此每美元经济安全的平均成本——即股权数量 对一美元经济安全的贡献是 1/n。 考虑一个网络，其中经济激励完全由 FFO 组成，上限为 每个节点 \(d ≤\)10K。假设网络有 n = 3 个节点。那么平均成本 每美元的经济安全约为 0.33 美元。 假设网络的总 FFO 上升到 \(30K (e.g., to \)31K 以上。给定 每个节点 FFO 的上限，网络增长到（至少）n = 4。现在平均成本 每美元的经济安全下降至约 0.25 美元。 我们在图 18 中示意性地说明了 oracle 网络中经济安全的完整良性循环。 我们强调经济安全的良性循环源于 用户汇集费用。 正是他们的集体 FFO 有利于更大的 网络规模，从而提高集体安全性。我们还注意到，良性循环 经济安全有利于 DON 实现财务可持续性。曾经 创建的、满足用户需求的 DON 应该增长到并超过 oracle 节点的费用收入超过运营成本。
图 18：Chainlink staking 的良性循环示意图。使用费上涨 向 oracle 网络支付 1⃝ 使其增长，从而导致其经济增长 安全2⃝。这种超线性增长在 Chainlink 网络中实现了规模经济 3⃝。具体来说，它意味着经济安全平均成本的降低，即 由费用支付或其他股权来源产生的每美元经济安全 增加。降低成本，转嫁给用户，刺激对 oracle 的需求增加 服务4⃝。 9.9 推动网络增长的其他因素 随着 Chainlink 生态系统的不断扩大，我们相信它的吸引力 对用户的重要性以及作为 blockchain 经济基础设施的重要性将会加速。 oracle 网络提供的值是超线性的，这意味着它增长得更快比网络本身的规模更大。 这种价值的增长来自于 规模经济——随着服务量的增加，每个用户的成本效率更高——以及 网络效应——随着用户更广泛地采用 DON，网络效用增加。 随着现有的 smart contract 继续获得更多价值和全新价值 smart contract 应用程序通过更加去中心化的服务而成为可能， DON 的使用和支付的总费用应该会增加。 增加收费池 转变为创造更加去中心化服务的手段和激励， 从而形成良性循环。 这种良性循环解决了关键的先有鸡还是先有蛋的问题 混合 smart contract 生态系统中的问题：创新 smart contract 功能 通常需要尚不存在的去中心化服务（例如，新的 DeFi 市场通常 需要新的数据源）但需要足够的经济需求才能存在。 各个 smart contract 对现有 DON 的费用汇集将表明对 来自不断增长的用户群的额外去中心化服务，从而催生了它们的诞生 由 DONs 和不断启用新的和多样化的混合 smart contracts。 综上所述，我们认为网络安全的增长是由良性的驱动的 Chainlink staking 机制中的循环体现了更大的增长模式 Chainlink 网络可以帮助实现去中心化的链上经济 服务。
الاقتصاد والاقتصاد المشفر
لكي تتمكن شبكة Chainlink من تحقيق أمان قوي ضمن نموذج ثقة لامركزي، من الضروري أن تظهر العقد بشكل جماعي السلوك الصحيح، مما يعني أنها تلتزم في أغلب الأحيان بالضبط إلى بروتوكولات DON. في هذا القسم، نناقش الأساليب للمساعدة في فرض مثل هذا السلوك عن طريق الحوافز الاقتصادية، المعروفة أيضًا باسم الاقتصاد المشفر الحوافز. وتنقسم هذه الحوافز إلى فئتين: صريحة وضمنية، محققة على التوالي من خلال staking وفرصة الرسوم المستقبلية (FFO). التوقيع المساحي: يتضمن التخزين Chainlink، كما هو الحال في أنظمة blockchain الأخرى، المشاركين في الشبكة، أي oracle العقد، وإيداع الأموال المقفلة في شكل LINK tokens. هذه الأموال، والتي نشير إليها أيضًا باسم الحصة أو الحصة الصريحة هي حافز صريح. هم تخضع للمصادرة عند فشل العقدة أو المخالفات. في سياق blockchain، غالبًا ما يسمى هذا الإجراء بالقطع. ومع ذلك، فإن التوقيع المساحي بواسطة oracle العقد في Chainlink يختلف بشكل أساسي عن staking بواسطة validators في blockchains غير المسموح بها. يمكن أن يسيء المدققون التصرف عن طريق المراوغة أو طلب المعاملات بشكل عدائي. بروتوكول الإجماع الأساسي في أ 15 بما أنه يمكن للمستخدمين استبدال المعاملات في مجمع الذاكرة، يلزم الحذر لضمان المراسلات الصحيحة بين المعاملات المستخرجة والمعاملات المقدمة DON.ومع ذلك، فإن blockchain غير المسموح به يستخدم قواعد صارمة وسريعة للتحقق من صحة الكتلة وأساسيات التشفير لمنع validators من إنشاء كتل غير صالحة. في المقابل، لا يمكن للحماية البرمجية أن تمنع إنشاء شبكة oracle للغش تقارير غير صالحة. السبب هو الاختلاف الرئيسي بين نوعي النظام: التحقق من صحة المعاملة في blockchains هو خاصية الاتساق الداخلي، في حين أن الصحة من oracle التقارير على blockchain هي خاصية خارجية، أي بيانات خارج السلسلة. لقد قمنا بتصميم آلية staking الأولية لشبكة Chainlink القائمة على على بروتوكول تفاعلي بين العقد oracle التي قد تستفيد من البيانات الخارجية. هذا تخلق الآلية حوافز مالية للسلوك الصحيح باستخدام مكافآت صريحة و العقوبات (القطع). وبما أن الآلية اقتصادية، فهي مصممة لمنع العقدة الفساد من قبل خصم يستخدم الموارد المالية لإفساد العقد عن طريق رشوة. (مثل هذا الخصم عام جدًا، ويمتد، على سبيل المثال، إلى العقد المتعاونة معها استخراج القيمة من سوء سلوكهم الجماعي.) تتميز آلية Chainlink staking التي صممناها ببعض القوة والرواية الميزات.16 الميزة الرئيسية هي التأثير الخطي الفائق staking (على وجه التحديد، التربيعي). يجب أن يكون لدى الخصم موارد تزيد بشكل كبير عن الأموال المودعة في العقد من أجل تخريب الآلية. بالإضافة إلى ذلك، توفر آلية staking الخاصة بنا الحماية ضد خصم أقوى مما كان مذكورًا سابقًا في أنظمة مماثلة، وهي خصم يمكنه إنشاء رشاوى تتكيف مع سلوك العقد المستقبلي. بالإضافة إلى ذلك، نناقش كيف يمكن لأدوات Chainlink مثل DECO أن تساعد في تعزيز staking لدينا آلية من خلال تسهيل الفصل الصحيح في حالة سلوك العقدة الخاطئ. فرصة الرسوم المستقبلية (FFO): blockchains غير مسموح بها — لكل من إثبات العمل (PoW). وتنوع إثبات الحصة (PoS) – يعتمد اليوم بشكل حاسم على ما نسميه الحوافز الضمنية. هذه هي الحوافز الاقتصادية للسلوك الصادق التي لا تستمد من المكافآت الصريحة، ولكن من مشاركة المنصة نفسها. على سبيل المثال، يتم تحفيز مجتمع عمال المناجم Bitcoin ضد شن هجوم بنسبة 51% بسبب خطر تقويض الثقة في Bitcoin، مما يؤدي إلى خفض قيمتها، وبالتالي تآكل قيمة جمعيتها الاستثمارات الرأسمالية في البنية التحتية للتعدين [150]. تستفيد شبكة Chainlink من الحافز الضمني المماثل الذي نشير إليه كفرصة للرسوم المستقبلية (FFO). عقد Oracle ذات تاريخ أداء قوي أو السمعة تجذب الرسوم من المستخدمين. سوء التصرف من قبل عقدة oracle يعرض المستقبل للخطر دفع الرسوم وبالتالي معاقبة العقدة بتكلفة الفرصة البديلة من حيث الإمكانات الإيرادات المكتسبة من خلال المشاركة في الشبكة. قياسا على حصة صريحة، قد يُنظر إلى FFO على أنه شكل من أشكال الحصة الضمنية، أو حافز للسلوك الصادق مستمد من المنفعة المشتركة المتمثلة في الحفاظ على الثقة في المنصة التي تعمل عليها تعتمد أعمال مشغلي العقد، على سبيل المثال، على الأداء الإيجابي والسمعة الإيجابية للعقدة شبكة. هذا الحافز متأصل في شبكة Chainlink ولكن لم يتم التعبير عنه صراحةً البروتوكولات. وفي Bitcoin الحفاظ على قيمة عمليات التعدين كما ذكرنا أعلاه 16إن آلية staking التي نصفها هنا تهدف حاليًا فقط إلى فرض تسليم التقارير الصحيحة بواسطة شبكات oracle. ونتوقع في العمل المستقبلي توسيع نطاقه لضمان التنفيذ الصحيح للكثيرين سيتم توفير وظائف أخرى DONs.قد يُنظر إليها بالمثل على أنها شكل من أشكال الحصة الضمنية. نؤكد على أن FFO موجود بالفعل في Chainlink ويساعد في تأمين الشبكة اليوم. ستكون مساهمتنا الرئيسية في التطوير الإضافي لـ Chainlink هي اتباع نهج مبدئي مدفوع تجريبيًا لتقييم الحوافز الضمنية مثل FFO من خلال ما نسميه إطار الحوافز الضمنية (IIF). لتقدير الكميات مثل فرصة الرسوم المستقبلية للعقد، سوف يعتمد معهد التمويل الدولي بشكل مستمر على النطاق الشامل بيانات الأداء والدفع التي تم جمعها بواسطة شبكة Chainlink. مثل هذه التقديرات سيتم تمكين المعلمات المستندة إلى IIF لأنظمة staking التي تعكس حوافز العقدة بدقة أكبر من النماذج الإرشادية و/أو الثابتة الحالية. لتلخيص الحافزين الاقتصاديين الرئيسيين للعقدة oracle الصحيحة السلوك في شبكة Chainlink النامية سيكون: • التوقيع المساحي (الحصة المودعة) س الحافز الصريح • فرصة الرسوم المستقبلية (FFO) س الحافز الضمني وهذان الشكلان من الحوافز متكاملان. يمكن للعقد أوراكل في وقت واحد شارك في بروتوكول Chainlink staking، واستمتع بتدفق مستمر للإيرادات من المستخدمين، والاستفادة بشكل جماعي من سلوكهم الجيد المستمر. وبالتالي كلا الحوافز المساهمة في أمن الاقتصاد المشفر الذي توفره شبكة oracle. بالإضافة إلى ذلك، ويمكن تعزيز الحافزين و/أو تبادلهما ضد بعضهما البعض. على سبيل المثال، يمكن لمشغل oracle جديد بدون سجل أداء وتدفق إيرادات أن يشارك في كمية كبيرة من LINK كضمان للسلوك الصادق، وبالتالي جذب المستخدمين والرسوم. وعلى العكس من ذلك، فإن مشغل oracle الذي تم تأسيسه يتمتع بمشغل طويل وخالي من الأخطاء نسبيًا يمكن أن يتقاضى سجل الأداء رسومًا كبيرة من قاعدة مستخدمين كبيرة وبالتالي يعتمد عليه بشكل أكبر على FFO كشكل من أشكال الحوافز الضمنية. بشكل عام، يهدف النهج الذي ندرسه هنا إلى قدر معين من oracle-الشبكة مورد لإنشاء أكبر قدر ممكن من الحوافز الاقتصادية في Chainlink للعقلانية الوكلاء - أي العقد التي تزيد من فائدتهم المالية - إلى التصرف بأمانة. ضع آخر وبطريقة ما، فإن الهدف هو تعظيم الموارد المالية اللازمة لكي يقوم الخصم بالهجوم الشبكة بنجاح. من خلال صياغة بروتوكول staking بطريقة رياضية جيدة الأمن الاقتصادي المحدد وأيضا باستخدام معهد التمويل الدولي، ونحن نهدف إلى قياس قوة حوافز Chainlink بأكبر قدر ممكن من الدقة. المبدعين من الاعتماد على العقود سوف ثم تكون قادرًا على التحديد بثقة قوية ما إذا كانت شبكة oracle تجتمع أم لا المستويات المطلوبة من الأمن الاقتصادي المشفر. الدورة الحميدة للأمن الاقتصادي: إن الحوافز التي نناقشها في هذا القسم، staking وFFO، لها تأثير يتجاوز تعزيزها لأمن DONs. وهي تَعِد بتحفيز ما نسميه بالدورة الحميدة للأمن الاقتصادي. يؤدي التأثير الخطي الفائق staking (ووفورات الحجم الأخرى) إلى انخفاض التشغيل التكلفة مع نمو أمان DON. التكلفة المنخفضة تجذب المزيد من المستخدمين إلى DON،تعزيز مدفوعات الرسوم. ويستمر الارتفاع في مدفوعات الرسوم في تحفيز النمو في الشبكة، التي تديم الدورة الحميدة. ونحن نعتقد أن الدورة الحميدة للأمن الاقتصادي هي مجرد مثال واحد على ذلك وفورات الحجم وتأثير الشبكة من بين أشياء أخرى سنناقشها لاحقًا في هذا القسم. تنظيم القسم: يمثل التوقيع المساحي تحديات فنية ومفاهيمية ملحوظة والتي قمنا بتصميم آلية ذات ميزات جديدة. لذلك سيكون التوقيع المساحي تركيزنا الرئيسي في هذا القسم. نقدم نظرة عامة على نهج staking الذي نقدمه في هذه الورقة في القسم 9.1، تليها مناقشة مفصلة في الأقسام 9.2 إلى 9.5. نحن نقدم IFF في القسم 9.6. نقدم عرضًا ملخصًا لحوافز شبكة Chainlink في القسم 9.7. في القسم 9.8، نناقش الدورة الحميدة للأمن الاقتصادي التي يمكن أن يجلبها نهجنا staking المقترح إلى شبكات oracle. وأخيرًا، سنصف بإيجاز الإمكانات الأخرى التأثيرات الدافعة لنمو شبكة Chainlink في القسم 9.9. 9.1 نظرة عامة على التوقيع المساحي يتضمن تصميم آلية staking الذي نقدمه هنا، كما هو مذكور أعلاه، بروتوكولًا تفاعليًا بين العقد oracle مما يسمح بحل التناقضات في الإبلاغ عن البيانات الخارجية. يهدف التوقيع المساحي إلى ضمان السلوك الصادق من العقد oracle العقلانية. يمكننا بالتالي أن نصمم خصمًا يهاجم بروتوكول staking باعتباره الراشي: تتمثل استراتيجية الخصم في إفساد oracle العقد باستخدام الحوافز المالية. وقد يستمد الخصم موارد مالية بأثر رجعي من التلاعب الناجح مع تقرير oracle، على سبيل المثال، عرض مشاركة الأرباح الناتجة مع العقد التالفة. نحن نهدف في تصميم آلية staking إلى تحقيق هدفين طموحين في وقت واحد: 1. مقاومة خصم قوي: تم تصميم آلية staking للحماية oracle شبكات ضد فئة واسعة من الخصوم القادرين على القيام بعمليات معقدة، استراتيجيات الرشوة المشروطة، بما في ذلك الرشوة المحتملة، التي تقدم الرشاوى إلى oracle الذين يتم تحديد هوياتهم بعد وقوع الحدث (على سبيل المثال، يقدم رشاوى لـ oracles تم اختيارها عشوائيًا للتنبيه ذي الأولوية العالية). بينما تصميمات oracle أخرى وقد اعتبرت مجموعة ضيقة من الهجمات دون كامل القدرات الواقعية الخصم، على حد علمنا آلية الخصومة التي نقدمها هنا هو أول من تناول بشكل صريح مجموعة واسعة من استراتيجيات الرشوة والعروض المقاومة في هذا النموذج يفترض نموذجنا أن العقد بجانب المهاجم موجودة عقلاني اقتصاديًا (على عكس الصادق)، ونفترض وجود أ مصدر الحقيقة باهظ التكلفة للاستخدام النموذجي ولكنه متاح في حالة الخلاف (تتم مناقشته أدناه). 2. تحقيق تأثير خطي فائق staking: هدفنا هو التأكد من أن شبكة oracle المكونة من وكلاء عقلانيين تقدم التقارير بصدق حتى في وجود مهاجم بميزانية فائقة الخطيةفي إجمالي الحصة المودعة من قبل الشبكة بأكملها. في أنظمة staking الموجودة، إذا تبلغ قيمة كل عقدة n $d، ويمكن للمهاجم إصدار رشوة موثوقة تطلبها أن العقد تتصرف بطريقة غير شريفة مقابل دفع مبلغ يزيد قليلاً عن \(d to each node, using a total budget of about \)dn. وهذا بالفعل شريط مرتفع يجب أن يكون لدى المهاجم ميزانية سائلة بناءً على الودائع المجمعة جميع أصحاب المصلحة في الشبكة. وهدفنا هو تحقيق درجة أقوى من الأمن الاقتصادي من هذه العقبة الكبيرة بالفعل. نحن نهدف إلى تصميم أول نظام staking يمكنها تحقيق الأمان لمهاجم عام بميزانية خطية فائقة في n. في حين أن الاعتبارات العملية قد تحقق تأثيرًا أقل، كما نناقش أدناه، يحقق تصميمنا الأولي متطلبات ميزانية تنافسية أكبر من $dn2/2، أي تحجيم التربيعية في n، مما يجعل الرشوة غير عملية إلى حد كبير حتى عندما تشترك العقد بكميات معتدلة فقط. ويتطلب تحقيق هذين الهدفين مزيجاً مبتكراً من تصميم الحوافز والتشفير. الأفكار الرئيسية: يعتمد نهجنا staking على فكرة نطلق عليها أولوية المراقبة. تقرير تم إنشاؤه بواسطة شبكة Chainlink oracle وإرساله إلى عقد الاعتماد (على سبيل المثال، على سعر الأصل) يتم تجميعها من التقارير الفردية التي تساهم بها العقد المشاركة (على سبيل المثال، عن طريق أخذ المتوسط). عادةً ما تكون اتفاقية مستوى الخدمة (SLA) يحدد حدود الانحراف المقبولة للتقارير، أي إلى أي مدى يمكن أن يصل تقرير العقدة الانحراف عن التقرير الإجمالي وإلى أي مدى ينبغي السماح للتجميع بذلك تنحرف عن القيمة الحقيقية لاعتبارها صحيحة. في نظام staking الخاص بنا، بالنسبة لجولة تقارير معينة، يمكن لكل عقدة oracle أن تعمل كـ هيئة رقابية لتوجيه تنبيه إذا اعتقدت أن التقرير الإجمالي غير صحيح. في كل جولة إعداد التقارير، يتم تعيين أولوية عامة لكل عقدة oracle تحدد الترتيب الذي ستتم به معالجة تنبيهه (إن وجد). آليتنا تهدف إلى المكافأة التركيز، مما يعني أن الجهة الرقابية ذات الأولوية القصوى لرفع التنبيه تحصل على المكافأة الكاملة الناتجة عن مصادرة رواسب العقد المعيبة. تشتمل تصميمات نظامنا staking على مستويين: الأول، المستوى الافتراضي، والثاني، الطبقة الخلفية. الطبقة الأولى هي شبكة oracle نفسها، وهي مجموعة من العقد n. (من أجل البساطة، نحن نفترض أن n أمر فردي.) إذا أبلغت غالبية العقد عن قيم غير صحيحة، فستقوم هيئة رقابية في يتم تحفيز المستوى الأول بقوة لرفع مستوى التنبيه. إذا تم رفع تنبيه، الإبلاغ يتم بعد ذلك تصعيد القرار المتعلق بالشبكة إلى المستوى الثاني، وهو نظام عالي التكلفة وأقصى قدر من الموثوقية يمكن تحديده من قبل المستخدم في اتفاقية مستوى خدمة الشبكة. يمكن أن يكون هذا النظام، على سبيل المثال، يتكون فقط من العقد ذات القوة القوية درجات الموثوقية التاريخية، أو تلك التي لها ترتيب أكبر من oracles الطبقة الأولى. بالإضافة إلى ذلك، كما تمت مناقشته في القسم 9.4.3، يمكن أن يخدم DECO أو Town Crier كأدوات قوية للمساعدة في ضمان إصدار أحكام قضائية فعالة وحاسمة في المستوى الثاني. ومن أجل التبسيط، فإننا نفترض أن نظام المستوى الثاني هذا قد وصل إلى التقرير الصحيح قيمة. على الرغم من أنه قد يبدو جذابًا الاعتماد على المستوى الثاني لإنشاء كافة التقارير، إلا أنه تكمن فائدة تصميمنا في أنه يحقق باستمرار الخصائص الأمنية للشبكةنظام من المستوى الثاني مع دفع تكاليف التشغيل فقط، في الحالة النموذجية، لل نظام الطبقة الأولى. تؤدي أولوية الوكالة الدولية للطاقة إلى تأثير خطي فائق staking بالطريقة التالية: إذا كان تُخرج شبكة oracle من المستوى الأول نتيجة غير صحيحة وعددًا من عقد المراقبة تنبيه، فإن آلية الحوافز staking تكافئ هيئة المراقبة ذات الأولوية القصوى أكثر من $dn/2 مأخوذة من ودائع العقد (الأغلبية) التي تسيء التصرف. ال وبالتالي فإن المكافأة الإجمالية تتركز في أيدي هذه الوكالة الرقابية الواحدة، والتي بالتالي يحدد الحد الأدنى الذي يجب على الخصم أن يعد به هيئة رقابية محتملة تحفيزه على عدم التنبيه. نظرًا لأن آليتنا تضمن حصول كل oracle على فرصة للعمل كرقيب إذا قبلت هيئات المراقبة ذات الأولوية العليا رشاويهم (واختار عدم التنبيه)، لذلك يجب على الخصم أن يقدم رشوة بأكثر من $dn/2 إلى كل عقدة لمنع إثارة أي تنبيه. نظرًا لوجود n عقد، فإن تبلغ الميزانية المطلوبة للخصم من أجل الحصول على رشوة ناجحة ما يزيد عن 2/2 دولار أمريكي، وهو ما يعادل 2/2 دولار أمريكي هو تربيعي في عدد n من العقد في الشبكة. 9.2 الخلفية يعتمد نهجنا في staking على الأبحاث في مجالات نظرية اللعبة وآلياتها التصميم (MD) (للحصول على مرجع كتاب مدرسي، راجع [177]). نظرية اللعبة هي رياضيا دراسة رسمية للتفاعل الاستراتيجي. وفي هذا السياق، تعتبر اللعبة نموذجًا لذلك تفاعل، عادة ما يكون في العالم الحقيقي، يقنن مجموعات من الإجراءات المتاحة المشاركين في اللعبة، والمعروفين باللاعبين. تحدد اللعبة أيضًا المكاسب التي تم الحصول عليها من قبل اللاعبين الفرديين - المكافآت التي تعتمد على الإجراءات التي يختارها اللاعب و تصرفات اللاعبين الآخرين. ولعل أفضل مثال معروف للعبة تمت دراستها في اللعبة النظرية هي معضلة السجناء [178]. يهدف منظرو الألعاب عمومًا إلى الفهم التوازن أو التوازنات (إن وجدت) الممثلة في لعبة معينة. التوازن هو مجموعة من الاستراتيجيات (واحدة لكل لاعب) بحيث لا يستطيع أي لاعب الحصول على أعلى المكافأة عن طريق الانحراف من جانب واحد عن استراتيجيتها. وفي الوقت نفسه، فإن تصميم الآلية هو علم تصميم الحوافز بحيث يتم يتمتع توازن التفاعل (واللعبة المرتبطة به) ببعض الخصائص المرغوبة. يمكن النظر إلى MD على أنه عكس نظرية اللعبة: السؤال الأساسي في اللعبة النظرية هي: "في ضوء الحوافز والنموذج، ماذا سيكون التوازن؟" في دكتوراه في الطب، والسؤال هو بدلاً من ذلك: "ما هي الحوافز التي ستؤدي إلى لعبة ذات توازن مرغوب؟" الهدف النموذجي لمصمم الآلية هو إنشاء آلية "متوافقة مع الحوافز"، مما يعني أن المشاركين في الآلية (على سبيل المثال، مزاد أو معلومات أخرى) يتم تحفيز نظام الاستنباط [228]) للإبلاغ عن الحقيقة بشأن بعض الأمور (على سبيل المثال، كيف كثيرًا ما يقدرون عنصرًا معينًا). ربما يكون مزاد فيكري (السعر الثاني) هو أفضل آلية معروفة متوافقة مع الحوافز، حيث يقدم المشاركون عطاءات مختومة لعنصر ما، ويفوز أعلى مزايد بالعنصر ولكنه يدفع ثاني أعلى سعر [214]. اقتصاديات التشفير هي شكل خاص بالمجال من أشكال MD الذي يعزز التشفير تقنيات لخلق التوازنات المرغوبة داخل الأنظمة اللامركزية. تخلق الرشوة والتواطؤ تحديات كبيرة في جميع أنحاء مجال الطب. تتعطل جميع الآليات تقريبًا في ظل وجود التواطؤ، الذي يُعرف بأنه عقود جانبية.بين الأطراف المشاركة في الآلية [125، 130]. وتمثل الرشوة، حيث يقدم طرف خارجي حوافز جديدة إلى اللعبة، مشكلة أكثر صعوبة مما يفعله التواطؤ. يمكن النظر إلى التواطؤ على أنه حالة خاصة من الرشوة بين اللعبة المشاركين. غالبًا ما يمكن تصور أنظمة Blockchain على أنها ألعاب ذات عوائد نقدية (قائمة على العملات المشفرة). مثال بسيط هو تعدين إثبات العمل: يتمتع عمال المناجم بمساحة عمل حيث يمكنهم اختيار hashالمعدل الذي سيتم من خلاله تعدين الكتل. إن مكافأة التعدين هي مكافأة سلبية مضمونة (تكلفة الكهرباء والمعدات) بالإضافة إلى مؤشر ستوكاستيك مكافأة إيجابية (دعم التعدين) تعتمد على عدد عمال المناجم النشطين الآخرين [106، 172] ورسوم المعاملات. يعد التعهيد الجماعي oracles مثل SchellingCoin [68] مثالًا آخر: مساحة الإجراء هي مجموعة التقارير المحتملة التي قد يرسلها oracle، بينما الدفع هو المكافأة المحددة بواسطة آلية oracle، على سبيل المثال، قد يعتمد الدفع حول مدى قرب تقرير oracle من متوسط التقارير الأخرى [26، 68، 119، 185]. توفر ألعاب البلوكشين فرصًا ناضجة لهجمات التواطؤ والرشوة؛ في الواقع، يمكن لـ smart contracts تسهيل مثل هذه الهجمات [96، 165]. ولعل أشهرها هجوم الرشوة على التعهيد الجماعي oracles هو هجوم p-plus-epsilon [67]. هذا الهجوم ينشأ في سياق آلية شبيهة بـ SchellingCoin حيث يقدم اللاعبون تقارير ذات قيمة منطقية (أي كاذبة أو صحيحة) ويتم مكافأتهم بـ p إذا وافقوا على تقديم الأغلبية. في هجوم p-plus-epsilon، يعد المهاجم بمصداقية بما يلي: على سبيل المثال، ادفع للمستخدمين $p + ϵ مقابل التصويت الخاطئ إذا كان تقديم الأغلبية صحيحًا فقط. والنتيجة هي التوازن، حيث يتم تحفيز جميع اللاعبين على الإبلاغ عن الأخطاء بغض النظر عما يفعله اللاعبون الآخرون؛ وبالتالي يستطيع الراشي أن يحفز العقد من خلال رشوتها الموعودة للإبلاغ عن الكذب دون دفع الرشوة فعليًا (!). ومع ذلك، فإن استكشاف استراتيجيات الرشوة الأخرى في سياق oracles، وخاصة oracles التي لا يتم التعهيد الجماعي لها، اقتصر على خصومة ضعيفة إلى حد ما نماذج. على سبيل المثال، في إعداد إثبات العمل (PoW)، قام الباحثون بدراسة النتائج المشروطة الرشاوى، أي الرشاوى المدفوعة فقط إذا تمت مراقبة الرسالة المستهدفة بنجاح ولم يتم إخضاعها للرقابة تظهر في كتلة، بغض النظر عن تصرفات عامل التعدين الفردي [96، 165]. في هذه الحالة من oracles، ومع ذلك، بخلاف هجوم p-plus-epsilon، فنحن على علم فقط بالعمل في نموذج محدود للغاية من الرشوة حيث يرسل الراشي رشوة مشروطة ب تصرفات اللاعب الفردية، وليس على النتيجة الناتجة. نرسم هنا تصميمات لآليات استنباط المعلومات التي تظل حافزًا متوافق حتى في نموذج الخصم القوي، كما هو موضح في القسم الفرعي التالي. 9.3 افتراضات النمذجة في هذا القسم الفرعي، نوضح كيف نقوم بنمذجة سلوك وقدرات اللاعبين نظامنا، على وجه التحديد عقد المستوى الأول oracle، والعقد في المستوى الثاني (التحكيم) الطبقة، والأعداء.9.3.1 نموذج الحوافز من المستوى الأول: الجهات الفاعلة العقلانية تعتمد العديد من أنظمة blockchain للأمان على افتراض وجود عدد من الصدق العقد المشاركة. يتم تعريف العقد على أنها صادقة إذا اتبعت البروتوكول حتى عندما لا يكون من مصلحتهم المالية القيام بذلك. أنظمة إثبات العمل عادةً تتطلب أغلبية hash السلطة لتكون صادقة، وتتطلب أنظمة إثبات الملكية عادةً 2/3 أو أكثر من جميع الحصص المشاركة لتكون صادقة، وحتى أنظمة الطبقة الثانية مثل تتطلب Arbitrum [141] مشاركًا واحدًا صادقًا على الأقل. في نمذجة آلية staking، قمنا بوضع افتراض أضعف بكثير. (ليكون إن الافتراضات الواضحة والأضعف تعني خصائص أمنية أقوى وبالتالي فهي مفضلة.) نحن نفترض أن الخصم قد أفسد، أي الضوابط، بعض (الأقلية) جزء من عقد الطبقة الأولى oracle. نحن نصمم العقد المتبقية وليس كوكلاء صادقين، ولكن كمعظمات عقلانية متوقعة للمنفعة. تعمل هذه العقد بالكامل وفقًا لحوافز مالية ذاتية، وتختار الإجراءات التي تؤدي إلى مكاسب مالية متوقعة كسب. على سبيل المثال، إذا عُرضت على العقدة رشوة أكبر من المكافأة الناتجة عنها السلوك الصادق، فإنه سيقبل الرشوة. ملاحظة على العقد الخصومة: وفقا لنموذج الثقة المشترك ل الأنظمة اللامركزية، نفترض أن جميع العقد عقلانية، أي تسعى إلى تعظيمها صافي الإيرادات، بدلاً من السيطرة عليها من قبل خصم خبيث. مطالباتنا، ومع ذلك - التأثير الخطي الفائق أو التربيعي staking على وجه التحديد - يتم توفيره بشكل مقارب أن مجموعة العقد التي يتم التحكم فيها بشكل عدائي تكون على الأكثر (1/2 -c)n، بالنسبة للبعض إيجابية ثابت ج. 9.3.2 نموذج التحكيم من المستوى الثاني: الصحة بالافتراض تذكر أن إحدى الميزات المهمة لآلية staking التي تساعد في تحقيق الأمان ضد العقد العقلانية هو نظام الطبقة الثانية. في آلية staking المقترحة، فإن أي oracle قد يثير تنبيهًا يشير إلى ذلك تعتقد أن مخرجات الآلية غير صحيحة. يؤدي التنبيه إلى درجة عالية من الثقة تفعيل نظام المستوى الثاني والإبلاغ عن النتيجة الصحيحة. وبالتالي، النمذجة الرئيسية الشرط لنهجنا هو الحكم الصحيح، أي الإبلاغ الصحيح من قبل نظام الدرجة الثانية. يفترض نموذج staking الخاص بنا نظامًا من المستوى الثاني يعمل كمصدر للحقيقة غير قابل للفساد وموثوق به إلى أقصى حد. ومن المرجح أن يكون مثل هذا النظام مكلفًا وبطيئًا، وبالتالي غير مناسب للاستخدام في الحالة النموذجية. ولكن في حالة التوازن، أي متى إذا كان نظام المستوى الأول يعمل بشكل صحيح، فلن يتم استدعاء نظام المستوى الثاني. وبدلاً من ذلك، فإن وجوده يعزز أمان نظام oracle بالكامل من خلال توفير ملف مساندة عالية الضمان. إن استخدام طبقة تحكيم عالية الثقة وعالية التكلفة يشبه عملية الاستئناف في قلب معظم الأنظمة القضائية. كما أنه شائع بالفعل في تصميم oracle النظم، على سبيل المثال، [119، 185]. نحن نناقش بإيجاز طرق تحقيق المستوى الثاني في آليتنا في القسم 9.4.3.يستخدم بروتوكول staking الخاص بنا الفصل الصحيح المفترض لنظام المستوى الثاني كتهديد موثوق به لفرض الإبلاغ الصحيح بواسطة العقد oracle. البروتوكول يصادر جزءًا أو كلًا من حصة oracle العقد التي تولد التقارير المحددة بواسطة نظام الطبقة الثانية غير صحيح. وبالتالي يتم ردع عقد أوراكل عن سوء التصرف بالعقوبة المالية الناتجة. يشبه هذا الأسلوب في النكهة ما تم استخدامه في متفائل rollups، على سبيل المثال، [141، 10]. 9.3.3 نموذج عدائي تم تصميم آليتنا staking للحصول على معلومات صادقة مع تحقيق الأمان ضد فئة واسعة ومحددة جيدًا من الخصوم. ويحسن من الأعمال السابقة، والتي إما تتجاهل نموذجًا عدائيًا صريحًا أو تركز على فئات فرعية ضيقة من الخصوم، على سبيل المثال، خصم p-plus-epsilon الذي تمت مناقشته أعلاه. هدفنا هو تصميم staking آلية ذات أمان مثبت رسميًا ضد مجموعة كاملة من الخصوم المحتملين التي يجب مواجهتها في الممارسة العملية. نحن نمثل خصمنا على أنه يمتلك ميزانية ثابتة (قابلة للقياس)، يُشار إليها بـ $ ب. يمكن للخصم التواصل بشكل فردي وسري مع كل oracle في الشبكة، ويمكن أن يعرض سرًا على أي فرد oracle دفع رشوة مضمونة ويتوقف ذلك على النتائج العامة التي يمكن ملاحظتها للآلية. تحديد النتائج يمكن أن تشمل الرشاوى، على سبيل المثال، القيمة التي تم الإبلاغ عنها بواسطة oracle، وأي رسائل عامة يتم إرسالها بواسطة أي oracle إلى الآلية (على سبيل المثال، تنبيه)، والقيم التي تم الإبلاغ عنها من قبل الآخرين oracles، والقيمة الناتجة عن الآلية. لا توجد آلية يمكنها الحماية ضد مهاجم بقدرات غير محدودة. ولذلك فإننا نعتبر بعض السلوكيات غير واقعية أو خارجة عن النطاق. نحن نفترض مهاجمنا لا يمكنه كسر أساسيات التشفير القياسية، وكما هو مذكور أعلاه، لديه علامة ثابتة (if يحتمل أن تكون كبيرة) الميزانية $B. ونفترض كذلك أن الخصم لا يسيطر الاتصال في شبكة oracle، خاصة أنه لا يمكن تأخيره بشكل كبير حركة المرور بين عقد الطبقة الأولى و/أو عقد الطبقة الثانية. (إن قدرة الخصم على مراقبة مثل هذا التواصل تعتمد على الآلية المحددة، كما سنوضح أدناه). ولكن بشكل غير رسمي، كما ذكرنا أعلاه، نفترض أن الخصم يمكنه: (1) الفساد جزء من oracle العقد ((1/2 −c)- جزء لبعض الثابت c)، أي التحكم الكامل لهم، و(2) تقديم الرشاوى إلى أي عقد مرغوبة، مع ضمان الدفع المشروط على النتائج التي يحددها الخصم، كما هو موضح أعلاه. بينما لا نقدم نموذجًا رسميًا أو تصنيفًا كاملاً للخصم نطاق إمكانيات الرشوة في هذا المستند التقني، فيما يلي أمثلة على هذه الأنواع الرشاوى التي يشملها نموذجنا. للتبسيط، نفترض أن oracles يصدر قيمة منطقية التقارير التي تكون قيمتها الصحيحة (w.l.o.g) صحيحة، ويتم حساب النتيجة النهائية على أنها سيتم استخدام إجمالي هذه التقارير بواسطة smart contract المستهلك. الراشي الهدف هو أن تكون النتيجة النهائية غير صحيحة، أي كاذبة. • الرشوة غير المشروطة: يقدم مقدم الرشوة رشوة بقيمة $b لأي oracle يقدم تقريرًا كاذبًا. • مقدم الرشوة الاحتمالي: يقدم مقدم الرشوة رشوة $b مع بعض الاحتمالية q إلى أي oracle أن تقارير كاذبة.• رشوة مشروطة بنتيجة كاذبة: يقدم مقدم الرشوة رشوة $b لأي oracle يبلغ عن خطأ بشرط أن تكون النتيجة النهائية خاطئة. • مقدم رشوة مشروط بعدم التنبيه: يعرض مقدم الرشوة مبلغ $b على أي oracle يقوم بالإبلاغ كاذبة طالما لم يتم رفع أي تنبيه. • p-plus-epsilon Briber: يقدم مقدم الرشوة رشوة $b لأي oracle يبلغ عن خطأ باسم طالما أن غالبية oracles لم يبلغوا عن خطأ. • مقدم الرشوة المحتمل: يقدم مقدم الرشوة مبلغ $b مقدمًا لأي جهة تم تحديدها oracle لدور عشوائي وتقارير كاذبة. في بروتوكولنا staking المقترح، كل شيء تعمل العقد كهيئات رقابة محتملة، ونحن قادرون على إظهار هذا التوزيع العشوائي من أولويات الوكالة الرقابية لا تصلح للرشوة المحتملة. العديد من أعمال إثبات العمل، proof-of-stake، والأنظمة المرخصة عرضة للاحتمالات ولكن الرشوة مما يدل على أهمية أخذها في الاعتبار في خصومنا النموذج والتأكد من أن بروتوكولات staking لدينا مرنة تجاهه. انظر الملحق ه لمزيد من التفاصيل. 9.3.4 ما مقدار الأمن الاقتصادي المشفر الكافي؟ لن ينفق الخصم العقلاني الأموال لمهاجمة النظام إلا إذا كان بإمكانه الحصول على الربح أكبر من نفقاتها. وهكذا بالنسبة لنموذجنا العدائي والمقترح staking في هذه الآلية، قد يُنظر إلى $B على أنه مقياس للربح المحتمل الذي يمكن أن يحققه الخصم للاستخراج من الاعتماد على smart contracts عن طريق إتلاف شبكة oracle والتسبب في ذلك لإنشاء تقرير أو مجموعة تقارير غير صحيحة. في تحديد ما إذا كانت شبكة oracle توفر درجة كافية من الأمان الاقتصادي المشفر لأغراضها، كما ينبغي للمستخدم تقييم الشبكة من هذا المنظور. بالنسبة للخصوم المحتملين في الإعدادات العملية، نتوقع أن يكون $B بشكل عام أصغر بكثير من إجمالي الأصول في الاعتماد على smart contracts. في معظم الحالات، فإنه من غير الممكن للخصم أن ينتزع هذه الأصول في مجملها. 9.4 آلية التوقيع المساحي: رسم نقدم هنا الأفكار الرئيسية والهيكل العام لآلية staking التي نقوم بها تدرس حاليا. لسهولة العرض، وصفنا بسيطة ولكنها بطيئة (متعدد الجولة) البروتوكول في هذا القسم الفرعي. ومع ذلك، نلاحظ أن هذا المخطط تماما عملي. ونظرًا للضمانات الاقتصادية التي توفرها الآلية، أي المعاقبة والحوافز اللاحقة ضد العقد المعيبة، فقد يكون العديد من المستخدمين على استعداد لـ قبول التقارير بتفاؤل. بمعنى آخر، قد يقبل هؤلاء المستخدمون التقارير قبل ذلك حكم محتمل من الدرجة الثانية. يمكن للمستخدمين غير الراغبين في قبول التقارير بتفاؤل أن يختاروا الانتظار حتى البروتوكول وينتهي التنفيذ، أي حتى يحدث أي تصعيد محتمل إلى المستوى الثاني. هذا، ومع ذلك، يمكن أن يؤدي ذلك إلى إبطاء وقت تأكيد التقارير بشكل كبير. لذلك نحن باختصارالشكل 15: رسم تخطيطي لنظام staking مع التنبيه. في هذا المثال، 1⃝أغلبية من العقد تالفة/مرشوشة وتصدر قيمة غير صحيحة ˜r، بدلاً من القيمة الصحيحة قيمة التقرير ص. تقوم عقدة المراقبة 2⃝ بإرسال تنبيه إلى لجنة المستوى الثاني، الذي يحدد ويصدر قيمة التقرير الصحيحة r، مما يؤدي إلى تلف العقد مصادرة ودائعهم — كل $d إلى عقدة المراقبة 4⃝. حدد بعض التحسينات التي تؤدي إلى سرعة (جولة واحدة) إذا كانت أكثر إلى حد ما التصميم المعقد في القسم 9.5. تذكر أن الطبقة الأولى في آليتنا staking تتكون من oracle الأساسية الشبكة نفسها. الهيكل الرئيسي لآليتنا، كما هو موضح أعلاه، هو أنه في كل جولة، يمكن لكل عقدة أن تعمل بمثابة "المراقبة" مع بعض الأولوية، وبالتالي لديها القدرة على القيام بذلك قم بإطلاق تنبيه إذا وصلت الآلية إلى مخرج غير صحيح، بدلاً من الصحيح ص واحد. يؤدي هذا التنبيه إلى دقة المستوى الثاني، والتي نفترض أنها تصل إلى الحل الصحيح تقرير. تتم معاقبة العقد التي تحتوي على تقارير غير صحيحة، بمعنى أن مخاطرها قطعت ومنحتها لهيئات المراقبة. هذه البنية الأساسية شائعة في أنظمة oracle، كما في مثلا [119، 185]. الابتكار الرئيسي في تصميمنا، المذكور بإيجاز أعلاه، هو أن كل عقدة أعطيت أولوية مميزة في ترتيب هيئات المراقبة المحتملة. وهذا هو، المراقبين يتم منح فرص للتنبيه في تسلسل الأولوية. تذكر أنه إذا كانت العقدة تحتوي على الأولوية القصوى لرفع التنبيه، فإنه يتلقى الوديعة المقطوعة $d لكل سوء تصرف العقدة، بإجمالي أكثر من \(dn/2 = \)d × n/2، حيث يشير التقرير غير الصحيح إلى غالبية العقد السيئة. وبالتالي، يجب على الخصم أن يدفع هذه المكافأة على الأقل رشوة عقدة تعسفية. وبالتالي، لرشوة غالبية العقد، يجب على الخصم أن يدفع أ رشوة كبيرة لغالبية العقد، أي أكثر من $dn2/2. نعرض بشكل تخطيطي كيفية عمل التنبيه وتصعيد المراقبة في الشكل 15.9.4.1 مزيد من تفاصيل الآلية إن نظام مقاومة الرشوة الذي نصفه الآن بمزيد من التفصيل هو رسم مبسط لـ البناء ذو المستويين الذي نعتزم بناءه. سيكون معظم تركيزنا على الوصف شبكة المستوى الأول (من الآن فصاعدا ببساطة "الشبكة" حيث يكون ذلك واضحا من السياق) جنبا إلى جنب مع آلية الحوافز وإجراءات التصعيد إلى المستوى الثاني. خذ بعين الاعتبار شبكة Chainlink مكونة من عدد oracle من العقد المسؤولة عن يتم الإبلاغ بانتظام (على سبيل المثال، مرة واحدة في الدقيقة) عن قيمة منطقية (على سبيل المثال، ما إذا كان السوق القيمة السوقية لـ BTC تتجاوز قيمة ETH). كجزء من آلية staking، العقد يجب تقديم وديعتين: وديعة $d قابلة للقطع في حالة الخلاف مع إيداع الأغلبية والمراقبة $dw الخاضع للتخفيض في حالة حدوث خلل التصعيد. نحن نفترض أن العقد لا يمكنها نسخ إرسالات العقد الأخرى، على سبيل المثال، من خلال مخطط الالتزام والكشف كما تمت مناقشته في القسم 5.3. في كل جولة، العقد أولاً الالتزام بتقريرهم، وبمجرد التزام جميع العقد (أو انتهاء المهلة)، العقد تكشف تقاريرها. بالنسبة لكل تقرير يتم إنشاؤه، يتم منح كل عقدة أيضًا أولوية مراقبة بين 1 وn يتم اختيارها عشوائيًا، مع كون 1 أولوية قصوى. هذه الأولوية تمكن تركيز المكافأة في يد جهة رقابية واحدة. بعد أن أصبحت جميع التقارير علنية، وتتبع ذلك مرحلة تنبيه. على مدى سلسلة من جولات n (متزامنة)، العقدة مع الأولوية لدي الفرصة للتنبيه في الجولة الأولى. دعونا نفكر في النتائج المحتملة للآلية بعد الكشف عن العقد تقاريرهم. مرة أخرى بافتراض وجود تقرير ثنائي، لنفترض أن القيمة الصحيحة صحيحة و الخطأ هو كاذب. لنفترض أيضًا أن آلية المستوى الأول تقوم بإخراج إخراج قيمة الأغلبية بواسطة العقد كالتقرير النهائي r. هناك ثلاث نتائج محتملة في الآلية: • اتفاق كامل: في أفضل الأحوال، تكون العقد في اتفاق كامل: جميع العقد متوفرة وقدمت تقريرًا في الوقت المناسب بنفس القيمة r (إما صحيحًا أو كاذبة). في هذه الحالة، تحتاج الشبكة فقط إلى إعادة توجيه العقود المعتمدة ومكافأة كل عقدة بدفعة ثابتة لكل جولة $p، وهي أصغر بكثير من $د. • اتفاق جزئي: من الممكن أن تكون بعض العقد غير متصلة بالإنترنت أو أن هناك خلافًا حول القيمة الصحيحة، ولكن معظم العقد تفيد بأنها صحيحة وفقط تقارير الأقلية كاذبة. هذه الحالة واضحة أيضًا. قيمة الأغلبية (صحيح) يتم حسابها، مما يؤدي إلى تقرير صحيح ص. جميع العقد التي ذكرت r هي تمت مكافأتهم بـ $p بينما oracles الذين أبلغوا بشكل غير صحيح لديهم ودائعهم تم تخفيضها بشكل متواضع، على سبيل المثال، بمقدار 10 بنس. • تنبيه: في حالة اعتقاد جهة المراقبة أن مخرجات الشبكة غير صحيحة، فهو يطلق تنبيهًا علنيًا، مما يؤدي إلى تصعيد الآلية إلى شبكة المستوى الثاني. ثم هناك نتيجتان محتملتان: - التنبيه الصحيح: إذا أكدت شبكة المستوى الثاني أن إخراجالشكل 16: تضخيم تكلفة الرشوة من خلال مكافآت التنبيه المركزة. رشوة يجب على الخصم رشوة كل عقدة بأكثر من المكافأة التي يمكنها الحصول عليها من خلال التنبيه (يظهر كشريط أحمر). إذا تمت مشاركة مكافآت التنبيه، فقد تكون هذه المكافأة نسبيًا صغير. تعمل مكافآت التنبيه المركزة على زيادة المكافأة التي قد تحصل عليها أي عقدة واحدة الحصول على (شريط أحمر طويل القامة). ومن ثم فإن المبلغ الإجمالي الذي يدفعه الخصم مقابل رشوة قابلة للتطبيق (المناطق الرمادية) أكبر بكثير وتحتوي على مكافآت تنبيه مركزة أكثر من المشتركة. كانت شبكة المستوى الأول غير صحيحة، وتتلقى عقدة المراقبة التنبيهية مكافأة تتكون من جميع الودائع المقطوعة، وبالتالي أكثر من $dn/2. – تنبيه خاطئ: إذا وافق المستوى الثاني والمستوى الأول oracles، فسيتم التصعيد تعتبر معيبة وتفقد عقدة التنبيه إيداعها $dw. في حالة القبول المتفائل للتقارير، لا تسبب تنبيهات المراقبة أي تغيير في تنفيذ عقود الاعتماد. للعقود المصممة للانتظار التحكيم المحتمل من قبل لجنة المستوى الثاني، تنبيهات الوكالة الرقابية تأخير ولكن لا تجميد تنفيذ العقد. من الممكن أيضًا أن تحدد العقود أ تجاوز الفشل DON لفترات الفصل في الأحكام. 9.4.2 تأثير التوقيع المساحي التربيعي قدرة كل عقدة على العمل كجهة رقابية، بالإضافة إلى أولوية العقدة الصارمة ضمان المكافآت المركزة، يمكّن الآلية من تحقيق المعادلة التربيعية staking تأثير كل نوع من مهاجمي الرشوة الموصوفين في القسم 9.3.3. أذكر أن هذا يعني على وجه التحديد في إعدادنا أنه بالنسبة لشبكة تحتوي على عدد n من العقد لكل منها إيداع $d، يجب أن يكون لدى الراشي الناجح (من أي من الأنواع المذكورة أعلاه) ميزانية أكبر من $dn2/2. على وجه الدقة، يجب على الراشي أن يفسد ما لا يقل عن (n+1)/2 عقدة، حيث يجب على الراشي أن يفسد إفساد غالبية العقد n (بالنسبة إلى n الفردية، حسب الافتراض). وهكذا تقف جهة المراقبة احصل على مكافأة قدرها $d(n + 1)/2. وبالتالي يجب على الراشي أن يدفع هذا المبلغ لكل شخصعقدة للتأكد من أن لا أحد يعمل كرقيب. نحن نعمل على إظهار ذلك رسميًا إذا يمتلك مقدم الرشوة ميزانية قدرها $d(n2 + n)/2 على الأكثر، ومن ثم تحقق التوازن المثالي للعبة الفرعية للعبة بين المرتشيين وoracle، وبعبارة أخرى، التوازن عند أي نقطة أثناء ممارسة اللعبة — هي ألا يقوم الراشي بإصدار الرشوة و كل oracle للإبلاغ عن قيمه الحقيقية بأمانة. لقد أوضحنا أعلاه كيف أنه من الممكن أن يطلب الراشي الناجح الحصول على الميزانية أكبر بكثير من مجموع ودائع العقدة. لتوضيح هذا نتيجة بديهية، يوضح الشكل 16 تأثير مكافآت التنبيه المركزة بيانياً. كما نرى هناك، إذا كانت مكافأة الوكالة الرقابية على التنبيه — وهي ودائع الرشوة العقد التي أبلغت عن خطأ) - تم تقسيمها بين جميع التنبيهات المحتملة، المبلغ الإجمالي لذلك أي عقدة تنبيه فردية يمكن أن تتوقعها ستكون صغيرة نسبيًا، حسب ترتيب $د. يمكن أن يستخدمه الراشي، وهو يعلم أن دفع تعويضات أكبر من $d أمر غير محتمل رشوة مشروطة ذات نتيجة كاذبة لرشوة كل من العقد n بأكثر قليلاً من $ د + ϵ. وعلى عكس ما هو متوقع، يوضح الشكل 16 أن النظام يقوم بتوزيع المكافأة على نطاق واسع بين العقد التي تشير إلى التنبيه أضعف بكثير من تلك التي تركز المكافأة فيها أيدي رقيب واحد. معلمات المثال: خذ بعين الاعتبار شبكة (من المستوى الأول) تحتوي كل منها على عدد = 100 عقدة إيداع \(d = \)20K. سيكون لهذه الشبكة ما مجموعه 2 مليون دولار مودعة ولكنها ستفعل ذلك كن محميًا ضد الراشي بميزانية \(100M = \)dn2/2. زيادة عدد oracles أكثر فعالية من زيادة $d، بالطبع، ويمكن أن يكون لها تأثير كبير: سيتم حماية الشبكة التي تحتوي على n = 300 عقدة وودائع \(d = \)20K ضد رشوة بميزانية تصل إلى 900 مليون دولار. لاحظ أن نظام staking يمكنه في كثير من الحالات حماية smart contracts التي تمثل قيمة أكبر من المستوى المعروض للحماية من الرشوة. وذلك لأن الخصم فمهاجمة هذه العقود لا يمكنها انتزاع القيمة الكاملة في كثير من الحالات. على سبيل المثال، أ Chainlink قد يتطلب العقد المدعوم بقيمة 1 مليار دولار ضمانًا فقط مقابل أ رشوة بموارد تبلغ 100 مليون دولار لأن مثل هذا الخصم يمكنه استخلاص الربح بشكل عملي 10% فقط من قيمة العقد. ملحوظة: يتم التعبير عن فكرة أن قيمة الشبكة يمكن أن تنمو بشكل تربيعي قانون ميتكالف المعروف [167، 235]، والذي ينص على أن قيمة الشبكة ينمو بشكل تربيعي في عدد الكيانات المتصلة. لكن قانون ميتكالف تنشأ من النمو في عدد اتصالات الشبكة الزوجية المحتملة، وهي ظاهرة مختلفة عن التأثير التربيعي الأساسي staking في حافزنا آلية. 9.4.3 تحقيق الطبقة الثانية هناك ميزتان تشغيليتان تسهلان تحقيق مستوى ثانٍ عالي الموثوقية: (1) يجب أن يكون التحكيم من المستوى الثاني حدثًا نادرًا في شبكات oracle وبالتالي يمكن ذلك تكون أكثر تكلفة بكثير من التشغيل العادي للطبقة الأولى و(2) بافتراضالتقارير المقبولة بتفاؤل – أو العقود التي يمكن أن ينتظر تنفيذها التحكيم – لا يلزم تنفيذ المستوى الثاني في الوقت الفعلي. هذه الميزات تؤدي إلى مجموعة من خيارات التكوين للطبقة الثانية لتلبية متطلبات DONs معينة. وكمثال على ذلك، يمكن أن تتكون لجنة المستوى الثاني من العقد التي يختارها أ DON (أي الطبقة الأولى) من العقد الأطول خدمة والأكثر موثوقية في Chainlink شبكة. بالإضافة إلى الخبرة التشغيلية الكبيرة ذات الصلة، فإن المشغلين من هذه العقد لديها حافز ضمني كبير في FFO الذي يحفز الرغبة للتأكد من أن شبكة Chainlink تظل موثوقة للغاية. لديهم أيضا علنا سجلات الأداء المتاحة التي توفر الشفافية في موثوقيتها. تجدر الإشارة إلى أن عقد المستوى الثاني لا تحتاج إلى أن تكون مشاركين في شبكة المستوى الأول، و قد يفصل في الأخطاء عبر شبكات متعددة من الدرجة الأولى. يمكن للعقد الموجودة في DON أن تحدد مسبقًا وتلتزم علنًا بمجموعة من هذه العناصر العقد باعتبارها تشكل لجنة المستوى الثاني لذلك DON. بالإضافة إلى ذلك، DON تنشر العقد المعلمة k ′ ≥n ′ التي تحدد عدد أصوات الطبقة الثانية مطلوب لمعاقبة عقدة من الدرجة الأولى. عندما يتم إنشاء تنبيه لتقرير معين، يصوت أعضاء الطبقة الثانية على صحة القيم المقدمة من كل منهم من عقد الطبقة الأولى. أي عقدة من الدرجة الأولى تحصل على أصوات سلبية k′ ستفقد حقها الودائع إلى عقدة المراقبة. بسبب ندرة إصدار الأحكام وفرصة التنفيذ لمدة طويلة المذكورة أعلاه، وعلى النقيض من الطبقة الأولى، يمكن للعقد في الطبقة الثانية: 1. أن يحصل على أجر كبير مقابل إجراء التحكيم. 2. اعتمد على مصادر بيانات إضافية، تتجاوز حتى المجموعة المتنوعة التي يستخدمها المستوى الأول. 3. الاعتماد على التفتيش والتدخل اليدوي و/أو الخبراء، على سبيل المثال، لتحديد و التوفيق بين الأخطاء في بيانات المصدر والتمييز بين ترحيل العقدة الصادق بيانات خاطئة وعقدة تتصرف بشكل غير صحيح. نؤكد على أن النهج الذي وصفناه للتو لاختيار العقد من الدرجة الثانية والفصل في السياسات التي تحكم السياسة لا يمثل سوى نقطة ضمن نطاق كبير مساحة التصميم للإنجازات المحتملة للطبقة الثانية. تقدم آلية الحوافز لدينا المرونة الكاملة فيما يتعلق بكيفية تحقيق المستوى الثاني. يمكن للأفراد DONs القيام بذلك تشكل وتضع قواعد للمستويات الثانية التي تلبي المتطلبات الخاصة وتوقعات العقد والمستخدمين المشاركين. DECO وTown Crier كأدوات تحكيمية: إنه ضروري للطبقة الثانية في آليتنا لنكون قادرين على التمييز بين عقد الطبقة الأولى المتعارضة إنتاج تقارير غير صحيحة عن عمد وعقد من الدرجة الأولى صادقة عن غير قصد ترحيل البيانات غير الصحيحة في المصدر. عندها فقط يمكن تنفيذ المستوى الثاني القطع لتثبيط الغش، هو هدف آليتنا. ديكو وتاون كريير هي أدوات قوية يمكنها تمكين العقد من المستوى الثاني من تحقيق هذا التمييز الحاسم بشكل موثوق.قد تتمكن عقد الطبقة الثانية في بعض الحالات من الاستعلام مباشرة عن مصدر البيانات المستخدم بواسطة عقدة من الدرجة الأولى أو استخدم قسم ADO 7.1 للتحقق مما إذا كان التقرير غير صحيح نتجت عن مصدر بيانات خاطئ. ومع ذلك، في حالات أخرى، قد لا توجد عقد من المستوى الثاني الوصول المباشر إلى مصدر بيانات عقدة الطبقة الأولى. وفي مثل هذه الحالات يكون الحكم الصحيح تبدو غير ممكنة أو تتطلب الاعتماد على حكم شخصي. السابق oracle وقد اعتمدت أنظمة حل النزاعات على جولات تصويت متصاعدة وغير فعالة لمعالجة هذه المشكلة التحديات. ومع ذلك، باستخدام DECO أو Town Crier، يمكن لعقدة المستوى الأول أن تثبت السلوك الصحيح إلى عقد الطبقة الثانية. (انظر القسم 3.6.2 للحصول على تفاصيل حول النظامين.) على وجه التحديد، إذا تحدد عقدة المستوى الثاني عقدة المستوى الأول على أنها قامت بإخراج قيمة تقرير خاطئة ˜r، يمكن لعقدة المستوى الأول استخدام DECO أو Town Crier لإنشاء دليل مضاد للتلاعب عقد الطبقة الثانية التي تقوم بنقلها بشكل صحيح من مصدر (ممكّن لـ TLS). معترف بها على أنها موثوقة بواسطة DON. والأهم من ذلك أن عقدة المستوى الأول يمكنها القيام بذلك دون عقد من المستوى الثاني تتطلب الوصول المباشر إلى مصدر البيانات.17 وبالتالي، من الممكن إصدار قرار صحيح في Chainlink لأي مصدر بيانات مرغوب فيه. 9.4.4 الإبلاغ الخاطئ عن التأمين إن المقاومة القوية للرشوة التي حققتها آلية staking تعتمد بشكل أساسي على الأموال المقطوعة الممنوحة للمنبهين. وبدون مكافأة مالية، فإن التنبيهات سوف تفعل ذلك ليس لديهم حافز مباشر لرفض الرشاوى. ونتيجة لذلك، فإن الأموال المقطوعة ليست كذلك متاحة لتعويض المستخدمين المتضررين من التقارير غير الصحيحة، على سبيل المثال، المستخدمين الذين يخسرون أموالاً عندما يتم ترحيل بيانات السعر غير الصحيحة إلى smart contract. من المفترض أن التقارير غير الصحيحة لا تشكل مشكلة إذا تم قبول التقارير من قبل أ العقد فقط بعد صدور حكم محتمل، أي الإجراء الذي يتخذه المستوى الثاني. كما هو موضح أعلاه، على الرغم من ذلك، لتحقيق أفضل أداء ممكن، قد تعتمد العقود بدلاً من ذلك متفائلون بآلية فرض الإبلاغ الصحيح، أي أنهم يقبلون التقارير قبل الفصل المحتمل من الدرجة الثانية. في الواقع، مثل هذا السلوك المتفائل هو آمن في نموذجنا بافتراض وجود خصوم عقلانيين لا تتجاوز ميزانياتهم staking تأثير الآلية. المستخدمون يشعرون بالقلق إزاء الحدث غير المحتمل لفشل الآلية الناتج عن، على سبيل المثال، قد يرغب الخصوم الذين لديهم موارد مالية هائلة في استخدام طبقة إضافية من الأمن الاقتصادي في شكل الإبلاغ الخاطئ عن التأمين. نحن نعرف وتعتزم العديد من شركات التأمين بالفعل تقديم وثائق تأمين مدعومة بعقود ذكية من هذا النوع لـ Chainlink-البروتوكولات الآمنة في المستقبل القريب، بما في ذلك من خلال آليات مبتكرة مثل DAOs، على سبيل المثال، [7]. وجود سجل الأداء لـ Chainlink توفر العقد والبيانات الأخرى حول العقد، مثل مبالغ حصصها، أساسًا قويًا بشكل استثنائي للتقييمات الاكتوارية للمخاطر، مما يجعل من الممكن سياسات التسعير بطرق غير مكلفة لحاملي وثائق التأمين ولكنها مستدامة بالنسبة لشركات التأمين. 17 باستخدام Town Crier، من الممكن أيضًا لعقد المستوى الأول إنشاء الشهادات محليًا من صحة التقارير التي يصدرونها ويقدمون هذه الشهادات إلى العقد من المستوى الثاني على أساس حسب الحاجة.يمكن تنفيذ الأشكال الأساسية لتأمين الإبلاغ الخاطئ بطريقة جديرة بالثقة بطريقة فعالة باستخدام smart contracts. كمثال بسيط، التأمين البارامترى يمكن لعقود SCins تعويض حاملي وثائق التأمين تلقائيًا إذا كانت آلية الحوافز لدينا يحدد المستوى الثاني خطأً في التقرير الذي تم إنشاؤه في المستوى الأول. المستخدم U الذي يرغب في شراء بوليصة تأمين، على سبيل المثال، منشئ الهدف يمكن للعقد SC، تقديم طلب إلى شركة تأمين لامركزية للحصول على مبلغ السياسة مليون دولار على العقد. عند الموافقة على U، يمكن لشركة التأمين تعيين مبلغ مستمر (على سبيل المثال، شهري) علاوة $P في SCins. بينما تدفع U القسط، تظل سياستها نشطة. في حالة حدوث فشل في الإبلاغ في SC، ستكون النتيجة انبعاث زوج (r1، r2) التقارير المتضاربة لـ SC، حيث يتم توقيع r1 بواسطة المستوى الأول في آليتنا و r2، التقرير المصحح المقابل، موقع من قبل الطبقة الثانية. إذا قدمت U مثل هذا الزوج الصالح (r1، r2) إلى SCins، يدفع لها العقد تلقائيًا مليون دولار، بشرط مدفوعات أقساطها محدثة. 9.5 البديل جولة واحدة يتطلب البروتوكول الموصوف في القسم الفرعي السابق أن تنتظر لجنة المستوى الثاني عددًا من الجولات لتحديد ما إذا كانت هيئة المراقبة قد أطلقت تنبيهًا أم لا. هذا ويظل هذا المتطلب قائمًا حتى في الحالة المتفائلة، أي عندما يعمل المستوى الأول بشكل صحيح. للمستخدمين غير الراغبين في قبول التقارير بتفاؤل، أي قبل الإمكانات الحكم، فإن التأخير المرتبط بهذا النهج سيكون غير عملي. ولهذا السبب، فإننا نستكشف أيضًا بروتوكولات بديلة تتطلب بروتوكولًا واحدًا فقط جولة. في هذا الأسلوب، ترسل كافة العقد oracle بتات سرية تشير إلى ما إذا كان سيتم ذلك أم لا يرغبون في رفع مستوى التنبيه. ثم تقوم لجنة المستوى الثاني بالتحقق من هذه القيم ترتيب الأولوية. لتقديم رسم تقريبي، قد يتضمن هذا المخطط ما يلي الخطوات: 1. تقديم بتات الوكالة الدولية للطاقة: تشترك كل عقدة سرية في Oi في قيمة مراقبة مكونة من بتة واحدة wi ∈{no تنبيه، تنبيه} بين العقد في المستوى الثاني لكل تقرير ينشئه. 2. نصائح مجهولة المصدر: يمكن لأي عقدة oracle تقديم نصيحة مجهولة المصدر α إلى لجنة المستوى الثاني في نفس الجولة التي يتم فيها تقديم بتات المراقبة. هذه النصيحة α هي رسالة تشير إلى أنه قد تم رفع تنبيه للتقرير الحالي. 3. فحص بتات الوكالة الدولية للطاقة: تكشف لجنة المستوى الثاني عن هيئة مراقبة العقد oracle البتات حسب الأولوية. لاحظ أن العقد يجب ألا ترسل أي بتات رقابية للتنبيه عندما لا تنبه: وإلا فإن تحليل حركة المرور يكشف عن بتات جميع العقد. يكشف البروتوكول عن حالة عدم التنبيه بتات الوكالة الرقابية للعقد ذات أولوية أعلى من الوكالة الرقابية للتنبيه ذات الأولوية القصوى. لاحظ أن ما تم الكشف عنه مطابق لما ورد في بروتوكول n-round الخاص بنا. يتم أيضًا توزيع المكافآت بشكل مماثل لهذا المخطط، أي أول جهة رقابية يتم تحديدها يتلقى الودائع المقطوعة للعقد التي قدمت تقارير غير صحيحة.إن استخدام النصائح مجهولة المصدر يمكّن لجنة المستوى الثاني من البقاء غير تفاعلية في الحالات التي لم يتم فيها رفع أي تنبيه، مما يقلل من تعقيد الاتصال في الحالة المشتركة. لاحظ أن أي جهة رقابية ترفع تنبيهًا لديها حافز اقتصادي لتقديم نصيحة مجهولة المصدر: إذا لم يتم تقديم أي نصيحة، فلن يتم دفع أي مكافأة لأي شخص عقدة. للتأكد من أنه لا يمكن التعرف على المرسل Oi للطرف المجهول α بواسطة الخصم بناءً على بيانات الشبكة، يمكن إرسال معلومات مجهولة المصدر عبر مجهول القناة، على سبيل المثال، عبر Tor، أو، بشكل أكثر عملية، وكيل عبر مزود خدمة سحابية. ل مصادقة الطرف على أنه نشأ بـ O، يمكن لـ Oi التوقيع على α باستخدام التوقيع الدائري [39، 192]. وبدلاً من ذلك، لمنع هجمات رفض الخدمة غير المنسوبة ضد لجنة المستوى الثاني بواسطة عقدة oracle ضارة، يمكن أن تكون α بيانات اعتماد مجهولة مع عدم الكشف عن هويته القابلة للإلغاء [73]. ورغم أن هذا البروتوكول قابل للتحقيق عمليا، إلا أنه يتمتع بهندسة ثقيلة الوزن إلى حد ما المتطلبات (التي نستكشف طرقًا لتقليلها). العقد من الدرجة الأولى، على سبيل المثال، يجب أن تتواصل مباشرة مع عقد المستوى الثاني، مما يتطلب صيانة الدليل. تضيف الحاجة إلى قنوات مجهولة وتوقيعات حلقية إلى الهندسة تعقيد المخطط. وأخيرًا، هناك متطلب ثقة خاص تمت مناقشته بإيجاز في المذكرة أدناه. ولذلك فإننا نستكشف أيضًا مخططات أبسط لا تزال تحقق النجاح تأثير خطي فائق staking، ولكن ربما أقل من تأثير تربيعي، حيث يحتاج مقدم الرشوة بشكل غير مقارب إلى موارد لا تقل عن $n log n، على سبيل المثال. بعض المخططات تحت يتضمن الاعتبار اختيارًا عشوائيًا لمجموعة فرعية صارمة من العقد لتكون بمثابة هيئات رقابة، وفي هذه الحالة تصبح الرشوة المحتملة هجومًا قويًا بشكل خاص. ملاحظة: يتطلب أمان آلية staking ذات الجولة الواحدة عدم إمكانية استغلالها القنوات بين oracle وعقد المستوى الثاني - وهو مطلب قياسي في الأنظمة المقاومة للإكراه، على سبيل المثال، التصويت [82، 138]، وهو مطلب معقول في الممارسة العملية. بالإضافة إلى ذلك، يمكن إنشاء عقدة Oi التي تسعى إلى التعاون مع الراشي أسهمها السرية بطريقة تُظهر للرشوة أنها قامت بتشفير شيء معين قيمة. على سبيل المثال، إذا كان Oi لا يعرف العقد التي يتحكم فيها الرشاوي، فيمكن لـ Oi ذلك تقديم أسهم بقيمة 0 إلى جميع أعضاء اللجنة. يمكن للرشاوي بعد ذلك التحقق من Oi الامتثال احتماليا. ولتجنب هذه المشكلة في أي بروتوكول أحادي الجولة، فإننا تتطلب أن تعرف Oi هوية عقدة واحدة صادقة من الدرجة الثانية على الأقل. باستخدام بروتوكول تفاعلي تضيف فيه كل عقدة من المستوى الثاني توزيعًا عشوائيًا عامل الأسهم، أفضل ما يمكن أن يفعله مقدم الرشوة هو فرض الاختيار بواسطة Oi بشكل عشوائي قليلا الوكالة الدولية للطاقة. 9.6 إطار الحوافز الضمنية (IIF) يعد FFO أحد أشكال الحوافز الضمنية للسلوك الصحيح في شبكة Chainlink. ذلك وظائف مثل الحصة الصريحة، أي الودائع، من حيث أنها تساعد في فرض الأمن الاقتصادي الشبكة. وبعبارة أخرى، ينبغي إدراج FFO كجزء من الوديعة (الفعالة). $d للعقدة في الشبكة.والسؤال هو: كيف يمكننا قياس FFO وغيرها من أشكال الحوافز الضمنية داخل شبكة Chainlink؟ إطار الحوافز الضمنية (IIF) عبارة عن مجموعة من المبادئ والتقنيات التي نخطط لتطويرها لهذا الغرض. أنظمة البلوكشين توفير العديد من أشكال الشفافية غير المسبوقة، وسجلات الثقة العالية للعقدة إن الأداء الذي يقدمونه يشكل نقطة انطلاق لرؤيتنا لكيفية عمل معهد التمويل الدولي. نعرض هنا بإيجاز شديد الأفكار حول العناصر الأساسية لمعهد التمويل الدولي. وسوف يتكون معهد التمويل الدولي نفسه من مجموعة من العوامل التي نعتبرها مهمة في التقييم الحوافز الضمنية، إلى جانب آليات نشر البيانات ذات الصلة في شكل عالي التأكيد لاستهلاكها بواسطة خوارزميات التحليل. يمكن لمستخدمي Chainlink المختلفين ترغب في استخدام معهد التمويل الدولي بطرق مختلفة، على سبيل المثال، إعطاء وزن مختلف لعوامل مختلفة. نتوقع ظهور خدمات تحليلية في المجتمع تساعد المستخدمين على تطبيق IIF وفقًا لتفضيلاتهم الفردية لتقييم المخاطر، وهدفنا هو تسهيل ذلك هذه الخدمات من خلال ضمان وصولهم إلى البيانات الداعمة عالية الجودة وفي الوقت المناسب، كما نناقش أدناه (القسم 9.6.4). 9.6.1 فرصة الرسوم المستقبلية تشارك العقد في النظام البيئي Chainlink لكسب حصة من الرسوم التي تدفعها الشبكات مقابل أي من الخدمات المتنوعة التي وصفناها في هذه الورقة، من تغذي البيانات العادية الخدمات المتقدمة مثل الهوية اللامركزية، والتسلسل العادل، والحفاظ على السرية DeFi. الرسوم في Chainlink تكاليف مشغلي عقدة دعم الشبكة، على سبيل المثال، تشغيل الخوادم، والحصول على تراخيص البيانات اللازمة، والحفاظ على فريق عمل عالمي لضمان وقت تشغيل عالي. يشير FFO إلى رسوم الخدمة، صافي النفقات، التي يمكن للعقدة أن تكسبها في المستقبل - أو تخسرها إذا أظهرت سلوكًا خاطئًا. FFO هو شكل من أشكال الحصة التي تساعد في تأمين الشبكة. الميزة المفيدة لـ FFO هي حقيقة أن البيانات الموجودة على السلسلة (المكملة بالبيانات خارج السلسلة) data) إنشاء سجل عالي الثقة لتاريخ العقدة، مما يتيح حساب FFO بطريقة شفافة مدفوعة تجريبيا. يمكن استخلاص مقياس بسيط من الدرجة الأولى لـ FFO من متوسط صافي الإيرادات لـ a عقدة على مدار فترة زمنية (أي إجمالي الإيرادات مطروحًا منها نفقات التشغيل). FFO قد ثم يتم حسابها على سبيل المثال، صافي القيمة الحالية [114] لصافي الإيرادات المستقبلية التراكمية، وبعبارة أخرى، القيمة المخصومة زمنيا لجميع الأرباح المستقبلية. ومع ذلك، يمكن أن تكون إيرادات العقدة متقلبة، كما هو موضح على سبيل المثال في الشكل 17. والأهم من ذلك، أن إيرادات العقدة قد لا تتبع توزيعًا ثابتًا مع مرور الوقت. وبالتالي، فإن العوامل الأخرى التي نخطط لاستكشافها في تقدير FFO تشمل ما يلي: • سجل الأداء: يوفر سجل أداء المشغل - بما في ذلك صحة تقاريره وتوقيتها، بالإضافة إلى وقت تشغيله - هدفًا المحك للمستخدمين لتقييم موثوقيتها. وهكذا فإن تاريخ الأداء توفير عامل حاسم في اختيار المستخدمين للعقد oracle (أو، مع ظهور من DONs، اختيارهم لـ DONs). ومن المرجح أن يكون هناك سجل أداء قوي ترتبط مع ارتفاع الإيرادات الجارية.18 18أحد الأسئلة البحثية المهمة التي نعتزم معالجتها هو الكشف عن أحجام الخدمات المزيفة.الشكل 17: الإيرادات المكتسبة بواسطة Chainlink العقد على خلاصة بيانات واحدة (ETH-USD) خلال أسبوع تمثيلي في مارس 2021. • الوصول إلى البيانات: بينما قد تحصل oracles على العديد من نماذج البيانات من واجهات برمجة التطبيقات المفتوحة، قد تكون بعض أشكال البيانات أو بعض المصادر عالية الجودة متاحة فقط على أساس الاشتراك أو من خلال الاتفاقيات التعاقدية. امتياز الوصول إلى بعض يمكن أن تلعب مصادر البيانات دورًا في إنشاء تدفق ثابت للإيرادات. • مشاركة DON: مع ظهور DONs، ستأتي مجتمعات العقد معا لتقديم خدمات معينة. نتوقع أن يتم تضمين العديد من DONs المشغلين على أساس انتقائي، مع تحديد المشاركة في DONs ذات السمعة الطيبة باعتبارها مكانة متميزة في السوق تساعد على ضمان مصدر ثابت للدخل. • النشاط عبر الأنظمة الأساسية: قد يكون لدى بعض مشغلي العقد تواجد راسخ وسجلات تتبع الأداء في سياقات أخرى، على سبيل المثال، PoS validators أو موفري البيانات في سياقات غير blockchain. ويمكن لأدائها في هذه الأنظمة الأخرى (عندما تكون البيانات المتعلقة بها متاحة في شكل جدير بالثقة) أن يفيد التقييم من تاريخ أدائهم. وبالمثل، السلوك الخاطئ في شبكة Chainlink يمكن أن يعرض الإيرادات في هذه الأنظمة الأخرى للخطر عن طريق إبعاد المستخدمين، أي FFO يمكن أن تمتد عبر المنصات. 9.6.2 FFO المضاربة يشارك مشغلو العقد في شبكة Chainlink ليس فقط لتوليد الإيرادات منها العمليات، ولكن لخلق أنفسهم ووضعهم للاستفادة من الفرص الجديدة لإدارة الوظائف. بمعنى آخر، الإنفاق بواسطة oracle العقد في الشبكة أيضًا بيان إيجابي حول مستقبل DeFi وتطبيق العقود الذكية الأخرى المجالات بالإضافة إلى التطبيقات الناشئة غير blockchain لشبكات oracle. يكسب مشغلو العقد اليوم الرسوم المتاحة على شبكات Chainlink الحالية وفي وقت واحد تشبه هذه بشكل عام المراجعات المزيفة على مواقع الإنترنت، إلا أن المشكلة أسهل في oracle لأنه لدينا سجل نهائي حول ما إذا كانت البضائع، أي التقارير، قد تم طلبها أم لا يتم تسليمها - على عكس، على سبيل المثال، السلع المادية المطلوبة في المتاجر عبر الإنترنت. وبعبارة أخرى، في oracle الإعداد، يمكن التحقق من صحة الأداء، حتى لو لم يكن ذلك ممكنًا.بناء سمعة وتاريخ أداء وخبرة تشغيلية من شأنها أن تحدد مكانتك لهم بشكل مفيد لكسب الرسوم المتاحة في الشبكات المستقبلية (المشروطة، بالطبع، على السلوك الصادق). العقد العاملة في النظام البيئي Chainlink اليوم سوف تفعل ذلك يتمتع Sense بميزة على القادمين الجدد في كسب الرسوم كرسوم إضافية Chainlink تصبح الخدمات متاحة. وتنطبق هذه الميزة على المشغلين الجدد، فضلاً عن شركات التكنولوجيا ذات السمعة الطيبة؛ على سبيل المثال، T-Systems، وهو نظام تقليدي مزود التكنولوجيا (شركة تابعة لشركة Deutsche Telekom)، وKraken، وهي شركة مركزية كبيرة التبادل، أسسوا تواجدًا مبكرًا في النظام البيئي Chainlink [28، 143]. يمكن اعتبار مثل هذه المشاركة بواسطة العقد oracle في الفرص المستقبلية بحد ذاتها كنوع من FFO المضاربة، وبالتالي يشكل شكلاً من أشكال الحصة في Chainlink شبكة. 9.6.3 السمعة الخارجية يمكن لمعهد التمويل الدولي كما وصفناه أن يعمل في شبكة بأسماء مستعارة تمامًا المشغلين، أي دون الكشف عن الأشخاص أو كيانات العالم الحقيقي المعنية. ومع ذلك، فإن أحد العوامل المهمة المحتملة لاختيار المستخدم لمقدمي الخدمات هو عامل خارجي السمعة. ونعني بالسمعة الخارجية تصور الجدارة بالثقة المرتبط بهويات العالم الحقيقي، وليس الأسماء المستعارة. مخاطر السمعة المرتبطة يمكن النظر إلى هويات العالم الحقيقي على أنها شكل من أشكال الحوافز الضمنية. نحن ننظر إلى السمعة من خلال عدسة معهد التمويل الدولي، أي بالمعنى الاقتصادي المشفر، كوسيلة للتأسيس النشاط عبر الأنظمة الأساسية الذي يمكن دمجه في تقديرات FFO. فائدة استخدام السمعة الخارجية كعامل في تقديرات FFO، على العكس من ذلك إلى الارتباط بأسماء مستعارة، هو أن السمعة الخارجية تربط الأداء ليس فقط بـ الأنشطة الحالية للمشغل، ولكن أيضًا للأنشطة المستقبلية. إذا، على سبيل المثال، سمعة سيئة عندما يتعلق الأمر بفرد ما، فإنه يمكن أن يلوث مشاريع ذلك الشخص المستقبلية. وبعبارة أخرى، يمكن للسمعة الخارجية أن تستحوذ على نطاق أوسع من FFO مقارنة بالأسماء المستعارة سجلات الأداء، وتأثير المخالفات المرتبطة بشخص أو المنشأة من الصعب الهروب من الشركة أكثر من تلك المرتبطة بعملية اسم مستعار. Chainlink متوافق مع تقنيات الهوية اللامركزية (القسم 4.3). يمكن أن يقدم الدعم لاستخدام السمعة الخارجية في معهد التمويل الدولي. مثل هذه التقنيات يمكن التحقق من صحة وبالتالي المساعدة في ضمان صحة العالم الحقيقي المؤكد للمشغلين الهويات.19 9.6.4 افتح تحليلات IIF يهدف معهد التمويل الدولي، كما أشرنا، إلى توفير بيانات وأدوات موثوقة مفتوحة المصدر تحليلات الحوافز الضمنية. الهدف هو تمكين مقدمي الخدمات داخل المجتمع لتطوير تحليلات مصممة خصيصًا لتلبية احتياجات تقييم المخاطر لأجزاء مختلفة من المنظمة Chainlink قاعدة المستخدمين. 19. يمكن أيضًا لأوراق اعتماد الهوية اللامركزية، عند الرغبة، تزيين الأسماء المستعارة بأسماء مستعارة تم التحقق من صحتها. معلومات تكميلية. على سبيل المثال، يمكن لمشغل العقدة من حيث المبدأ استخدام بيانات الاعتماد هذه من أجل إثبات أنها إحدى شركات Fortune 500، دون الكشف عن أي منها.كمية كبيرة من البيانات التاريخية المتعلقة بإيرادات العقد وأدائها يوجد في سلسلة في شكل عالي الثقة وغير قابل للتغيير. ولكن هدفنا هو توفير البيانات الممكنة الأكثر شمولاً، بما في ذلك البيانات المتعلقة بالسلوكيات التي لا يمكن رؤيتها إلا من الخارج سلسلة، مثل التقارير خارج السلسلة (OCR) أو نشاط DON. من المحتمل أن تكون مثل هذه البيانات تكون ضخمة. الطريقة الأفضل لتخزينها والتأكد من سلامتها، أي حمايتها من نعتقد أن التلاعب سيتم بمساعدة DONs، باستخدام التقنيات التي تمت مناقشتها في القسم 3.3. بعض الحوافز تصلح لأشكال القياس المباشرة، مثل staking الودائع و FFO الأساسية. أما البعض الآخر، مثل المضاربة الأجنبية المباشرة والسمعة، فيصعب القيام بها قياس بطريقة موضوعية، ولكننا نعتقد أن أشكال البيانات الداعمة، بما في ذلك النمو التاريخي للنظام البيئي Chainlink، ومقاييس السمعة على وسائل التواصل الاجتماعي، وما إلى ذلك، يمكن أن تدعم نماذج تحليلات IIF حتى بالنسبة لهذه العناصر التي يصعب تحديدها كميًا. يمكننا أن نتخيل أن DONs مخصصة تنشأ خصيصًا للمراقبة والتحقق من الصحة تسجيل البيانات المتعلقة بسجلات الأداء خارج السلسلة للعقد، بالإضافة إلى البيانات الأخرى المستخدمة في IIF، مثل معلومات الهوية التي تم التحقق من صحتها. يمكن أن توفر DONs بيانات IIF موحدة وعالية الثقة لأي موفري تحليلات يخدمون مجتمع Chainlink. وسيوفرون أيضًا سجلاً ذهبيًا يقدم ادعاءات موفري التحليلات يمكن التحقق منها بشكل مستقل من قبل المجتمع. 9.7 تجميع كل ذلك معًا: حوافز مشغل العقدة تجميع مناقشاتنا أعلاه حول الحوافز الصريحة والضمنية لمشغلي العقد يوفر نظرة شاملة للطرق التي يشارك بها مشغلو العقد ويستفيدون منها شبكة Chainlink. كدليل مفاهيمي، يمكننا التعبير عن إجمالي الأصول المعنية من خلال Chainlink معين مشغل العقدة $S في شكل تقريبي ومنمق على النحو التالي: \(S ≈\)D + \(F + \)FS + $R، حيث: • $D هو إجمالي الحصص المودعة بشكل صريح عبر جميع الشبكات التي فيها يشارك المشغل؛ • $F هو صافي القيمة الحالية لمجموع جميع FFO عبر جميع الشبكات التي يشارك فيها المشغل؛ • $FS هو صافي القيمة الحالية لـ FFO المضاربة للمشغل. و • $R هو قيمة سمعة المشغل خارج النظام البيئي Chainlink التي قد تتعرض للخطر بسبب سوء السلوك الذي تم تحديده في عقدها oracle. على الرغم من أنها مفاهيمية إلى حد كبير، إلا أن هذه المساواة التقريبية تظهر بشكل مفيد أن هناك العديد من العوامل الاقتصادية التي تفضل الأداء عالي الموثوقية بواسطة Chainlink العقد. كل هذه العوامل بخلاف $D موجودة في شبكات Chainlink اليوم.9.8 الدورة الفاضلة للأمن الاقتصادي مزيج من التأثير الخطي الفائق staking مع تمثيل مدفوعات الرسوم حيث أن فرصة الرسوم المستقبلية (FFO) في معهد التمويل الدولي يمكن أن تؤدي إلى ما نسميه الدورة الحميدة للأمن الاقتصادي في شبكة oracle. ويمكن اعتبار هذا نوعا من الاقتصاد من الحجم. ومع ارتفاع المبلغ الإجمالي المضمون بواسطة شبكة معينة، يزداد مقدار هناك حاجة إلى حصة إضافية لإضافة مقدار ثابت من انخفاض الأمن الاقتصادي كما هو الحال متوسط التكلفة لكل مستخدم. لذلك، يعد انضمام المستخدم أرخص من حيث الرسوم شبكة موجودة بالفعل من تحقيق نفس الزيادة في الشبكة الاقتصادية الأمن عن طريق إنشاء شبكة جديدة. الأهم من ذلك، أن إضافة كل مستخدم جديد يخفض تكلفة الخدمة لجميع المستخدمين السابقين لتلك الشبكة. بالنظر إلى هيكل رسوم معين (على سبيل المثال، معدل عائد معين على المبلغ المراهن عليه)، إذا زاد إجمالي الرسوم التي تكسبها الشبكة، فإن هذا يحفز تدفق الرسوم الإضافية حصة في الشبكة لتأمينها بمعدل أعلى. على وجه التحديد، إذا كانت الحصة الإجمالية يتم تغطية العقدة الفردية التي قد تعقد في النظام، ثم عند دفع الرسوم الجديدة أدخل النظام، ورفع FFO، وسوف يزيد عدد العقد n. شكرا ل فائقة الخطية staking تأثير تصميم نظام الحوافز لدينا، والأمن الاقتصادي ل سوف يرتفع النظام بشكل أسرع من n، على سبيل المثال، كما هو الحال مع n2 في الآلية التي نرسمها في القسم 9.4. ونتيجة لذلك، فإن متوسط تكلفة الأمن الاقتصادي - أي مقدار المساهمة في الحصة دولار من الأمن الاقتصادي – سينخفض. وبالتالي يمكن للشبكة فرض رسوم على مستخدميها رسوم أقل. بافتراض أن الطلب على خدمات oracle مرن (انظر، على سبيل المثال، [31] للحصول على ملخص) تفسيرا)، سيرتفع الطلب، مما يولد رسوما إضافية و FFO. ونوضح هذه النقطة بالمثال التالي. مثال 5. منذ الأمن الاقتصادي لشبكة oracle مع حافزنا المخطط هو \(dn2 for stake \)dn، الأمن الاقتصادي الذي ساهم به دولار من الحصة هو n، وبالتالي متوسط تكلفة كل دولار من الأمن الاقتصادي، أي مقدار الحصة المساهمة في دولار واحد من الأمن الاقتصادي — هو 1/ن. لننظر إلى شبكة تتكون فيها الحوافز الاقتصادية بالكامل من FFO، ذات حد أقصى عند \(d ≤\)10K لكل عقدة. لنفترض أن الشبكة بها n = 3 عقد. ثم متوسط التكلفة ويبلغ كل دولار من الأمن الاقتصادي حوالي 0.33 دولار. لنفترض أن إجمالي FFO للشبكة يرتفع فوق \(30K (e.g., to \)31K). نظرا الحد الأقصى لكل عقدة FFO، تنمو الشبكة إلى (على الأقل) n = 4. الآن متوسط التكلفة وينخفض كل دولار من الأمن الاقتصادي إلى نحو 0.25 دولار. نوضح الدورة الحميدة الكاملة للأمن الاقتصادي في شبكات oracle بشكل تخطيطي في الشكل 18. ونؤكد على أن الدورة الحميدة للأمن الاقتصادي تنبع من التأثير من المستخدمين تجميع رسومهم. إن FFO الجماعي الخاص بهم هو الذي يعمل لصالح الأكبر أحجام الشبكات وبالتالي قدر أكبر من الأمن الجماعي. ونلاحظ أيضا أن الدورة الفاضلة يعمل الأمن الاقتصادي لصالح DON لتحقيق الاستدامة المالية. مرة واحدة تم إنشاؤها، DONs التي تلبي احتياجات المستخدم يجب أن تنمو إلى ما هو أبعد من النقطة التي عندها تتجاوز الإيرادات من الرسوم تكاليف التشغيل لـ oracle العقد.
الشكل 18: رسم تخطيطي للدورة الفاضلة لـ Chainlink staking. ارتفاع في رسوم المستخدم تؤدي المدفوعات إلى شبكة oracle 1⃝ إلى نموها، مما يؤدي إلى نمو اقتصادها الأمن 2⃝. يحقق هذا النمو الخطي الفائق وفورات الحجم في شبكات Chainlink 3⃝. ويعني على وجه التحديد انخفاضًا في متوسط تكلفة الأمن الاقتصادي، أي: الأمن الاقتصادي لكل دولار الناشئ عن دفع الرسوم أو مصادر الحصص الأخرى يزيد. تؤدي التكاليف المنخفضة، التي يتم تمريرها إلى المستخدمين، إلى تحفيز الطلب المتزايد على oracle الخدمات 4⃝. 9.9 عوامل إضافية تقود نمو الشبكة مع استمرار توسع النظام البيئي Chainlink، فإننا نؤمن بجاذبيته للمستخدمين والأهمية مع تسارع البنية التحتية لاقتصاد blockchain. القيمة التي توفرها شبكات oracle هي قيمة خطية للغاية، مما يعني أنها تنمو بشكل أسرعمن حجم الشبكات نفسها. وهذا النمو في القيمة مستمد من كليهما وفورات الحجم - زيادة كفاءة التكلفة لكل مستخدم مع زيادة حجم الخدمة - و تأثيرات الشبكة - زيادة في فائدة الشبكة حيث يتبنى المستخدمون DONs على نطاق أوسع. مع استمرار smart contracts الحاليين في رؤية المزيد من القيمة المضمونة والجديدة تمامًا smart contract أصبحت التطبيقات ممكنة من خلال المزيد من الخدمات اللامركزية، المجموع يجب أن ينمو استخدام الرسوم الإجمالية المدفوعة إلى DONs. زيادة مجمعات الرسوم في تحويلها إلى وسائل وحوافز لخلق المزيد من الخدمات اللامركزية، مما أدى إلى دورة حميدة. هذه الدورة الفاضلة تحل مشكلة الدجاجة والبيضة الحرجة المشكلة في النظام البيئي smart contract المختلط: ميزات smart contract المبتكرة غالبًا ما تتطلب خدمات لا مركزية غير موجودة بعد (على سبيل المثال، أسواق DeFi الجديدة غالبًا تتطلب خلاصات بيانات جديدة) ولكنها تحتاج إلى طلب اقتصادي كافٍ لكي تظهر إلى الوجود. إن تجميع الرسوم من خلال smart contracts المختلفة لـ DONs الحالية سيشير إلى الطلب على خدمات لامركزية إضافية من قاعدة مستخدمين متنامية، مما أدى إلى إنشائها بواسطة DONs والتمكين المستمر لـ smart contracts الهجين الجديد والمتنوع. باختصار، نحن نعتقد أن النمو في أمن الشبكات مدفوع بالفاضلة الدورات في آلية Chainlink staking تمثل أنماطًا أكبر من النمو يمكن لشبكة Chainlink أن تساعد في تحقيق اقتصاد متصل بالسلسلة من أجل اللامركزية الخدمات.
结论
在本文中，我们提出了 Chainlink 的演变愿景。主题 在这一愿景中，oracle 网络有能力为以下用户提供更广泛的服务： smart contracts 比单纯的数据传输。使用 DON 作为未来去中心化服务的基础，Chainlink 将致力于提供高性能、保密性增强的 oracle 功能。其 oracle 网络将提供强大的信任最小化 通过结合原则性的加密经济机制，例如 staking 和 精心设计的护栏和依赖主链的服务水平执行。 DONs 还将帮助第 2 层系统对交易执行灵活、公平的排序策略，并降低内存池路由交易的 Gas 成本。综合起来， 这些功能都朝着安全且功能丰富的混合智能方向发展 合同。 DON 的灵活性将增强现有的 Chainlink 服务并带来 许多附加的 smart contract 功能和应用程序。其中，无缝衔接 连接到各种链下系统，去中心化身份创建 现有数据、优先渠道有助于确保及时交付关键基础设施 交易和保密 DeFi 工具。 我们在这里提出的愿景是雄心勃勃的。在短期内，我们寻求增强能力 混合合同来实现目前 smart contract 无法实现的目标，同时 从长远来看，我们的目标是实现去中心化的元层。庆幸的是我们可以画画 新工具和想法——从共识算法到零知识证明 系统——社区正在开发该系统，作为快速发展的研究的成果。
同样，我们希望优先实施本文中的想法作为回应 满足 Chainlink 用户社区的需求。我们期待下一阶段 我们寻求通过通用连接来增强 smart contract 的能力并建立 去中心化技术是世界下一代金融的支柱 和法律制度。 致谢 感谢 Julian Alterini 和 Shawn Lee 绘制了本文中的数据。
خاتمة
في هذه الورقة، وضعنا رؤية لتطور Chainlink. الموضوع الرئيسي في هذه الرؤية تكمن قدرة الشبكات oracle على توفير نطاق أوسع بكثير من الخدمات smart contracts أكثر من مجرد تسليم البيانات. باستخدام DONs كأساس للخدمات اللامركزية في المستقبل، سيهدف Chainlink إلى توفير وظائف oracle عالية الأداء ومعززة للسرية. ستوفر شبكات oracle الخاصة بها تقليلًا قويًا للثقة من خلال مجموعة من آليات الاقتصاد المشفر المبدئية مثل staking و حواجز حماية مصممة بعناية وإنفاذ على مستوى الخدمة يعتمد على السلاسل الرئيسية. سيساعد DONs أيضًا أنظمة الطبقة الثانية على فرض سياسات طلب مرنة وعادلة على المعاملات، بالإضافة إلى تقليل تكاليف الغاز للمعاملات الموجهة بواسطة الذاكرة. مجتمعة، كل هذه القدرات تقود في اتجاه نظام ذكي هجين آمن وغني بالوظائف العقود. ستؤدي مرونة DONs إلى تحسين خدمات Chainlink الحالية وتؤدي إلى العديد من الميزات والتطبيقات الإضافية smart contract. ومن بين هذه سلسة الاتصال بمجموعة واسعة من الأنظمة خارج السلسلة، وإنشاء الهوية اللامركزية من البيانات الحالية، والقنوات ذات الأولوية للمساعدة في ضمان تسليم البنية التحتية الحيوية في الوقت المناسب المعاملات وأدوات الحفاظ على السرية DeFi. إن الرؤية التي طرحناها هنا طموحة. وعلى المدى القصير، نسعى إلى التمكين عقود هجينة لتحقيق أهداف بعيدة عن متناول smart contracts اليوم، بينما على المدى الطويل، نهدف إلى تحقيق طبقة معدنية لا مركزية. لحسن الحظ يمكننا الرسم على أدوات وأفكار جديدة، تتراوح من خوارزميات الإجماع إلى إثبات المعرفة الصفرية الأنظمة - التي يتطورها المجتمع كثمرة لأبحاث سريعة التطور.
وبالمثل، نتوقع إعطاء الأولوية لتنفيذ الأفكار الواردة في هذه الورقة ردًا على ذلك لتلبية احتياجات مجتمع مستخدمي Chainlink. ونحن نتطلع إلى المرحلة التالية في سعينا لتمكين smart contracts من خلال الاتصال العالمي والتأسيس التكنولوجيات اللامركزية باعتبارها العمود الفقري للجيل القادم من الخدمات المالية في العالم والأنظمة القانونية. شكر وتقدير شكرًا لجوليان ألتريني وشون لي على تقديم الأرقام الواردة في هذه الورقة.