ホワイトペーパー ストーリー 図 用語集 グラフ 検索

Chainlink: شبكة أوراكل اللامركزية

著 Steve Ellis, Ari Juels and Sergey Nazarov · 2017

単一表示 chain.link
🇺🇸 English (原文)
🇸🇦 العربية (翻訳)

概要

このホワイトペーパーでは、元の Chainlink ホワイトペーパーの初期概念を超えた Chainlink の進化のビジョンを明確に示します。 私たちは予測します oracle ネットワークの役割はますます拡大しており、高速性、信頼性、信頼性を提供することで既存および新規の blockchain を補完および強化します。 機密性を維持したユニバーサル接続とオフチェーン計算 smart contract秒。 私たちの計画の基礎となるのは、分散型 Oracle ネットワーク (つまり分散型 Oracle ネットワーク) と呼ばれるものです。 略してDONs。 DON は、Chainlink の委員会によって維持されるネットワークです。 ノード。 目的に選択された無制限の範囲の oracle 関数をサポートします。 委員会による展開。したがって、DON は強力な抽象化レイヤーとして機能します。 smart contracts のインターフェイスを広範なオフチェーン リソースに提供し、 DON 自体内の効率的でありながら分散化されたオフチェーン コンピューティング リソース。 DON を出発点として、Chainlink は 7 つの分野の進歩に注力する予定です 主要分野: • ハイブリッド 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.

導入

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

ブロックチェーン oracle は、現在、次の 1 つの目的を備えた分散型サービスとして見なされていることがよくあります。 オフチェーン リソースから blockchain にデータを転送します。短いステップではありますが、 データの転送から、データの計算、保存、双方向の送信まで。この観察は、oracles の機能についてのより広い概念を正当化します。それもそうだ smart contract の増加し、ますます多面化するサービス要件に対応します oracle ネットワークに依存するテクノロジー。つまり、oracle は次のことを行うことができ、またそうする必要があります。 オンチェーン システムとオフチェーン システムの間の汎用、双方向、コンピューティング対応インターフェイスであること。 blockchain エコシステムにおけるオラクルの役割は、 smart contract のパフォーマンス、機能、相互運用性を向上させ、 さまざまな業界に新しい信頼モデルと透明性をもたらします。この変革は、ハイブリッド smart contract の使用を拡大することによって実現されます。 blockchains の特別なプロパティと、オフチェーン システムの独自の機能を備えた次のような oracle ネットワークを利用することで、オンチェーン システムよりもはるかに大きな到達範囲とパワーを実現します。 孤立して。 このホワイトペーパーでは、Chainlink 2.0 と呼ばれるもののビジョンを明確に示します。これは、元の Chainlink ホワイトペーパー [98] の初期概念を超えた Chainlink の進化です。 oracle ネットワークの役割はますます拡大すると予想されます。 これらは、ハイブリッド向けに高速で信頼性が高く、機密性を保持するユニバーサルな接続と計算機能を提供することにより、既存および新しい blockchain を補完および強化します。 smart contract秒。私たちは、oracle ネットワークが進化してユーティリティになると信じています 高整合性 blockchain グレードのデータを blockchain 以降のシステムにエクスポートするため 生態系。 現在、さまざまなエンティティのセットによって実行される Chainlink ノードが oracle ネットワークに集まり、いわゆるレポートでデータを smart contract に中継します。そのようなものを見ることができます oracle ノードは、古典的なコンセンサス blockchain [72] と同様の委員会として、 ただし、独立した機能を提供するのではなく、既存の blockchain をサポートすることを目的としています。検証可能なランダム関数 (VRF) とオフチェーン レポート機能を搭載 (OCR)、Chainlink は、smart contract が必要とする計算リソースを提供するための汎用フレームワークとインフラストラクチャに向けてすでに進化しています。 高度な機能。 Chainlink 2.0 の計画の基礎となるのは、分散型 Oracle と呼ばれるものです。 ネットワーク、略して DONs。 「oracle ネットワーク」という用語を オリジナルの Chainlink ホワイトペーパー [98]、oracle はさらに豊富な機能を開発し、 応用範囲の広さ。この論文では、以下に従ってこの用語の新たな定義を提供します。 Chainlink エコシステムの将来のビジョンに向けて。このビューでは、DON はネットワークです Chainlink ノードの委員会によって維持されています。コンセンサスプロトコルに基づいており、 によって展開用に選択された無制限の範囲の oracle 関数のいずれかをサポートします。 委員会。したがって、DON は blockchain 抽象化レイヤーとして機能し、インターフェイスを提供します smart contract と他のシステムの両方のリソースをオフチェーンにします。また、 非常に効率的でありながら分散化されたオフチェーン コンピューティング リソースへのアクセス。一般に、 DON はメインチェーンでの操作をサポートします。その目標は、安全かつ柔軟なセキュリティを実現することです。オンチェーンとオフチェーンの計算を組み合わせたハイブリッド smart contracts 外部リソースへの接続。 DON で委員会を利用したとしても、Chainlink 自体は 本質的にパーミッションレスのままです。 DON はパーミッションレスの基盤として機能します ノードが連携してカスタム oracle ネットワークを実装できるフレームワーク ノードを含めるための独自の体制。これは許可されている場合と許可されていない場合があります。 DONs を基盤として、Chainlink 2.0 では 7 つの機能の進歩に重点を置く予定です。 主要領域: ハイブリッド smart contract、複雑さの抽象化、スケーリング、機密性、トランザクションの順序の公平性、信頼の最小化、インセンティブ ベースの (暗号経済) セキュリティ。この論文の紹介では、分散型の概要を紹介します。 セクション 1.1 では Oracle ネットワークについて説明し、セクション 1.2 ではイノベーションの 7 つの主要分野について説明します。この文書の残りの構成についてはセクション 1.3 で説明します。 1.1 分散型 Oracle ネットワーク 分散型 Oracle ネットワークは、機能を強化および拡張するように設計されています。 ターゲット blockchain または関数を介したメイン チェーン上の smart contract の数 ネイティブでは利用できません。彼らは、次の 3 つの基本リソースを提供することでこれを実現します。 コンピューティング システム: ネットワーキング、ストレージ、およびコンピューティング。 DON の目的は、 これらのリソースは、強力な機密性、完全性、および可用性の特性1を備えています。 説明責任も。 DON は、特定の条件を満たすために協力する oracle ノードの委員会によって形成されます。 仕事を続けるか、永続的なサービスを提供するために長期的な関係を築くことを選択します クライアントへ。 DON は、blockchain に依存しない方法で設計されています。彼らは次のように奉仕することを約束します アプリケーション開発者がオフチェーン サポートを作成するための強力で柔軟なツール サポートされているメイン チェーン上の smart contract。 DON の機能は、実行可能ファイルと実行可能ファイルの 2 種類の機能によって実現されます。 アダプター。実行可能ファイルは、DON 上で継続的かつ分散的に実行されるプログラムです。メインチェーン資産を直接保存するわけではありませんが、高いパフォーマンスや機密情報を実行する機能など、重要な利点があります。 計算。実行可能ファイルは DON 上で自律的に実行され、決定論的に実行されます。 操作。これらは、DON を外部リソースにリンクするアダプターと連携して動作します。 実行可能ファイルによって呼び出される可能性があります。私たちが DON 向けに想定しているアダプターは、 本日、Chainlink で外部アダプターが一般化されました。既存のアダプターを使用しながら、 通常、アダプターはデータ ソースからデータをフェッチするだけですが、アダプターは双方向で動作する場合があります。で DON では、DON ノードによる共同計算をさらに利用して、次のことを達成する場合があります。 プライバシーを保護して利用するためのレポートの暗号化などの追加機能 実行可能ファイル。 DON の基本的な動作を理解するために、図 1 に、DON がどのように動作するかを概念的に示します。 DON は、レポートを blockchain に送信するために使用され、従来の既存の oracle 機能を実現できます。 DONs は多くの追加機能を提供しますが、それ以外にも 1 情報セキュリティの「CIA トライアド」 [123、p. 26、§2.3.5]。Chainlink の既存のネットワーク。たとえば、図 1 の一般的な構造内では、 実行可能ファイルは、取得した資産価格データを DON に記録し、そのようなデータを使用して たとえば、レポートの末尾平均を計算します。 図 1: 分散型 Oracle ネットワークが基本的な oracle 機能、つまりオフチェーン データをコントラクトに中継する方法を例として示す概念図。アン 実行可能ファイルはアダプターを使用してオフチェーン データを取得し、そのデータに基づいて計算し、出力を送信します 別のアダプターを介してターゲット blockchain に接続します。 (アダプターは、 DON、小さな青いボックスで表されます。矢印は、このデータ フローの方向を示します。 特定の例。) 実行可能ファイルは、ローカル DON への読み取りと書き込みも可能です。 状態を保持したり、他の実行可能ファイルと通信したりするためのストレージ。ここに示されている DONs の柔軟なネットワーキング、コンピューティング、およびストレージは、さまざまな新しい機能を可能にします。 アプリケーション。 DON の主な利点は、新しい blockchain サービスをブートストラップできることです。 DONs 既存の oracle ネットワークがサービス アプリケーションを迅速に立ち上げることができる手段です それには今日では専用のネットワークの構築が必要になります。いくつか挙げます このようなアプリケーションの例はセクション 4 で説明します。 セクション 3 では、DON について詳しく説明し、その機能について説明します。 開発者とユーザーに提示するインターフェイスの用語。 1.2 7 つの主要な設計目標 ここでは、上で列挙した 7 つの重要な焦点を簡単にレビューします。 Chainlink、つまり:ハイブリッド smart contracts: Chainlink に対する当社のビジョンの中心となるのは、安全性を確保するという考えです。 smart contracts でオンチェーン コンポーネントとオフチェーン コンポーネントを組み合わせます。契約書を参照します このアイデアは、ハイブリッド smart contract またはハイブリッド コントラクトとして実現されます。2 ブロックチェーンは、分散型サービスにおいて 2 つの重要な役割を現在も果たし続けます。 エコシステム: どちらも暗号通貨の所有権が表現される場所です 分散型サービスのための堅牢なアンカー。したがって、スマート コントラクトはチェーン上で表現または実行される必要がありますが、そのオンチェーン機能は大幅に制限されています。純粋に オンチェーンコントラクトコードは遅く、高価で、閉鎖的であり、現実世界の恩恵を受けることができない データと、さまざまな形式の機密計算、安全な (擬似) 乱数の生成など、チェーン上では本質的に実現不可能なさまざまな機能 マイナー / validator 操作などに対して。 したがって、smart contracts がその可能性を最大限に発揮するには、smart contracts が必要です。 オンチェーン部分 (通常、SC で表します) の 2 つの部分で設計されます。 オフチェーン部分、DON 上で実行される実行可能ファイル (通常、これを次のように表します) 実行)。目標は、オンチェーン機能の安全な構成を達成することです。 DON が提供しようとしている多数のオフチェーン サービス。 2 つの部分を合わせて、 ハイブリッド契約を締結します。このアイデアを概念的に図 2 に示します。 Chainlink データ フィードや VRF などのサービス3 により、他の方法では実現できないことが可能になります smart contract アプリケーションは、DeFi から適切に生成された NFT、分散型保険に至るまで、より一般的なフレームワークに向けた最初のステップとして提供されます。 Chainlink サービスとして このホワイトペーパーのビジョンに従って拡張し、よりパフォーマンスを向上させます。 すべての blockchain にわたって smart contract システムのパワーが発揮されます。 このホワイトペーパーの他の 6 つの主要な焦点は、サービス内で機能するとみなされる場合があります。 ハイブリッド契約の最初の最も重要な契約の 1 つです。これらの焦点には、目に見えるものを取り除くことが含まれます ハイブリッド契約による複雑さにより、追加のオフチェーン サービスが作成され、 これまで以上に有能なハイブリッド契約の構築、および信頼の最小化の場合には、ハイブリッド契約によって達成されるセキュリティ特性が強化されます。アイデアは残しておきます ハイブリッド契約は文書の大部分で暗黙的に示されていますが、これらの組み合わせは、 DON を持つ MAINCHAIN ロジックは、ハイブリッド コントラクトとして見なすことができます。 複雑さを抽象化する: DON は、分散型を利用するように設計されています。 複雑になりがちな機構を抽象化することで、開発者とユーザーにとって使いやすいシステムを実現 DONs の強力で柔軟な一連のサービスの背後にあります。 既存の Chainlink サービス すでにこの機能を持っています。 たとえば、Chainlink のデータ フィードは、開発者がプロトコル レベルの詳細 (OCR がユーザー間でコンセンサス レポートを強制する手段など) を気にする必要のないオンチェーン インターフェイスを提供しています。 2オンチェーン/オフチェーンの契約構成という考え方は、これまでさまざまな制約条件の中で生じてきました。 レイヤー 2 システム、TEE ベースの blockchains [80] などのフォームをサポートし、一般化することが私たちの目標です。 これらのアプローチを採用し、オフチェーン データ アクセスやその他の重要な鍵を確実に包含できるようにします oracle サービス。 3Chainlink サービスは、さまざまな分散型サービスと機能で構成されます。 ネットワーク。これらは、さまざまな oracle ネットワークを構成する多数のノード オペレーターによって提供されます。 生態系全体で。図 2: オンチェーン/オフチェーンの契約構成を示す概念図。あ ハイブリッド smart contract 3⃝ 2 つの補完的なコンポーネントで構成されます: オンチェーン blockchain に常駐するコンポーネント SC 1⃝、およびオフチェーン コンポーネント exec 2⃝ DON で実行されます。 DON は 2 つのコンポーネント間のブリッジとしても機能します ハイブリッド コントラクトを Web サービスなどのオフチェーン リソースと接続するなど、 blockchains、分散ストレージなど。 分散されたノードのセット。 DON は、 Chainlink が開発者に提供できるサービス範囲 高レベルのサービスのための合理化されたインターフェイスが付属しています。 セクション 4 では、このアプローチを強調するいくつかの応用例を示します。 たとえば、企業が DONs を安全なミドルウェアの形式として使用して、 レガシー システムを blockchain に接続します。 (セクション 4.2 を参照してください。) この DON の使用により、一般的な blockchain ダイナミクス (手数料、再組織など) の複雑さが抽象化されます。それも 特定の blockchain の機能を抽象化することで、企業は既存のシステムを、ますます拡大する blockchain システムに接続することができます。 これらのシステム、またはより一般的には分散システム開発における専門知識が必要です。 最終的に、私たちの目標は、Chainlink によって達成される抽象度を高めることです。 私たちが分散型メタレイヤーと呼ぶものを実装するところまで。そんな層 すべてのクラスの開発者にとってオンチェーンとオフチェーンの区別が抽象化されます。 と DApps のユーザーにより、分散型サービスのシームレスな作成と使用が可能になります。開発プロセスを簡素化するために、開発者はメタレイヤーで DApp 機能を統合マシン モデルの仮想アプリケーションとして指定できます。彼らはできるだろう 次に、分散メタレイヤー コンパイラーを使用して、DApp を次のように自動的にインスタンス化します。 blockchains、DONs、および 外部サービス。 (これらの外部サービスの 1 つはエンタープライズ システムである可能性があり、メタレイヤーはレガシー エンタープライズ システムに関係するアプリケーションに役立ちます。) コンパイルは、最新のコンパイラーやソフトウェア開発キット (SDK) の仕組みに似ています。 異種ハードウェアの可能性を最大限に活用できるジェネラリスト プログラマーをサポートします。 汎用CPUとGPUなどの専用ハードウェアで構成されるアーキテクチャ、 機械学習アクセラレータ、または信頼されたエンクレーブ。図 3 は、このアイデアを概念的なレベルで示しています。 ハイブリッド smart contract は、このビジョンと、メタ コントラクトと呼ばれる概念への第一歩です。メタコントラクトは、分散型でコーディングされたアプリケーションです。 メタレイヤーに含まれ、オンチェーン ロジック (smart contracts) だけでなく、オフチェーンの計算と、さまざまな blockchain と既存のオフチェーン間の接続も暗黙的に包含されます。 サービス。言語とコンパイラのサポート、新しいセキュリティ モデル、および ただし、異種テクノロジーの概念的および技術的調和は実現可能 真の分散型メタレイヤーの実現は、私たちが長期にわたって目指している野心的な目標です 時間の地平線。それでも、これは、読んでいるときに覚えておくと役立つ理想的なモデルです。 この論文については、ここでは詳しく説明しませんが、今後の作業で焦点を当てていく予定です。 Chainlink。 スケーリング: 進化するデザインにおいて非常に重要な目標は、 Chainlink ネットワークは、blockchain エコシステムの増大するスケーリング ニーズに対応します。 既存のパーミッションレスではネットワークの輻輳が繰り返し問題になる中、 blockchains [86]、新しくてより高性能な blockchain デザインが使用され始めています。 例: [103, 120, 203]、および補完的なレイヤー 2 スケーリング技術 (例: [5, 12、121、141、169、186、187]。 Oracle サービスはレイテンシとスループットを達成する必要があります オンチェーン手数料を最小限に抑えながら、これらのシステムのパフォーマンス要求を満たします 契約事業者も一般ユーザーも同様に（例：ガス料金）。 DON、Chainlink を使用 この機能はさらに進化し、純粋な Web ベースのシステムに十分なパフォーマンスを提供することを目指しています。 DON は、パフォーマンス向上の多くを、blockchain と組み合わせた、高速な委員会ベースまたはパーミッションレスのコンセンサス プロトコルの使用から得ています。 彼らはサポートします。さまざまな構成の多くの DON が並行して実行されることが予想されます。さまざまな DApp とユーザーが、基礎となるコンセンサスの選択におけるトレードオフをナビゲートできる アプリケーション要件に応じて。 DON は、実質的にレイヤー 2 テクノロジーとみなされる場合があります。 私たちは次のことを期待しています 他のサービス、DONs はトランザクション実行フレームワーク (TEF) をサポートします。 DON、つまり oracle と他の高性能製品との効率的な統合が容易になります。 レイヤ 2 システム - 例: rollups、トランザクションをオフチェーンにバンドルして達成するシステム パフォーマンスの向上。 TEF についてはセクション 6 で紹介します。

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

図 3: 分散メタレイヤーの理想的な実現を示す概念図。のために 開発が容易なため、開発者は仮想アプリケーションとしてピンク色で強調表示された DApp を指定します。 統合されたマシンモデルでのアプリケーション。分散メタレイヤー コンパイラーは、対応する相互運用機能を自動的に生成します: smart contracts (示されています) SC による)、DONs 上のロジック (exec で示される)、ターゲットの外部サービスに接続するアダプターなど (黄色のハイライトで示されています)。 図 4 は、DON が blockchain (smart contract) スケーリングをどのように改善するかを概念的に示しています トランザクションとoracleレポートの処理をオフチェーンに集中させることで、 チェーン。計算の主な領域におけるこのシフトにより、トランザクションの待ち時間が短縮され、 トランザクションのスループットを向上させながら手数料を削減します。 機密保持: ブロックチェーンは、smart contract とそれが実現するアプリケーションに前例のない透明性を提供します。しかし、透明性と機密性の間には基本的な緊張関係があります。たとえば今日、ユーザーの分散型取引所の取引は、図 4: 分散型 Oracle ネットワークがどのようにネットワークを改善するかを示す概念図 blockchain 対応の smart contract のスケーリング。図A ⃝従来のoracleを示します 建築。トランザクションは、oracle レポートと同様に、blockchain に直接送信されます。 したがって、黄色で強調表示されている blockchain がトランザクション処理の主な場所です。図 B⃝は、blockchain のコントラクトをサポートするための DON の使用を示しています。 DON 実行可能ファイルは、外部システムからのデータとともにトランザクションを処理し、転送します。 結果 (バンドルされたトランザクションやトランザクションの影響による契約状態の変更など) を blockchain に送信します。したがって、黄色で強調表示されている DON がメインです トランザクション処理の場所。 アクションはチェーン上に記録されるため、交換の動作を簡単に監視できますが、 ユーザーの金融取引を一般に公開します。同様に、スマートに中継されるデータ 契約は連鎖的に残ります。これにより、そのようなデータは簡単に監査可能になりますが、次のように機能します。 smart contract に機密情報や機密データを提供したいと考えるデータプロバイダーにとっては阻害要因となります。 独自のデータ。 私たちは、oracle ネットワークが次世代の触媒となる重要な役割を果たすと信じています。 blockchains 本来の透明性と新しい機密保護を組み合わせたシステムです。このペーパーでは、次の 3 つの主なアプローチを使用して、どのようにそれを行うかを示します。 • 機密保持アダプター: 計画的に展開される 2 つのテクノロジー Chainlink のネットワーク、DECO [234] および Town Crier [233] では、oracle ノードが ユーザーのプライバシーとデータを保護する方法でオフチェーン システムからデータを取得する 機密保持。これらは、DON のアダプターの設計において重要な役割を果たします。 (これら 2 つのテクノロジーの詳細については、セクション 3.6.2 を参照してください。) • 機密の計算: DONs は、blockchains に依存しないように単純に計算を隠すことができます。安全なマルチパーティ コンピューティングや信頼できる実行環境を使用すると、DON ノードでの機密性を強化することも可能です。 それ自体が可視性を持たないデータを計算します。

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

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

• 機密のレイヤー 2 システムのサポート: TEF は、さまざまなレイヤー 2 システムをサポートするように設計されており、その多くはゼロ知識証明を使用して、 さまざまな形の取引機密保持。 これらのアプローチについてはセクション 3 で説明します (詳細はセクション 6、付録 B.1、および付録 B.2 で説明します)。 図 5 は、機密データが機密性保持アダプターおよび DON での機密計算。 図 5: DON における機密保持オペレーションの概念図 機密データ (黄色で強調表示)。 Web 内の機密ソース データ (黒丸) サーバーは、機密保持アダプター (青色の二重矢印線) を使用して DON に抽出されます。 DON は、これらのアダプターから派生データ (白丸) を受け取ります。 機密情報源に関数または秘密共有などを適用した結果 データ。 DON 上の実行可能ファイルは、派生データに機密計算を適用する可能性があります レポート (二重丸) を作成し、アダプター経由で blockchain に送信します。 私たちは、機密データを扱うための強力なツールによって、あらゆる問題が解決されると信じています。 応用範囲。 その中には、民間の分散型（および集中型）金融、分散型アイデンティティ、クレジットベースのオンチェーン融資、およびより効率的かつ効率的な融資が含まれます。 セクション 4 で説明する、ユーザーフレンドリーな顧客認識プロトコルと認定プロトコル。 トランザクションの注文の公平性: 今日のblockchainのデザインには少し汚れがあります 公然の秘密: これらは一時的に集中化されます。マイナーと validator は取引を注文できます。彼らが選択した行動。トランザクション順序は、ユーザーが次のように操作することもできます。 彼らが支払うネットワーク料金の関数 (例: Ethereum のガソリン価格) 高速ネットワーク接続を利用して、範囲を拡大できます。このような操作により、 たとえば、鉱山労働者などの戦略的主体がフロントランニングの形をとります。 ユーザーのトランザクションを監視し、独自の搾取的なトランザクションを以前のトランザクションに挿入します。 ユーザーの取引に関する事前の知識を利用して、ユーザーから効果的にお金を盗みます。たとえば、ボットが買い注文を出す場合があります。 ユーザーの前に。そして、それによって引き起こされる資産価格の上昇を利用することができます。 ユーザーの取引。 一般ユーザーに害を及ぼす一部のボットによるフロントランニング (高頻度に類似) ウォール街での取引 - 関連するものとして、すでに普及しており、十分に文書化されています [90] バックランニング [159] や [195] を模倣する自動トランザクションなどの攻撃。マイナーによる注文の搾取を体系化するという提案も、最近 [110] で浮上しています。 rollups などのレイヤー 2 テクノロジーは問題を解決するものではなく、単に再集中化するだけです 注文して、rollup を作成するエンティティの手に渡します。 私たちの目標の 1 つは、Chainlink に Fair Sequencing と呼ばれるサービスを導入することです。 サービス (FSS) [137]。 FSS は、smart contract デザイナーが公正な発注を保証するのに役立ちます ユーザー トランザクションや他のタイプのトランザクション (oracle レポート送信など) に対するフロントランニング攻撃、バックランニング攻撃、および関連する攻撃を回避します。 FSS DON は、[144] で導入された順序の公平性の厳密で時間的な概念などのアイデアを実装できるようになります。付随的な利点として、FSS はユーザーのネットワークを低下させることもできます 料金（ガソリン代など）。 簡単に説明すると、FSS では、トランザクションはターゲット smart contract に直接伝播するのではなく、DON を通過します。 DON はトランザクションを注文して転送します。 彼らを契約に結び付けます。 図 6: FSS がどのように役立つかの例。図A ⃝マイナーがその能力をどのように活用するかを示します。 トランザクションの注文権限を集中管理し、トランザクションのペアを交換する場合があります: トランザクション 1⃝ は 2⃝ より前に到着しますが、マイナーは代わりに 2⃝ より後に配列します。対照的に、図 B⃝ は次のようになります。 DON が DON ノード間で注文プロセスをどのように分散化するか。定足数が満たされている場合 正直なノードは 2⃝ の前に 1⃝ を受け取ります。FSS により、チェーン上で 1⃝ が 2⃝ の前に表示されます。 契約で強制可能なシーケンス番号を付加することで、マイナーの並べ替えを防止します。 図 6 は、標準マイニングと FSS を比較しています。標準的なマイニングでどのように行われるかを示しています。トランザクションの順序付けのプロセスはマイナーによって集中化されるため、 到着に応じてペアのトランザクションを並べ替えるなどの操作 回。対照的に、FSS では、プロセスは DON ノード間で分散されます。仮定すると 正直なノードのクォーラムである FSS は、ノードの一時的な順序付けなどのポリシーを強制するのに役立ちます。 トランザクションを保護し、マイナーやその他の組織による操作の機会を減らします。 また、ユーザーはガソリン価格に基づいて優先注文を競う必要がないため、 比較的低いガソリン価格を支払うことができます (DON からのトランザクションはバッチ処理できます) ガスの節約のため）。 信頼の最小化: DONs の設計における一般的な目的は、高度な設計を容易にすることです。 smart contract およびその他の oracle に依存するシステムの信頼できるサポート層 分散化、暗号化ツール、暗号経済的保証によって。 DON 自体は分散化されており、ユーザーは利用可能な DON から選択できます。 追加の DON を操作または生成するメイン チェーンをサポートします。 彼らが信頼するノードの委員会と。 ただし、一部のアプリケーション、特に smart contracts、Chainlink のユーザーは、 DON によってサポートされるメイン チェーンをより信頼できるものとして扱う信頼モデルを好む DON 自体よりも。そのようなユーザーのために、私たちはすでに、または導入する予定の Chainlink ネットワークのアーキテクチャ コントラクトを可能にする多数のメカニズム DONs によって提供されるセキュリティ保証を強化するためにメイン チェーン上で、 同時に、データ ソースが破損する可能性に対する保護も強化します。 DON がデータを取得する Web サーバーなど。 これらのメカニズムについてはセクション 7 で説明します。それらは 5 つの主要な見出しに分類されます。 • データソース認証: データプロバイダーがデジタル署名できるようにするツール データを収集し、それによって、発信元とデータの間の保管連鎖を強化します。 信頼できる契約。 • DON マイノリティ レポート: DON ノードのマイノリティ サブセットによって発行されるフラグ。 DON における大多数の不正行為を観察します。 • ガードレール: 異常な状態を検出して一時停止するメインチェーン上のロジック または契約の実行を停止します（または他の是正措置を講じます）。 • 信頼を最小限に抑えたガバナンス: コミュニティの検査を容易にするための段階的リリースのアップデートの使用と、迅速な対応のための分散型の緊急介入。 システム障害への対応。 • 分散型エンティティ認証: 公開キー基盤 (PKI) を使用して、 Chainlink ネットワーク内のエンティティを識別します。 図 7 は、信頼最小化の目標の概念図を示しています。 インセンティブベースの (暗号経済的) セキュリティ: oracle ノード間でレポート生成を分散化することで、一部のノードが破損した場合でもセキュリティを確保できます。

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

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

図 7: Chainlink の信頼最小化目標の概念図。 DON および Web などのデータ ソースの正しい動作に対するユーザーのニーズを最小限に抑える サーバー。図内の黄色のハイライトは、信頼最小化遺伝子座、DON および 個別または少数の Web サーバーのセット。ピンクのハイライトはシステムコンポーネントを示します 仮定により非常に信頼できるもの: blockchain と過半数に関する契約 Web サーバーの数、つまり Web サーバーの集合体。 ただし、同様に重要なのは、ノードが正しく動作するための経済的インセンティブを確保することです。ステーキング、つまりノードにリンクとスラッシュのデポジットを提供するよう要求する 不正行為があった場合にこれらの預金を没収することは、Chainlink において重要な役割を果たします。これは、すでに多くの blockchain で使用されている重要なインセンティブ デザインです。 例: [81、103、120、204]。 ただし、Chainlink でのステーキングは、スタンドアロンの staking とは大きく異なります。 blockchain秒。 blockchains へのステーキングは、コンセンサスへの攻撃を防ぐことを目的としています。それは Chainlink の別の目標: 正しい oracle レポートをタイムリーに配信すること。 oracle ネットワーク用に適切に設計された staking システムでは、贈収賄などの攻撃が行われるはずです たとえターゲットが高強度のsmart contractであっても、敵にとって利益はありません。 金銭的価値。 このペーパーでは、3 つのキーを使用した Chainlink の staking への一般的なアプローチを示します。 イノベーション:1. 既存の攻撃では見落とされていた攻撃を包含する強力な敵対的モデル 近づいてきます。一例として、いわゆる「見込贈収賄」が挙げられます。これは次の形式です どのノードが賄賂を受け取るかを条件に基づいて決定する賄賂。 staking メカニズムが選択したノードに事前に保証された賄賂を提供します。 特定の役割に対してランダム（レポートの裁定をトリガーするなど）。 2. 超線形 staking インパクト。非公式には、成功するには、敵対者はすべての oracle のデポジットの合計より $B 大きい予算を持っている必要があることを意味します。 ノード。 より正確には、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 では、さまざまな例を示します。 DON が魅力的な展開プラットフォームを提供するアプリケーション。読者は次のことを行うことができます ここまで読んで、この論文の主要な概念のほとんどを学びましょう。 この文書の残りの部分には、さらなる詳細が記載されています。公平な順序付けについて説明します サービス (FSS) についてはセクション 5 で、トランザクション実行フレームワーク (TEF) についてはセクション 6 で説明します。信頼の最小化に対するアプローチについてはセクション 7 で説明します。 重要な DON 展開要件、つまり機能の増分ロールアウト、動的な台帳メンバーシップ、セクション 8 の説明責任。最後に、セクション 9 で次のことを示します。 インセンティブ設計に対する当社の開発アプローチの概要。セクション 10 で結論を述べます。 この文書の概念についてあまり詳しくない読者を助けるために、 付録 A に用語集を記載しています。DON インターフェイスについてさらに詳しく説明します。 とその機能については付録 B で説明し、アダプタの例を付録 C でいくつか示します。 付録 D では、信頼を最小限に抑えたデータ ソースの暗号化プリミティブについて説明します。 認証は関数署名と呼ばれ、離散化関数署名と呼ばれる新しいバリアントが導入されます。委員会に関するいくつかの考慮事項について議論します 付録 F の DON の選択。

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

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

مقدمة

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

غالبًا ما يُنظر إلى 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.

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

الشكل 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 العقد حساب البيانات التي لا يمكنهم رؤيتها بأنفسهم.

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

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

• دعم أنظمة الطبقة الثانية السرية: تم تصميم 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 على ضمان الأمان حتى في حالة تلف بعض العقد.

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

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

الشكل 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.

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

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

セキュリティモデルと目標

分散型 Oracle ネットワークは、私たちが期待する独特の分散システムです。 必ずしもではありませんが、最初は通常、委員会ベースで実装されます。 コンセンサス プロトコルを使用し、oracle ノードのセットによって実行されます。 DON は主に設計されています oracle レポートを使用して、メイン チェーン上の smart contract の機能を強化します。 および他のサービスですが、同じサポート サービスを他の非blockchain システムに提供できるため、特定のメイン チェーンに関連付ける必要はありません。

したがって、私たちが考慮するモデルとプロパティは、 DON の特定の用途。 2.1 現在の建築モデル 現在の Chainlink はモノリシック サービスではなく、 個別の独立したプログラムを起動できる許可のないフレームワーク oracle ノード [77] のネットワーク。ネットワークには異種のノード オペレーターのセットがあり、 デザイン。また、提供するサービスの種類も異なる場合があります。 これには、データフィード、プルーフオブリザーブ、検証可能なランダム性などが含まれます。その他 違いには、分散化の程度、ネットワークのサイズなどが含まれます。 サポートするロック値、およびデータ頻度などのさまざまなサービスレベルパラメータ そして正確さ。 Chainlink のパーミッションレス モデルは、エコシステムの成長を促進します。 プロバイダーは、コミュニティに提供できる最善のサービスを専門としています。これ モデルは、モデルよりもユーザーのコストが低くなり、サービス品質が高くなる可能性があります すべてのノードとネットワークがあらゆる種類のサービスを提供する必要があるというアプローチ これは、最も少ないサービスのシステム全体への導入に容易に発展する可能性があります。 ノードが利用できるリソースの共通分母。 Chainlink が Chainlink 2.0 の DON ベースの設計に向けて進化するにつれて、私たちは引き続き という目標を念頭に置きながら、パーミッションレスでオープンなフレームワークのモデルをサポートします。 グローバルに最適な結果となる幅広いサービスの選択肢をユーザーに提供します 特定のアプリケーション要件を備えています。 2.2 コンセンサスの仮定 私たちは、分散型 Oracle ネットワークという用語を、次のすべての機能を包含するために使用します。 私たちが説明する oracle システム: oracle ノードが維持するデータ構造と その上にコア API が重ねられます。 基になるデータを意味するために、L で示されるレジャー (小文字) という用語を使用します。 DON によって維持され、それが提供する特定のサービスをサポートするために使用される構造。 私たちの DON フレームワークは L を次のような独立したシステムとして扱っていないことを強調します。 a blockchain: その目的は、blockchains およびその他のシステムをサポートすることです。ブロックチェーンとは、 もちろん、これは信頼できる台帳を実現する 1 つの方法ですが、他にも方法があります。期待しています DONs は多くの場合、ビザンチン フォールト トレラントを使用して基礎となる台帳を実現します。 (BFT) システム。Bitcoin [174] など、blockchain よりかなり古いものです。私たちが使用するのは 便宜上、BFT タイプの表記とプロパティを本書全体で使用していますが、 DONs はパーミッションレス コンセンサス プロトコルを使用して実現できることを強調します。 概念的には、台帳 L は、データが線形に順序付けされている掲示板です。 私たちは一般的に台帳には、一般的に考えられるいくつかの重要なプロパティがあると考えています。 blockchains [115]。台帳とは次のとおりです。 • 追加のみ: データは一度追加すると、削除したり変更したりすることはできません。• パブリック: 誰でもその内容を読むことができ、その内容は時代を超えて一貫しています。 すべてのユーザーのビュー。4 • 利用可能: レジャーは、許可された書き込み者によって常に書き込みおよび読み取りが可能です。 誰でもタイムリーに。 DON によって実現される場合、台帳内で代替プロパティが可能になります。 委員会。たとえば、台帳への書き込みアクセスは、次のように特定のユーザーに制限される場合があります。 一部のアプリケーションには読み取りアクセスが許可される場合があります。つまり、台帳は定義どおりに公開される必要はありません。 上。同様に、元帳ルールではデータの変更または編集が許可される場合があります。しません ただし、この論文ではそのようなバリアントを明示的に考慮します。 DON のモジュラー設計は、さまざまな最新の 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 の永続的な ID が有効になるためです。 それを実行しているノード。 (付録 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実際には、Hotstuff の亜種である LibraBFT [205] などの一部のコード ベースが現在採用しています。 しきい値署名ではなくマルチ署名により、通信の複雑さが軽減されます。 よりシンプルなエンジニアリング。コストを追加すると、oracle ノードはメッセージにしきい値署名を追加できます L に使用されるコンセンサス プロトコルがそれらを採用していない場合でも、L に書き込まれます。2.3 表記 台帳を実行する n 個の oracle ノードのセットを O = {Oi}n で表します。 i=1。 そんな ノードのセットは委員会と呼ばれることがよくあります。簡単にするために、次のセットがあると仮定します。 oracles の DON 機能、つまり L 上のサービスの実装は、 L は維持されますが、異なる場合もあります。 pki に次の公開鍵を示します。 プレーヤー Oi を取得し、対応する秘密鍵をスキーします。 ほとんどの BFT アルゴリズムでは、少なくとも n = 3f + 1 ノードが必要です。ここで、f はノードの数です。 潜在的に障害のあるノード。残りのノードは、以下に従うという意味で正直です。 プロトコルは指定どおりに実行されます。これを満たしている場合、委員会 O は誠実であるとみなします。 つまり、正直なノードの 2/3 部分を超えています。そうでない限り 前述したように、O は正直である (そして腐敗の静的モデルである) と仮定します。 pkO / を使用します。 skO は、文脈に応じて pkL / skL と同じ意味です。 σ = Sigpk[m] が pk に関するメッセージ m の署名を表すものとします。つまり、以下を使用します。 対応する秘密鍵 sk. verify(pk, σ, m) →{false, true} が対応する署名検証アルゴリズムを表すものとします。 (本稿では鍵の生成を暗黙的に残しておきます。) データ ソースを表すには S という表記を使用し、データ ソースの完全なセットを表すには S を使用します。 特定のコンテキスト内の nS ソース。 MAINCHAIN はスマートコントラクトが有効であることを示します blockchain は DON によってサポートされています。私たちは、信頼できるコントラクトという用語を、あらゆるスマートなサービスを表すために使用します。 DON と通信する MAINCHAIN 上のコントラクトを作成し、SC という表記を使用して そのような契約を指します。 セクション 4 の例で示すように、DON は単一のメイン チェーン MAINCHAIN をサポートすると想定していますが、複数のそのようなチェーンをサポートすることもできます。 DON は、MAINCHAIN で複数の依存コントラクトをサポートできますし、通常はサポートします。 (として 前述のように、DON は、blockchain 以外のサービスをサポートすることもできます。) 2.4 信頼モデルに関する注意事項 上で述べたように、DON は委員会ベースのコンセンサス プロトコルの上に構築される場合があります。 彼らはそのようなプロトコルを一般的に使用すると予想されます。多くの有力な議論がありますが、 2 つの選択肢 (委員会ベースまたは権限のない blockchain) のいずれかにより、以下が提供されます。 他よりも強力なセキュリティ。 委員会ベースとパーミッションレスのセキュリティは重要であることを認識することが重要です。 分散型システムは計り知れないものです。 PoW または PoS の侵害 blockchain via 51% 攻撃では、敵が過半数のリソースを一時的に取得する必要があり、 たとえば、PoW システムで hash 電力を借りるなど、潜在的に匿名で行われます。そんな 実際の攻撃はすでにいくつかのblockchainに影響を与えています[200、34]。対照的に、 委員会ベースのシステムを侵害するということは、ノードが公に知られ、十分なリソースがあり、 そして信頼できる存在。 一方、委員会ベースのシステム（および「ハイブリッド」パーミッションレス） 委員会をサポートするシステム）は、厳密に定義されている機能よりも多くの機能をサポートできます。ミッションレスシステム。これには、次のような永続的な秘密を維持する機能が含まれます。 署名キーや暗号化キー - 私たちの設計における可能性の 1 つです。 DON は原則として委員会ベースの、または パーミッションレスコンセンサスプロトコルと DON デプロイ担当者は最終的に採用を選択する可能性があります どちらかのアプローチ。 信頼モデルの強化: 現在の Chainlink の重要な機能は、ユーザーが次のことを実行できることです。 説明したように、パフォーマンス履歴の分散記録に基づいてノードを選択します。 セクション3.6.4に記載されています。セクション 9 で紹介する staking メカニズムと暗黙的インセンティブ フレームワークは合わせて、広範囲にわたる厳密なメカニズム設計を構成します。 このフレームワークにより、ユーザーは DON のセキュリティを評価できる機能が大幅に拡張されます。これと同じフレームワークにより、DON 自体も可能になります。 参加ノードにさまざまなセキュリティ要件を強制し、動作を保証するため 強力な信頼モデル内で。 このペーパーで説明されている DON のツールを使用して、規制要件への準拠など、特別な信頼モデル要件を強制することもできます。のために たとえば、セクション 4.3 で説明した手法を使用すると、ノードは次の証拠を提示できます。 ノードとオペレーターの特性 (例: 運用地域など)。 たとえば、一般データ保護規則 (GDPR) 第 3 条 (「適用範囲」) [105] への準拠を強制します。そうでなければ、このようなコンプライアンスは困難になる可能性があります 分散システム [45] で会います。 さらに、セクション 7 では、DON の堅牢性を強化する計画について説明します。 サポートするメインチェーンの信頼最小化メカニズムを通じて。

نموذج الأمن والأهداف

تعد شبكة 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 開発者インターフェイスと実行可能ファイルの機能について説明します。 コンピューティング システムを特徴付けるために通常使用される 3 つのリソース (ネットワーキング、コンピューティング、ストレージ) の観点からアダプターを説明します。これらのそれぞれについて簡単に概要を説明します 以下のリソースを参照し、付録 B で詳細を説明します。

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

3.1 ネットワーキング アダプターは、DON 上で実行される実行可能ファイルが送信および送信できるインターフェイスです。 DON のシステムからデータを受信します。アダプターは、以下を一般化したものと見なすことができます。 Chainlink で現在 [20] で使用されているアダプター。アダプターは双方向である場合があります。 DON から Web サーバーにデータをプルするだけでなく、プッシュすることもできます。彼らはまた、活用するかもしれません 分散プロトコルと安全なマルチパーティなどの暗号化機能 計算。 図 9: DON1 で示される DON を、DON2 で示される別の DON、blockchain (メイン チェーン) およびそのリソースを含むさまざまなリソースに接続するアダプター mempool、外部ストレージ、Web サーバー、IoT デバイス (Web サーバー経由)。 アダプターが作成される可能性のある外部リソースの例が示されています。 図 9 には次のものが含まれます。 • ブロックチェーン: アダプターはトランザクションを blockchain に送信する方法を定義でき、 そこからブロック、個々のトランザクション、またはその他の状態を読み取る方法。アダプター blockchain のメモリプールに対して定義することもできます。 (セクション 3.5 を参照してください。) • Web サーバー: アダプターは、データを取得するための API を定義できます。 Web サーバー (特別に適応されていないレガシー システムを含む) から DON とのインターフェース。このようなアダプターには、データを送信するための API を含めることもできます。 そのようなサーバー。 DON が接続する Web サーバーはゲートウェイとして機能する可能性があります モノのインターネット (IoT) デバイスなどの追加リソースにアクセスします。• 外部ストレージ: アダプタはストレージの読み取りおよび書き込みメソッドを定義できます。 分散型ファイル システム [40、188] やクラウドなど、DON の外部のサービス 保管。 • その他の DON: アダプターは、DON 間でデータを取得および送信できます。 DONs の初期展開には一連の構成要素が含まれることを期待しています このような一般的に使用される外部リソース用のアダプターが追加され、DON 固有の DON ノードによって公開されるアダプター。 smart contract 開発者がアダプターを作成するとき 今日、私たちは彼らがこの高度な機能を使用してさらに強力なアダプターを構築することを期待しています。 機能性。 最終的にはユーザーが新しいアダプターを作成できるようになると期待しています。 許可のないやり方。 一部のアダプターは、DON によって制御される外部リソースの永続性と可用性を保証する方法で構築する必要があります。たとえば、クラウド ストレージでは、 クラウド サービス アカウントのメンテナンスが必要です。さらに、DON は次のことを実行できます。 ユーザーに代わって秘密鍵を分散管理する ([160] など) および/または 実行可能ファイル。その結果、DON は、ターゲット blockchain でトランザクションを送信するなどに使用できる、暗号通貨などのリソースを制御できます。 DON アダプターの詳細については付録 B.1 を参照してください。一部のアダプターについては付録 C を参照してください。 アダプターの例。 3.2 計算 実行可能ファイルは、DON 上のコードの基本単位です。実行可能ファイルは exec = のペアです。 (ロジック、初期化)。ここで、ロジックは指定されたエントリを多数持つ決定的なプログラムです。 ポイント (logic1、logic2、...、logicℓ) および init は対応するイニシエーターのセットです (init1、init2、...、inite)。 DON の完全な監査可能性を確保するには、実行可能ファイルのロジック すべての入力と出力に対して基礎となる元帳 L を使用します。したがって、たとえば、どのアダプターでも 実行可能ファイルへの入力として機能するデータは、最初に L に保存する必要があります。 イニシエーター: 現在、Chainlink のイニシエーターにより、イベントに依存したジョブが実行されます。 Chainlink ノード [21]。 DONs のイニシエーターは、ほぼ同じように機能します。ただし、DON イニシエーターは、具体的には実行可能ファイルに関連付けられます。イニシエーターは依存する可能性があります 外部のイベントまたは状態、現在の時刻、または DON 状態の述語に基づいて。 イベントに依存しているため、イニシエーターは当然ながら非決定的に動作する可能性があります。 (もちろんアダプターも同様です)。イニシエーターは個々の DON ノード内で実行できます したがって、アダプターに依存する必要はありません。 (以下の例 1 を参照してください。) イニシエーターは、実行可能ファイルと smart contract を区別する重要な機能です。 実行可能ファイルはイニシエーターに応答して実行できるため、効率的に動作できます。 もちろん、拡張により、実行可能ファイルを組み込んだハイブリッド コントラクトを自律的に実行できます。現在のイニシエーターの 1 つの形式は、トランザクションを提供する Chainlink キーパーです。oracle レポートに基づいて、smart contract 実行 (担保不足ローンの清算や指値注文取引の実行など) をトリガーする自動化サービス。 便利なことに、DONs のイニシエーターは、 実行可能ファイルに適用されるサービス契約。サービス契約は以下の状況を定義します。 DON はこれを呼び出す必要があります。 次の例は、実行可能ファイル内でイニシエーターがどのように動作するかを示しています。 例 1 (偏差によってトリガーされる価格フィード)。 smart contract SC には新しいものが必要な場合があります 価格フィードデータ (セクション 3.6.3 を参照) に大幅な変化 (例: 1%) があるときは常に 資産ペア間の為替レート（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⟩ という形式のエントリ。 2 番目のイニシエーター init2 は、新しい価格を持つそのような PriceView エントリーが少なくとも k 個あるときに起動します。 個別のノードによって作成されたインデックス j + 1 の値が L に蓄積されます。その後、init2 エントリ ポイントのロジック 2 を呼び出して、最初の k 個の新鮮な有効なpriceview 値の中央値 ρ を計算し、新しい値 ⟨NewPrice : j + 1, ρ⟩ を L に書き込みます。 (運用上、ノードは 交代で指定作家となる場合があります。） 3 番目のイニシエーター init3 は、L 上の NewPrice エントリーを監視します。新しいレポートが作成されるたびに、 そこに ⟨NewPrice : j, r⟩ が表示され、(j, r) を SC にプッシュするエントリ ポイント ロジック 3 が呼び出されます。 アダプターを使用して。 すでに述べたように、実行可能ファイルの機能は smart contract と似ています。 ただし、パフォーマンスが高いことは別として、典型的なメインチェーン契約とは異なります。 2 つの重要な方法で: 1. 機密性: 実行可能ファイルは機密の計算を実行できます。つまり、秘密のプログラムが平文入力を処理したり、公開されたプログラムが処理したりできます。 秘密の入力データ、または両方の組み合わせ。単純なモデルでは、機密データは次のようになります。 DON ノードからアクセスできます。中間結果は隠蔽され、のみが公開されます。 処理およびサニタイズされた値を MAINCHAIN に送信します。 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 は権限を与えることができません メインチェーン上で作成された資産 (例: Ether または ERC20 tokens) を表します。 彼らのネイティブチェーンは、彼らの所有権の信頼できる記録を維持します。 (c) ライフサイクル: DON は、次のように、限られたライフタイムで意図的に起動される場合があります。 DON と所有者との間のオンチェーン サービス レベル アグリーメントによって定義される 依存契約の。 対照的に、ブロックチェーンは次のように機能することを目的としています。 永久アーカイブシステム。 DON 計算の詳細については、付録 B.2 を参照してください。 3.3 ストレージ 委員会ベースのシステムとして、DON は適度な量のデータを永続的に保存できます L では、権限のない blockchain よりもはるかに低コストで利用できます。さらに、アダプターを介して、 DONs は、ファイルコイン [85] など、データ ストレージ用の外部分散システムを参照できます。 これにより、そのようなシステムを smart contract に接続できるようになります。このオプションは特に 蔓延する「肥大化」の問題に対処する手段として、大量のデータにとって魅力的です。 blockchain システム。 したがって、DON は、特定のサポートされているサービスで使用するためにデータをローカルまたは外部に保存できます。 DON はさらに、そのようなデータを機密性の高い方法で利用できます。 次のようなデータを計算します: (1) DON ノード間で秘密が共有されているか、または暗号化されている 安全なマルチパーティ計算に適した方法で DON ノードによって管理されるキー または部分的または完全な準同型暗号化。または (2) 信頼できる実行を使用して保護される 環境。 DONs は、 スマート コントラクト システム: 実行可能ファイルは、それ自体のメモリにのみ書き込むことができます。実行可能ファイル ただし、他の実行可能ファイルのメモリから読み取ることはできます。 DON ストレージの詳細については、付録 B.3 を参照してください。 3.4 トランザクション実行フレームワーク (TEF) DON は、メイン チェーン MAINCHAIN (または複数のメイン チェーン) でコントラクトをサポートすることを目的としています。トランザクション実行フレームワーク (TEF) について詳しく説明しますセクション 6 では、契約を効率的に実行するための汎用アプローチです。 MAINCHAIN および DON にわたる SC。 TEF は、FSS とレイヤー 2 をサポートすることを目的としています。 必要に応じて、テクノロジーを同時に利用できます。まさに主力車両として活躍しそうです FSS の使用のためです (そのため、このセクションでは FSS についてはこれ以上説明しません)。 簡単に言うと、TEF では、MAINCHAIN 用に設計または開発されたオリジナルのターゲット コントラクト SC ハイブリッド コントラクトにリファクタリングされます。このリファクタリングにより、2 つの相互運用性が生成されます。 ハイブリッド コントラクトの一部: 明確にするために参照する MAINCHAIN コントラクト SCa TEF のコンテキストではアンカー コントラクトとして、実行可能ファイルは DON 上で実行されます。の 契約SCaはユーザーの資産を保管し、権限のある状態遷移を実行し、また DON の障害に対するガード レール (セクション 7.3 を参照) を提供します。実行可能ファイル exec トランザクションをシーケンスし、それらに関連する oracle データを提供します。同梱可能です 有効性証明ベースの使用や、 楽観的なrollup、DONによる機密実行など。 開発者が契約を簡単に分割できるツールの開発を期待しています。 高級言語で MAINCHAIN および DON ロジックの部分に書かれた SC、SCa および それぞれ実行され、安全かつ効率的に構成されます。 TEF を使用して高パフォーマンスのトランザクション スキームと高パフォーマンスのトランザクション スキームを統合する oracles は、oracle スケーリング アプローチに不可欠です。 3.5 メンプールサービス サポート対象の DONs にデプロイする予定の重要なアプリケーション層機能 FSS および TEF は Mempool Services (MS) です。 MS はアダプターと見なすこともできますが、 ただし、一流のサポートが付いています。 MS は、レガシー互換のトランザクション処理のサポートを提供します。この用途では、MS ターゲットコントラクトを対象としたトランザクションをメインチェーンのメモリプールから取り込みます メインチェーン上の SC。その後、MS はこれらのトランザクションを DON 上の実行可能ファイルに渡します。 目的の方法で処理されます。 MS データは DON で使用できます DON から SC に直接渡すことができるトランザクションを作成する、または SC を呼び出す別のコントラクトに接続します。たとえば、DON はトランザクションを転送できます。 MS 経由で収集することも、MS データを使用して送信先のトランザクションのガス価格を設定することもできます メインチェーン。 MS はメモリプールを監視するため、SC と直接対話するユーザーからトランザクションを取得できます。したがって、ユーザーは引き続き次を使用してトランザクションを生成できます。 レガシー ソフトウェア、つまり MS および MS で構成されたアプリケーションの存在を認識しないアプリケーション 契約。 (この場合、元のトランザクションを無視するように SC を変更する必要があります。 二重処理を避けるために、MS によって処理されたもののみを受け入れます。) ターゲット契約 SC で使用する場合、MS は FSS および/または TEF で使用できます。3.6 ステッピング ストーン: 既存の Chainlink 機能 3.6.1 オフチェーンレポート (OCR) オフチェーン レポート (OCR) [60] は、oracle レポートの集約と依存コントラクト SC への送信のための Chainlink のメカニズムです。最近Chainlink価格で導入されました フィード ネットワークでは、完全な DON へのパスに沿った最初のステップを表します。 OCR の核心は、部分同期で動作するように設計された BFT プロトコルです。 ネットワーク。 f < n/3 の存在下での生存性と正確性を任意に保証します 障害のあるノードは、ビザンチンの信頼できるブロードキャストの特性を保証しますが、そうではありません。 完全な BFT コンセンサス プロトコル。ノードは次のようなメッセージ ログを維持しません。 すべてのビューで同一の台帳を表すという意味での一貫性。 そして、プロトコルのリーダーは、安全性を侵害することなく曖昧な発言をする可能性があります。 OCR は現在、特定のメッセージ タイプ、つまり中央値化されたメッセージ タイプ向けに設計されています。 (少なくとも 2f +1) の値が参加ノードによって報告されます。重要な保証を提供します。 SC に対して出力するレポートは、証明済みレポートと呼ばれます。 証明済みレポートの中央値 レポートは、2 つの正直なノードによってレポートされた値と等しいか、その間にあります。この物件は OCR の重要な安全条件。リーダーは中央値に何らかの影響を与える可能性がある ただし、この正当性条件のみが条件となります。 OCRできる さまざまな方法で値を集計するメッセージ タイプに拡張できます。 Chainlink ネットワークの稼働性と正確性の今日の目標では、 OCR が本格的なコンセンサス プロトコルであるためには、従来の BFT プロトコルには存在しないいくつかの追加形式の機能を提供するために OCR が必要です。特に注目すべきは次のとおりです。 1.オール・オア・ナッシングのオフチェーン・レポート・ブロードキャスト: OCRにより、証明されたレポートが確実に送信されます。 すべての正直なノードがすぐに利用できるようになるか、どのノードも利用できないようになります。これは公平性です 正直なノードが参加する機会を確実に得るのに役立つプロパティ 証明されたレポート送信において。 2. 信頼性の高い送信: OCR により、欠陥や悪意のあるデータが存在する場合でも確実に送信されます。 すべての OCR レポートとメッセージが特定のノード内で SC に送信されること、 事前定義された時間間隔。これは活性プロパティです。 3. 契約ベースの信頼の最小化: SC は、たとえば、報告された値が他の値と大きく異なる場合など、誤った可能性がある OCR 生成レポートを除外します。 最近受け取ったもの。これは、プロトコル外の正確性の強制の一種です。 これら 3 つのプロパティはすべて、DON で自然な役割を果たします。オール オアナッシング オフチェーン (DON) ブロードキャストは、暗号経済保証の重要な構成要素です 信頼性の高い伝送が重要であり、これがアダプターの重要な特性となります。信頼 セクション 7.3 で説明したように、SC の最小化は一種のガード レールです。 OCR は、Chainlink の oracle ネットワークにおける BFT プロトコルの運用展開と改良のための基盤も提供するため、前述したように、完全なネットワークへの道が提供されます。 DON の機能。3.6.2 DECOとタウンクライヤー DECO [234] と Town Crier [233] は、現在開発されている 2 つの関連テクノロジーです。 Chainlink ネットワークで開発されました。 現在、ほとんどの Web サーバーでは、ユーザーはプロトコルを使用して安全なチャネル経由で接続できます。 Transport Layer Security (TLS) [94] と呼ばれます。 (HTTPS は、HTTP のバリアントを示します。 TLS が有効になっています。つまり、「https」という接頭辞が付いている URL は、セキュリティのために TLS を使用していることを示します。) ただし、ほとんどの TLS 対応サーバーには、デジタル署名が行われないという顕著な制限があります。 データ。したがって、ユーザーまたは証明者はサーバーから受け取ったデータを提示できません。 oracle や smart contract などの第三者または検証者に、 データの信頼性。 たとえサーバーがデータにデジタル署名したとしても、機密性の問題が残ります。証明者は、機密データを提出する前に編集または変更したい場合があります。 検証者。ただし、デジタル署名は、変更されたデータを無効にするために特別に設計されています。したがって、証明者が機密保持のための変更を行うのを防ぎます。 データに。 (詳細については、セクション 7.1 を参照してください。) DECO と Town Crier は、証明者が Web からデータを取得できるように設計されています。 サーバーに保存し、完全性と機密性が保証される方法で検証者に提示します。 2 つのシステムは、提供されるデータが確実に保持されるという意味で整合性を維持します。 証明者から検証者への送信は、ターゲット サーバーから確実に発信されます。彼らはサポートします 証明者がデータを編集または変更できるようにするという意味での機密性（まだ 完全性の維持）。 両方のシステムの主な特徴は、システムを変更する必要がないことです。 ターゲットWebサーバー。これらは、既存の TLS 対応サーバーであればどれでも動作できます。実際、 それらはサーバーに対して透過的です。サーバーの観点から見ると、証明者は次のようになります。 通常の接続を確立します。 2 つのシステムは同様の目標を持っていますが、ここで簡単に説明するように、信頼モデルと実装が異なります。 DECO は、暗号化プロトコルを基本的に利用して完全性を実現します そして機密性のプロパティ。 DECO を使用してターゲット サーバーとのセッションを確立している間、証明者は同時に、ターゲット サーバーとの対話型プロトコルを実行します。 検証者。このプロトコルにより、証明者は、自分が受け取ったものを検証者に証明することができます。 現在のセッション中にサーバーからの特定のデータ D 。証明者は次のことを行うことができます 代わりに、D の何らかのプロパティのゼロ知識証明を検証者に提示します。 したがって、D を直接明らかにすることはありません。 DECO の一般的な使用法では、ユーザーまたは単一ノードがプライベート データベースからデータ D をエクスポートできます。 DON 内のすべてのノードに対する Web サーバーとのセッション。その結果、完全な DON は、 D (またはゼロ知識証明によって D から導出された事実) の信頼性を証明します。 この文書で後ほど説明するサンプル アプリケーションに加えて、この機能は次のようにすることができます。 DON によるデータ ソースへの高整合性アクセスを増幅するために使用されます。ノードが 1 つだけであっても たとえば、との排他的取り決めにより、データ ソースに直接アクセスできます。 データプロバイダー - DON 全体がデータの正確さを証明することが可能です。そのノードによって発行されたレポート。 Town Crier は、Intel などの信頼できる実行環境 (TEE) の使用に依存しています。 SGX。簡単に言うと、TEE はアプリケーションを実行する一種のブラック ボックスとして機能します。 改ざん防止と機密性の高い方法。原則として、ホストの所有者であっても、 実行中の TEE は、TEE で保護されたアプリケーションを (検出されずに) 変更することも、 アプリケーションの状態を表示します。これには機密データが含まれる場合があります。 タウンクライエは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 やその他の今日の分散システム。 説明どおりのさらなる進化 このホワイトペーパーでは、これらの既存のサービスに追加の機能を与え、 届く。 3 つの例は次のとおりです。 データフィード: 現在、smart contract に依存している Chainlink ユーザーの大多数は、 データフィードの使用。これらは、主要なデータ部分の現在の値に関するレポートです。 信頼できるオフチェーンの情報源に送信します。たとえば、価格フィードは価格を報告するフィードです。 によると、仮想通貨、コモディティ、外国為替、インデックス、株式などの資産の 交換またはデータ集約サービス。このようなフィードは今日すでに数十億ドルの安全を確保するのに役立っています Aave [147] や シンセティクス [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 は、指定されたフィードを同時にセットにプッシュできます さまざまな blockchain を使用できるため、チェーンごとの oracle ネットワークが不要になり、 新しい blockchain および追加のフィードの既存のフィードの迅速なデプロイメントを可能にします。 現在サービスされている blockchain にわたるフィード。 • 機密性: DON で一般化された計算を実行できる機能により、機密データの計算をオフチェーンで実行できるようになり、オンチェーンを回避できます。 露出。 また、DECOやタウンクライエを利用することで、 機密性がさらに強化され、非公開データに基づいたレポート生成が可能になります。 DON ノードにも公開されます。例については、セクション 4.3 およびセクション 4.5 を参照してください。 検証可能なランダム関数 (VRF): いくつかの種類の DApp は、自身の公正な動作を検証できるように、検証可能な正しいランダム性ソースを必要とします。 代替不可能なトークン (NFTs) がその例です。 Aavegotchi [23] および Axie Innity [35] の NFT フィーチャーの希少性は、分布と同様に Chainlink VRF によって決まります。 Ether カード [102] のチケットベースの描画による NFT 件。多種多様な 結果がランダム化されるゲーム DApps。および非伝統的な金融商品、たとえば、PoolTogether [89] などの損失のない貯蓄ゲームなど、 ランダムな勝者。他のblockchainおよびblockchain以外のアプリケーションも安全なセキュリティを必要とします 分散システム委員会の選択や、 宝くじの実施。 ブロック hashes は予測不可能なランダム性のソースとして機能する可能性がありますが、敵対的なマイナーによる操作に対して脆弱です (また、ある程度はユーザーの送信による操作に対しても脆弱です) トランザクション）。 Chainlink VRF [78] は、より安全な代替手段を提供します。アン oracle には、秘密鍵と公開鍵のペア (sk、pk) が関連付けられており、その秘密鍵はオフチェーンで維持され、公開鍵 pk は公開されます。ランダムな値を出力するには、 依存コントラクト (ブロック hash など) によって提供される予測不可能なシード x に sk を適用します。 および DApp 固有のパラメーター）関数 F を使用して、y = Fsk(x) と、 正しさの証明。 (Chainlink で利用可能な VRF については、[180] を参照してください。) VRF が検証可能であるということは、pk の知識があれば、証明の正しさ、したがって y の正しさをチェックできるという事実です。したがって、値 y は、ユーザーにとって予測不可能です。 x を予測したり、sk を学習したりすることができず、サービスが操作することは不可能な敵対者。Chainlink VRF は、オフチェーンの秘密キーの管理を伴うアプリケーション ファミリの 1 つにすぎないとみなされる場合があります。より一般的には、DON は安全なセキュリティを提供します。 アプリケーションおよび/またはユーザーの個別のキーの分散ストレージ、およびそれらの組み合わせ この機能は一般化された計算で実現されます。その結果、多数のアプリケーションが作成されます。 このホワイトペーパーでは、Proof of of のためのキー管理を含むいくつかの例を示します。 リザーブ (セクション 4.1 を参照) およびユーザーの分散型認証情報 (およびその他のデジタル情報) 資産) (セクション 4.3 を参照)。 キーパー: Chainlink Keepers [87] により、開発者は分散型のコードを作成できます オフチェーン ジョブの実行。通常は依存する smart contract の実行をトリガーします。 Keepers が登場する前は、開発者がこのようなオフチェーンを運用するのが一般的でした。 ロジックそのものが原因で、集中的な障害点が発生します (また、かなりの重複した開発作業も発生します)。キーパーは代わりに、使いやすいフレームワークを提供します。 これらの業務の分散型アウトソーシングにより、開発サイクルの短縮と 生存性およびその他のセキュリティ特性の強力な保証。キーパーは何でもサポートできます 価格に応じたローンの清算や、 金融取引の実行、時間に応じたエアドロップまたは支払いの開始 収量収穫を伴うシステムなど。 DON フレームワークでは、イニシエーターは、さまざまな意味でキーパーを一般化したものと見なすことができます。イニシエータはアダプタを利用することができるため、 オンチェーンおよびオフチェーン システムへのインターフェイスのモジュール化されたライブラリにより、迅速な 安全で洗練された機能の開発。イニシエーターは計算を開始します 実行可能ファイル自体が DON の完全な多用途性を提供し、幅広い機能を可能にします。 このホワイトペーパーでは、オンチェーンおよびオフチェーンのアプリケーション向けにさまざまな分散サービスを紹介します。 3.6.4 ノードの評判/パフォーマンス履歴 既存の Chainlink エコシステムは、パフォーマンス履歴をネイティブに文書化します。 チェーン上のノードに貢献します。この機能により、個人のパフォーマンス データを取り込み、フィルタリングし、視覚化する評判指向のリソースのコレクションが誕生しました。 ノードオペレーターとデータフィード。ユーザーはこれらのリソースを参照して情報を得ることができます ノードの選択における決定と、既存のネットワークの運用の監視を行います。 同様の機能は、ユーザーが DON を選択するのに役立ちます。 たとえば、今日のmarket.linkなどのパーミッションレスマーケットプレイスでは、ノードが許可されています。 オペレータは、oracle サービスをリストし、オフチェーン ID を証明します。 Keybase [4] などのサービス。Chainlink のノードのプロファイルをそのノードにバインドします。 所有者の既存のドメイン名とソーシャルメディアアカウント。さらに、パフォーマンス マーケット.リンクやレピュテーション.リンクで入手可能な分析ツールなどを使用すると、 ユーザーは、個々のノードの履歴パフォーマンスに関する統計を表示できます。 平均応答待ち時間、コンセンサス値からのレポートの値の偏差 チェーンで中継され、生み出された収益、達成された仕事など。これらの分析ツールも ユーザーが他のユーザーによるさまざまな oracle ネットワークの採用を追跡できるようにします。このようなネットワークを保護するノードの暗黙の承認。その結果、平坦な「ウェブ」が形成されます。 「信頼」。特定のノードを使用することで、高価値の分散アプリケーションが 他のユーザーがそれを観察して考慮に入れることができる、それらのノードに対する信頼のシグナル。 独自のノード選択決定。 DONs (および最初は OCR) により、トランザクション処理が変化し、 契約アクティビティは、より一般的にはオフチェーンです。レコーディングノードの分散モデル DON 自体の内部でもパフォーマンスは引き続き可能です。まさに、高性能 DONs のデータ容量により、きめ細かいレコードの構築が可能になります。 これらのレコードに対して分散計算を実行し、レピュテーション サービスで使用したりチェックポイントを作成したりできる信頼できる概要を生成します。 メインチェーン。 原理的には、大部分のノードが破損している場合、DON が構成ノードの動作を誤って表現する可能性がありますが、集合的な オンチェーン データの配信における DON 自体のパフォーマンスは MAINCHAIN で確認できます したがって、誤って伝えることはできません。さらに、 DON でノードの動作に関する正確な内部レポートを奨励します。たとえば、貢献するデータを最も早く返す高性能ノードのサブセットを報告することによって、 チェーン上で中継されるレポートに対して、DON はノードが不正な内容に異議を唱えるインセンティブを生み出します。 レポート: このサブセットにノードが誤って含まれているということは、ノードが誤って除外されていることを意味します これは含まれるべきであったため、無効に罰せられるべきでした。 DON によるレポートの失敗が繰り返されると、誠実なノードがそのシステムから離脱するインセンティブも生成されます。 DON。 正確なパフォーマンス履歴とその結果の分散型編集 ユーザーが高性能ノードを特定し、ノードオペレーターが構築できる能力 評判は、Chainlink エコシステムの重要な特徴です。 私たち セクション 9 で、これらを厳密な分析の重要な部分としてどのように推論できるかを示します。 DONs によって提供される経済的安全性の広範なビュー。

واجهة شبكة أوراكل اللامركزية وCa-

القدرات نحن هنا نرسم بإيجاز قدرات DONs من حيث البساطة ولكن القوية الواجهة التي تم تصميمها لتحقيقها. تتكون التطبيقات الموجودة على DON من ملفات تنفيذية ومحولات. الملف القابل للتنفيذ هو برنامج منطقه الأساسي هو برنامج حتمي، مشابه لـ smart contract. يحتوي الملف القابل للتنفيذ أيضًا على عدد من البادئين المصاحبين، وهي البرامج التي تستدعي الدخول نقاط في منطق الملف القابل للتنفيذ عند وقوع أحداث محددة مسبقًا، على سبيل المثال، في أوقات معينة (مثل وظيفة كرون)، عندما يتجاوز السعر الحد الأدنى، وما إلى ذلك - يشبه إلى حد كبير الحراس (انظر القسم 3.6.3). توفر المحولات واجهات للموارد خارج السلسلة ويمكن استدعاؤها بواسطة إما البادئين أو المنطق الأساسي في الملفات التنفيذية. لأن سلوكهم قد يعتمد على ذلك من الموارد الخارجية، قد يتصرف البادئون والمحولون بطريقة غير حتمية. نحن نصف واجهة المطور DON وعمل الملفات التنفيذية و المحولات من حيث الموارد الثلاثة المستخدمة عادةً لوصف أنظمة الحوسبة: الشبكات والحوسبة والتخزين. ونقدم لمحة موجزة عن كل واحدة منها الموارد أدناه وتقديم المزيد من التفاصيل في الملحق ب.

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

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.

分散化によって実現される分散化サービス

オラクルネットワークス DONs の多用途性と、それらがどのように新しいサービスのホストを可能にするかを説明するには、次のようにします。 このセクションでは、DON ベースのアプリケーションの 5 つの例を示し、 それらを実現するハイブリッド契約: (1) クロスチェーン サービスの一形態である Proof of Reserves。 (2) エンタープライズ/レガシーシステムとのインターフェース、つまりミドルウェアベースのシステムの作成 最小限の要素で blockchain アプリケーションの開発を容易にする抽象化レイヤー blockchain 固有のコードまたは専門知識。 (3) 分散型アイデンティティ、ユーザーが次のことを可能にするツール 自分自身の身分証明書と資格情報を取得して管理する。 (4) 優先チャンネル、 重要なインフラストラクチャのトランザクションをタイムリーに含めることを保証するサービス (例: oracle) レポート) blockchain について。 (5) 機密保持 DeFi、つまり財務 参加当事者の機密データを隠すsmart contract。 ここで、私たちは

SC を使用してハイブリッド コントラクトの MAINCHAIN 部分を示し、DON を記述します。 コンポーネントを個別に、または実行可能ファイル exec として。 4.1 準備金の証明 多くのアプリケーションでは、blockchain 間で状態を中継すると便利です。あ このようなサービスの一般的な用途は、暗号通貨のラッピングです。ラッピングされたコインなど WBTC [15] は分散型金融 (DeFi) で人気の資産になりつつあるためです。彼らは 「ラップされた」バッキング資産をソース blockchain MAINCHAIN(1) にデポジットすることが含まれます。 そして、対応する token を別のターゲット blockchain MAINCHAIN(2) に作成します。 たとえば、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 が動作する可能性があります。 多数のカストディアンの中の 1 人として、または単一の分散型カストディアンとして、 ラップされたアセット。これにより、DONs は、セキュリティを強化するプラットフォームとして機能します。 Proofs of Reserves を使用する既存のサービス。 たとえば、MAINCHAIN(1) が Bitcoin で、MAINCHAIN(2) が Ethereum であるとします。 MAINCHAIN(2) では、コントラクト SC がラップされた BTC を表す token を発行します。 DON BTC アドレス addr(1) を制御します DON。 BTC をラップするには、ユーザー U が X BTC を送信します。 アドレス(1) U アドレス(1)へ DON と MAINCHAIN(2)-address addr(2) U 。 DON モニター アドレス(1) DON アダプタ経由で MAINCHAIN(1) に接続します。 U のデポジットを観察すると、十分に高い確率で確認が得られ、アダプタを介して SC にメッセージを送信します。 メインチェーン(2)。このメッセージは、SC に addr(2) の X token を作成するように指示します。 U 。 U が X token を解放すると、その逆が起こります。 ただし、MAINCHAIN(1) では、 アドレス(1) DON は X BTC を addr(1) に送信します U (またはユーザーが要求した場合は別のアドレス)。 もちろん、これらのプロトコルは、直接ではなく交換機と連動するように適合させることができます。 ユーザーと一緒に。 4.2 エンタープライズ/レガシー システムとのインターフェース DON は、Proof の例のように、blockchain 間のブリッジとして機能します。 しかし、もう一つの目的は、保護区間の双方向の橋渡し役として機能することです。 blockchain およびレガシー システム [176] または blockchain のようなシステム (中央銀行など) デジタル通貨 [30]。 企業は、既存のシステムとネットワークを接続する際に多くの課題に直面しています。 以下を含む分散システムへのプロセス。• ブロックチェーンの俊敏性: ブロックチェーン システムは急速に変化します。企業は、blockchain の急速な新たな出現や人気の上昇に直面する可能性があります。 取引相手は取引を希望しているが、企業にはそれに関する権限がない。 既存のインフラストラクチャでのサポート。一般的に、blockchains のダイナミズムは 個々の企業が完全なエコシステムに遅れを取らないようにすることは困難です。 • ブロックチェーン固有の開発リソース: 多くの組織にとって、最先端のblockchain専門知識を雇用または育成することは、特に次のような観点から困難です。 敏捷性への挑戦。 • 秘密鍵の管理: blockchains または暗号通貨の秘密鍵を管理するには、従来のサイバーセキュリティとは異なる運用上の専門知識が必要です。 慣行であり、多くの企業は利用できません。 • 機密性: 企業は機密情報や専有情報を公開することを懸念しています。 チェーン上のデータ。 これらの問題のうち最初の 3 つに対処するには、開発者は DON を使用するだけで済みます。 エンタープライズ システムの読み取りまたは書き込みを可能にする安全なミドルウェア層として blockchain秒。 DON は、次のような詳細な技術的考慮事項を抽象化できます。 ガスダイナミクス、チェーンの再編成など、開発者とユーザーの両方に役立ちます。によって 合理化された blockchain インターフェイスをエンタープライズ システムに提供することで、DON は blockchain 対応のエンタープライズ アプリケーションの開発が大幅に簡素化され、blockchain 固有の開発リソースを取得または育成するという企業の負担が軽減されます。 DONs のこのような使用法は、エンタープライズ開発者が次のことを可能にするという点で特に魅力的です。 blockchain にほとんど依存しないスマート コントラクト アプリケーションを作成します。その結果、 DON がミドルウェアとして機能するように設定されている blockchain のセットが大きい場合、 企業ユーザーが簡単にアクセスできる blockchain のセットが大きくなります。開発者 最小限の変更で既存の blockchain から新しいアプリケーションにアプリケーションを移植できます 社内で開発されたアプリケーションに。 機密保持というさらなる問題に対処するために、開発者は、 この文書で紹介するツールは、DON アプリケーションをサポートするために導入される予定です。 これらには、DECO および Town Crier セクション 3.6.2 および機密保持が含まれます。 API の変更についてはセクション 7.1.2 で説明し、アプリケーション固有のいくつかのアプローチについてはこのセクションの残りの部分で説明します。これらのDON システムは次のことを提供できます。 エンタープライズ システムの状態を明らかにすることなく、高整合性のオンチェーン認証を行う 機密性の高いエンタープライズ ソース データがチェーン上に存在します。 4.3 分散型アイデンティティ 分散型アイデンティティは、ユーザーが次のことができるべきであるという概念の一般用語です。 サードパーティに依存するのではなく、独自の資格情報を取得して管理する そう。分散型資格情報は、所有者の属性または主張に対する証明書です。これらはしばしばクレームと呼ばれます。資格情報は、エンティティによってデジタル署名されます。 発行者は、権限を持ってクレームをユーザーに関連付けることができます。提案されているスキームのほとんどでは、 クレームは、分散型識別子 (DID)、つまり汎用識別子に関連付けられています。 特定のユーザー。資格情報は、ユーザーがその秘密鍵を保持する公開鍵にバインドされます。 したがって、ユーザーは自分の秘密鍵を使用して請求の所有を証明できます。 分散型アイデンティティとしての先見性は、既存のスキームと提案されたスキームです。例: [14、92、 129, 216] には 3 つの重大な制限があります。 • レガシー互換性の欠如: 既存の分散型 ID システムは、 発行者と呼ばれる当局のコミュニティが DID 認証情報を生成します。なぜなら 既存の Web サービスは通常、データにデジタル署名を行わないため、発行者が立ち上げる必要がある 特殊な目的のシステムとして。なぜなら、 分散型アイデンティティ エコシステムでは、卵が先か鶏が先かの問題が発生します。その他では つまり、発行者のエコシステムをどのようにブートストラップするかは不明です。 • 機能しないキー管理: 分散型 ID システムでは、ユーザーは次のことを行う必要があります。 秘密鍵の管理、暗号通貨の経験が示していること 実行不可能な負担になること。約 4,000,000 Bitcoin が被害を受けたと推定されています。 鍵管理の失敗 [194] により永久に失われ、多くのユーザーが 暗号資産を取引所 [193] と共有することにより、分散化が損なわれます。 • プライバシーを保護するシビル耐性の欠如: 投票、token 販売中の token の公平な割り当てなどのアプリケーションの基本的なセキュリティ要件は、次のとおりです。 ユーザーは複数の ID を主張できません。既存の分散型アイデンティティ提案では、そのようなことを実現するために、ユーザーが現実世界のアイデンティティを明らかにする必要があります。 シビル耐性により、重要なプライバシー保証が損なわれます。 ノードの委員会を組み合わせて使用することで、これらの問題に対処することが可能です。 DON 内で分散計算を実行し、DECO などのツールを使用する または、CanDID [160] と呼ばれるシステムに示されている Town Crier。 DECO または Town Crier は、設計により既存の Web サービスを変更せずに変えることができます 機密性を保持する資格情報の発行者に。これらにより、DON が関連するファイルをエクスポートできるようになります。 この目的のためのデータを認証情報に含める一方、機密データを隠す必要はありません。 資格情報に表示されます。 さらに、ユーザーのキー回復を容易にし、キー管理の問題に対処します。 問題として、DON を使用すると、ユーザーは秘密鍵を秘密共有形式で保存できるようになります。ユーザーは次のことができます DON 内のノードに証明することでキーを回復します。同様に、Town Crier または DECO - 所定の Web プロバイダーのセットを使用してアカウントにログインする機能 (例: ツイッター、グーグル、フェイスブック）。 Town Crier または DECO を使用する利点は、 OAUTH はユーザーのプライバシーです。これら 2 つのツールを使用すると、ユーザーは DON への暴露を回避できます。 Web プロバイダーの識別子。多くの場合、そこから現実世界の ID を導き出すことができます。 最後に、[160] に示すように、シビル耐性を提供するには、DON で次のことが可能です。 ユーザーの一意の実世界識別子のプライバシーを保護する変換を実行する (社会保障番号 (SSN) など) をユーザー登録時にオンチェーン識別子に変換します。これにより、システムは、次のような機密データを使用せずに重複した登録を検出できます。 SSN は個々の DON ノードに公開されます。7 DON は、外部の分散型 ID に代わってこれらのサービスのいずれかを提供できます 許可のないまたは許可された blockchain 上のシステム (例: Hyperledger のインスタンス) インディ [129]。 アプリケーション例: KYC: 分散型アイデンティティは、次の手段として有望です。 ユーザーの利便性を向上させながら、blockchains の金融アプリケーションの要件を合理化します プライバシー。解決に役立つ 2 つの課題は、マネーロンダリング防止 / 顧客確認 (AML / KYC) 規制に基づく認定とコンプライアンス義務です。 多くの国の AML 規制では、金融機関 (およびその他の企業) に対して、取引先の個人および企業の身元を確認し、確認することが求められています。 彼らは取引を実行します。 KYC は金融機関のコンポーネントの 1 つを形成します。 より広範な AML ポリシーには、通常、特にユーザーの行動の監視や資金の流れの監視も含まれます。 KYC には通常、何らかの形式 (例: ユーザーの顔の前に身分証明書をかざしてオンライン Web フォームに入力する ビデオセッションなど）。分散型認証情報の安全な作成と提示 原理的には、いくつかの点で有益な代替手段となり得る。すなわち、(1) KYC プロセスは、ユーザーと金融機関にとってより効率的になります。 資格情報が取得されれば、あらゆる金融機関にシームレスに提示できます。 (2) 侵害による個人情報の盗難の機会を減らすことで不正行為を減らす 個人識別情報 (PII) の流出およびビデオ検証中のなりすまし。そして (3) ユーザーがコントロールを保持できるため、金融機関における PII 侵害のリスクが軽減されます。 自分自身のデータの。 AMLコンプライアンス違反に対して金融機関が支払った数十億ドルの罰金と、多くの金融機関がKYCに年間数百万ドルを費やしていることを考慮すると、改善は金融機関にかなりの節約をもたらす可能性がある さらに言えば、消費者向け[196]。伝統的な金融セクターの動きが遅い一方で、 新しいコンプライアンス ツールを採用するために、DeFi システムでは [43] を採用するケースが増えています。 適用例: 担保不足のローン: ほとんどのDeFiアプリケーションは、 現在のサポート融資は、完全に担保された融資のみを組成しています。これらは融資です 融資額を超える仮想通貨資産を預けている借り手に。 最近、DeFi コミュニティで一般に過少担保ローンと呼ばれるものに関心が高まっています。対照的に、これらは対応する担保が設定されているローンです。 ローンの元本よりも価値が低いもの。担保不足のローン 従来の金融機関が行うローンによく似ています。依存するのではなく ローン返済の保証として預けられた担保に基づいて融資を行うのではなく、 借り手の信用履歴に基づく決定。 7この変換は分散擬似乱数関数 (PRF) に依存しています。担保不足のローンは、DeFi 融資市場において初期段階ではあるものの、成長を続けている部分を構成しています。彼らは伝統的な金融機関が採用しているようなメカニズムに依存しています。 法的契約 [91] などの機関。彼らの成長に不可欠な要件 従来の融資決定における重要な要素であるユーザーの信用力に関するデータを、強力な整合性を提供する方法で DeFi システムに提供できるようになります。 正しいデータの保証。 DON 対応の分散型 ID システムにより、借り手希望者は次のことが可能になります。 信用力を維持しながら、信頼性の高い認証情報を生成します。 機密情報の機密性。具体的には、借り手はこれらを生成できます 信頼できるオンライン ソースからの記録に基づく認証情報のみを公開しながら、 他の潜在的な機密データを公開することなく、DON によって証明されたデータ。のために たとえば、借り手は自分の信用スコアが 一連の信用調査機関は、彼女を明らかにすることなく、特定のしきい値 (例: 750) を超えます。 彼女の記録にある正確なスコアやその他のデータ。さらに、必要に応じて、そのような資格情報 匿名で生成できます。つまり、ユーザーの名前は機密データとして扱われます。 そして、それ自体は oracle ノードや分散認証情報に公開されません。資格情報 それ自体は、アプリケーションに応じてチェーンまたはオフチェーンで使用できます。 要約すると、借り手は自分の信用に関する重要な情報を貸し手に提供できます。 強い整合性を持ち、不必要で機密性の高い情報が漏洩するリスクのない履歴 データ。 借り手は、機密保持のためのその他のさまざまな認証情報を提供することもできます。 融資の決定に役立ちます。たとえば、資格情報は借り手の本人であることを証明できます。 次の例で示すように、(オフチェーン) 資産の所有。 アプリケーション例: 認定: 多くの管轄区域では、未登録証券を販売できる投資家の種類が制限されています。たとえば、米国では SEC 規則 D では、そのような投資機会に対して認定されるためには、 個人は 100 万ドルの純資産を所有しているか、特定の最低収入要件を満たしているか、特定の専門的資格を持っている必要があります [209, 210]。現在の認定 プロセスは煩雑で非効率的であり、多くの場合、 会計士、または同様の証拠。 分散型 ID システムにより、ユーザーは次の情報から資格情報を生成できます。 認定への準拠を証明する既存のオンライン金融サービス口座 規制を強化し、より効率的でプライバシーを保護した KYC プロセスを促進します。 の さらに、DECO と Town Crier のプライバシー保護特性により、これらのことが可能になります。 認証情報は、ユーザーの経済状況の詳細を直接明らかにすることなく、完全性が強力に保証されて生成されます。たとえば、ユーザーは資格情報を生成できます。 それ以上のことを明らかにすることなく、彼女が少なくとも100万ドルの純資産を持っていることを証明する 彼女の経済状況に関する情報。 4.4 優先チャンネル プライオリティ チャネルは、DON を使用して簡単に構築できる便利な新しいサービスです。彼らの

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

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

目標は、厳選された優先度の高いトランザクションをメインチェーン上でタイムリーに配信することです ネットワークが混雑しているとき。優先チャネルは、次のような形式と見なすことができます。 ブロック空間上の先物契約、したがって暗号商品としての一部として造られた用語 プロジェクト・シカゴ [61, 136]。 優先チャネルは、特にマイナーがoracle、契約のガバナンス機能などのインフラストラクチャ サービスを有効にすることを目的としており、金融取引などの通常のユーザーレベルのアクティビティを対象とするものではありません。 実際、ここで設計されているように、優先順位は ネットワーク内のマイニング電力の 100% 未満によって実装されたチャネルは、 配信時間に緩やかな制限を設け、速度に大きく依存する用途での使用を防止します。 先制ゴールなど。 図 10: 優先チャネルはマイナー M による保証です。より一般的には、 マイナーのセット M - ユーザー U に、彼女のトランザクション τ が D ブロック内でマイニングされることを通知します。 mempool に含めるかどうか。契約 SC は、DON モニタリングを使用して、 チャンネルのサービス規約。 優先チャネルは、マイナーまたはマイナーのセット間の合意の形をとります。 チャネルを提供する（またはマイニングプール）M と、アクセス料金を支払うユーザー U です。 M は、U がトランザクション τ をメモリプールに送信するとき (任意のガス価格で、ただし、事前に合意されたガス制限）、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 がマイニングするトランザクションを U が送信すると、成功メッセージが SC に送信されます。 タイムリーな方法と、サービス障害の場合の障害メッセージ。 SC は成功メッセージを受け取って $p の支払いを M に送信し、残りの資金をすべて送信します。 $d を含み、失敗メッセージを受信した場合は U に送信されます。正常に終了すると、 M に $d のデポジットをリリースします。 もちろん、マイナー M は複数のユーザーに優先チャネルを同時に提供することもできます。 ユーザーは、事前に合意された数のメッセージに対して U を使用して優先チャネルを開くことができます。 4.5 機密保持 DeFi / Mixicles 現在、DeFi アプリケーション [1] は、ユーザーに対して機密性をほとんど、あるいはまったく提供していません。すべてのトランザクションはチェーン上で表示されます。さまざまなゼロ知識ベースのアプローチ、例: [149、217]、 トランザクションのプライバシーを提供でき、TEF はそれらをサポートするのに十分な汎用性を備えています。でも これらのアプローチは包括的ではなく、たとえば、通常、 トランザクションの基礎となる資産。 DONs で最終的にサポートする予定の広範な計算ツールのセットは、 このようなギャップを埋めるさまざまな方法でプライバシーを確保し、他のシステムのプライバシー保証を補完するのに役立ちます。たとえば、Chainlink 研究所の研究者 [135] によって提案された機密保持 DeFi 機器である Mixicles は、 金融商品を裏付ける資産タイプであり、DON に非常に自然に適合します。 フレームワーク。 ミクシクルは、単純なバイナリを実現するために使用するという観点から最も簡単に説明されます。 オプション。 バイナリー オプションは 2 人のユーザーが参加する金融商品です。 プレーヤーとしての [135] との一貫性については、ここを参照してください。2 つの可能性があるイベントに賭けます 結果、たとえば、事前に指定された時点で資産が目標価格を超えるかどうか。 次の例は、このアイデアを示しています。 例 2. アリスとボブは、資産の価値に基づくバイナリー オプションの当事者です。 キャロルのバブルトークン（CBT）と呼ばれます。アリスは、CBT の市場価格が になると賭けます。 2025 年 6 月 21 日の T = 正午時点で最低 250 米ドル。ボブは逆に賭けます。各プレイヤー 事前に指定された期限までに 100 ETH を入金します。勝ちポジションを持つプレイヤー 200 ETHを受け取ります（つまり、100 ETHを獲得します）。 もちろん、8D は、M が高い確率に準拠できることを保証するのに十分な大きさでなければなりません。 のために たとえば、M がネットワーク内のマイニング電力の 20% を制御している場合、D = 100 を選択する可能性があります。 故障確率は ≈2 × 10−10、つまり 10 億分の 1 未満です。既存の Chainlink oracle ネットワーク O を考慮すると、スマートなネットワークを実装するのは簡単です。 例 2 の合意を実現する契約 SC。2 人のプレーヤーがそれぞれ入金します。 SCで100ETH。 T の後のある時点で、クエリ q が O に送信され、商品の価格 r が要求されます。 時間 T.O の CBT は、この価格のレポート r を SC に送信します。その後、SC はアリスに送金します。 r ≥250 の場合はボブ、そうでない場合はボブ。ただし、このアプローチではチェーン上の r が明らかになり、簡単になります。 オブザーバーがバイナリー オプションの基礎となる資産を推測できるようにします。 Mixicles の用語では、結果を概念的に考えると役立ちます。 述語として計算されたバイナリ値を送信するスイッチに関する SC の スイッチ(r)。この例では、r ≥250 の場合は switch(r) = 0 になります。この結果を考えると、アリスが勝ちます。 それ以外の場合は、switch(r) = 1 となり、ボブが勝ちます。 DON は、実行可能ファイルを実行することで、基本的な Mixicle をハイブリッド コントラクトとして実現できます。 switch(r) を計算し、それをチェーン上で SC に報告する exec。この構造を示します 図11に示す。 図 11: 例 2 の基本的な Mixicle の図。 レポート r、つまりバイナリー オプションの基礎となる資産を、oracle が バイナリ値スイッチのみを介して SC を契約します (r)。 これを簡単に実現できるアダプター ConfSwitch を付録 C.3 で指定します。 DONでゴール。 ConfSwitch の基本的な考え方は非常にシンプルです。報告する代わりに 値 r の場合、ConfSwitch はバイナリ スイッチ値 switch(r) のみを報告します。 SCは可能です switch(r) のみ、および switch(r) 自体に基づいて正しい支払いを行うように設計されています。 原資産 (この例では CBT) に関する情報は明らかにされません。さらに、 pkaud で暗号化された台帳上の (q, r) に暗号文を配置することにより、 アダプターの ConfSwitch は、機密性を保持する監査証跡を作成します。 ここでの説明を簡単にするために選択した基本的な Mixicle は、 この例では、バイナリー オプションの背後にある資産と賭け金です。本格的な Mixicle [135] は次のことができます。 2 つの形式の機密保持を提供します。それは観察者からは次のことを隠します: (1) どのような出来事が起こったか プレイヤーは（つまり、q と r）だけでなく、（2）どのプレイヤーが賭けに勝ったかにも賭けます。 Mixicles は MAINCHAIN 上で実行されるため、どちらかのプレイヤーが中継する必要があります。 DON から MAINCHAIN に switch(r) するか、実行可能 exec が作成される可能性があります。

ConfSwitch による出力でトリガーされ、別のアダプターを呼び出してスイッチ(r) を送信します。 メインチェーン。 3 番目の微妙な種類の機密保持も考慮する価値があります。 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. بهم

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

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

الهدف هو تقديم معاملات مختارة وذات أولوية عالية في الوقت المناسب على 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 が提供すると予想される、ネットワーキング、計算、ストレージ機能を活用した重要なサービスの 1 つは、Fair Sequencing Services (FSS) と呼ばれます。 FSS は単に DON フレームワーク内で実現されるアプリケーションとして見なされるかもしれませんが、私たちは FSS を、あらゆる分野で需要が高いと思われるサービスとして強調しています。 blockchains、Chainlink ネットワークが積極的にサポートすることが期待されます。 パブリック blockchain ネットワーク上で実行すると、今日の DeFi アプリケーションの多くが ユーザーが自分の利益のために悪用できる情報を明らかにする。 既存の組織に蔓延している内部関係者の漏洩や操作の機会の種類 市場[64、155]。その代わりに、FSS は公平な DeFi エコシステムへの道を開きます。 FSS 開発者が市場操作から保護されたDeFi契約を構築するのに役立ちます 情報漏洩によるもの。以下で強調する問題を考慮すると、FSS は レイヤ 2 サービスにとって特に魅力的であり、そのようなサービスのフレームワーク内に適合します これについてはセクション 6 で説明します。 課題: 既存のパーミッションレス システムでは、トランザクションは完全に順序付けされます 鉱山労働者の裁量で。許可されたネットワークでは、validator ノードが影響を与える可能性があります。 同じ力。これは、ほとんど認識されていない一時的な集中化の一形態です。 それ以外の場合は分散システム。マイナーはトランザクションを（一時的に）検閲することができます。 [171] 自身の利益を最大化するか、自身のゲインを最大化するためにそれらを並べ替えます。これは、採掘可能値 (MEV) [90] と呼ばれる概念です。 MEV という用語は少し欺瞞的です。つまり、MEV を指すものではありません。 マイナーがキャプチャできる値のみ: 一部の MEV は一般ユーザーがキャプチャできます。 ただし、マイナーは通常のユーザーよりも大きな権限を持っているため、MEV は、あらゆるエンティティが敵対的な並べ替えを通じて取得できる価値の量の上限を表します。 および補完的なトランザクションの挿入。マイナーが単純にトランザクションを注文する場合でも、 料金（ガス）に基づいて、操作することなく、ユーザー自身がガス価格を操作できます 洗練されていない取引よりも取引を有利にするため。 大安ら。 [90] ボット (マイナーではない) が実行する方法を文書化して定量化します。 今日のDeFiシステムのユーザーに害を及ぼすガス力学の利点とその方法 MEV は、blockchain の基礎となるコンセンサス層の安定性さえ脅かします。 トランザクション注文操作の他の例は定期的に表示されます ([50, 154] など)。rollups などの新しいトランザクション処理メソッドは、非常に有望なアプローチです 高スループット blockchain のスケーリングの問題に対処します。しかし、彼らは言及していない MEVの問題。代わりに、rollup を生成するエンティティにそれをシフトします。それ smart contract のオペレーターであるか、(zk-)rollup に提供するユーザーであるかに関係なく、エンティティ 有効性の証明であり、トランザクションを注文して挿入する権限があります。つまり、rollups MEV と REV: ロールアップ抽出可能な値を交換します。 MEV は、メモリプールに送信された今後のトランザクションに影響します。 しかし、まだチェーン上にコミットされていません。このような取引に関する情報は広範に提供されます。 ネットワークで利用可能です。マイナー、validator、および一般のネットワーク参加者は、 したがって、この知識を利用して依存トランザクションを作成します。さらに、マイナーと validator は、コミットするトランザクションの順序に影響を与える可能性があります。 自分自身を攻撃し、これを自分たちの利益のために利用します。 合意に基づく取引順序に対するリーダーによる不当な影響の問題 プロトコルは 1990 年代から文献で知られていました [71, 190] が、満足のいくものはありませんでした。 解決策はこれまでに実際に実現されています [97]。 主な理由は、提案されたソリューションが、少なくともごく最近までは、公共のソリューションに容易に統合できなかったことです。 blockchains、トランザクションの内容がその後まで機密に保たれることに依存しているため 彼らの順番は決まっています。 Fair Sequencing Services (FSS) の概要: DONs は、トランザクションの順序を分散化し、依存者によって指定されたポリシーに従って実装するためのツールを提供します。 契約作成者、理想的には公平で、契約を希望する関係者に有利にならないもの トランザクションの順序を操作します。これらのツールは集合的に FSS を構成します。 FSS には 3 つのコンポーネントが含まれています。 1 つ目はトランザクションの監視です。 FSSでは、 O の oracle ノードは両方とも MAINCHAIN のメモリプールを監視し、(必要に応じて) 許可します 特殊なチャネルを介したオフチェーンでのトランザクションの送信。 2 つ目はトランザクションの順序付けです。 O のノードは依存コントラクトのトランザクションを注文します その契約に対して定義されたポリシーに従って。 3つ目は取引の転記です。 トランザクションが注文された後、O のノードは共同でトランザクションを メインチェーン。 FSS の潜在的な利点は次のとおりです。 • 注文の公平性: FSS には、開発者がトランザクションを確実に実行できるように支援するツールが含まれています。 特定の契約への入力は、不公平を生じない方法で命令される。 リソースが豊富なユーザーや技術的に精通したユーザーにとっては有利です。注文ポリシー この目的のために指定できます。 • 情報漏洩の削減または排除: ネットワーク参加者が今後のトランザクションに関する知識を悪用できないようにすることで、FSS を軽減または排除できます。 入手可能な情報に基づいたフロントランニングのような攻撃を排除します。 トランザクションがコミットされる前にネットワークにアクセスします。そのような悪用を防止する 漏洩により、元の保留中のトランザクションに依存する敵対的なトランザクションが確実に実行されます。 元のトランザクションがコミットされるまでは、トランザクションを台帳に入力することはできません。• トランザクションコストの削減: プレイヤーが提出する際のスピードの必要性を排除することにより、 トランザクションを smart contract に制限することで、FSS はトランザクション処理のコストを大幅に削減できます。 • 優先順位: FSS は重要なトランザクションに自動的に特別な優先順位を与えることができます。 注文すること。たとえば、oracle に対する前線攻撃を防ぐため レポート (例: [79])、FSS はトランザクションのストリームに oracle レポートを挿入できます 遡及的に。 DONs における FSS の包括的な目標は、DeFi クリエイターが公平性を実現できるようにすることです。 金融システム、つまり、特定のユーザー（またはマイナー）に利益をもたらさないシステム スピード、内部知識、または技術的な実行能力に基づいて他の人よりも優れている 操作。公平性の明確な一般的な概念はとらえどころがなく、完璧な公平性は FSS は、開発者に強力な機能を提供することを目的としています。 DeFi の設計目標を達成するのに役立つポリシーを適用できるツール セット。 FSS の主な目標は、公平な順序付けサービスとして機能することですが、 DON がターゲットとする MAINCHAIN、FSS と同じ公平性の要求の一部 保証は、複数のユーザー間で実行される (分散型) プロトコルにも適している可能性があります。 DON パーティー。したがって、FSS はサブセットによって提供されるサービスとしてより広く見ることができます。 MAINCHAIN のユーザーによって送信されたトランザクションだけでなく、公正に順序付けする DON ノード 他の DON ノード間で共有されるトランザクション (つまり、メッセージ) も同様です。このセクションでは、 ここでは主に、MAINCHAIN トランザクションの順序付けという目標に焦点を当てます。 セクションの構成: セクション 5.1 では、FSS の設計を動機付ける 2 つの高レベルのアプリケーションについて説明します。oracle レポートのフロントランニングの防止と、レポートのフロントランニングの防止です。 ユーザートランザクションのフロントランニング。次に、FSS の設計についてさらに詳しく説明します。 セクション5.2に記載されています。セクション 5.3 では、公正な注文の保証と手段の例について説明します それらを達成するために。最後に、セクション 5.4 とセクション 5.5 では、ネットワーク レベルの脅威について説明します。 ネットワークフラッディングとシビルそれぞれに対するそのようなポリシーとそれに対処する手段 攻撃します。 5.1 最前線の問題 FSS の目標と設計を説明するために、フロントランニングの 2 つの一般的な形式について説明します。 攻撃と既存のソリューションの制限。 フロントランニングはクラスを体現する トランザクション順序付け攻撃の割合: バックランニングやサンドイッチング (フロントランニングとバックランニング) [237] など、ここでは取り上げていない関連攻撃が多数あります。 ここでは、FSS も解決に役立ちます。 5.1.1 オラクルのフロントランニング blockchain アプリケーションにオフチェーン データを提供するという従来の役割では、oracles 前線攻撃の自然なターゲットになります。oracle を使用してさまざまな価格フィードを提供する一般的な設計パターンを検討してください。 オンチェーン取引所へ: oracle は定期的に (たとえば 1 時間ごとに) 価格データを収集します。 異なる資産を取得し、これらを交換契約に送信します。これらの価格データ取引 明らかな裁定取引の機会が存在します: たとえば、最新の oracle レポートのリストに 一部の資産の価格がはるかに高い場合、攻撃者は oracle レポートを前倒しで実行する可能性があります。 資産を買い占め、oracle の報告が処理されたらすぐに転売してください。 スピードバンプと遡及価格設定: oracle の最前線の問題に対する自然な解決策は、oracle レポートに他のトランザクションよりも特別な優先順位を与えることです。のために たとえば、oracle レポートは、マイナーに処理を奨励するために高額な料金で送信される可能性があります。 まずは彼らから。しかし、裁定取引の機会が高い場合、これはフロントランニングを妨げるものではありません。 また、マイナー自身による裁定取引を防ぐこともできません。 そのため、一部の取引所は、ユーザーのトランザクションを処理する前にいくつかのブロックのキューに入れるなど、より強力な「スピードバンプ」の実装に頼っています。 または、新しい oracle レポートが到着したときに価格を遡及的に調整します。これらのソリューションの欠点は、交換の実装が複雑になることです。 ストレージ要件が増加し、その結果、トランザクションコストが増加し、資産の交換がかなりの期間を経た後にのみ確認されるため、ユーザーエクスペリエンスが混乱します。 便乗: FSS に進む前に、ピギーバックについて説明します。 oracle の最前線の問題に対する洗練された解決策。住所には適用されません ただし、他のシナリオでは最前線で実行されます。 つまり、オンチェーン コントラクトに定期的にレポートを送信する代わりに、oracles ユーザーが売買時に取引に追加する署名付きレポートを公開する オンチェーン資産。その後、交換はレポートが有効で新しいことを確認するだけです (例: oracle は、レポートが有効なブロックの範囲に署名できます)、および抽出 そこからの関連する価格フィード。 このシンプルなアプローチには、上記の「スピードバンプ」に比べて多くの利点があります。 アプローチ: (1) 取引所契約は価格フィードの状態を保持する必要はありません。 取引コストの削減につながります。 (2) oracle レポートは必要に応じてチェーンに投稿されるため、oracle はより頻繁な更新 (例: 1 分ごと) を生成できます。 レポートのフロントランニングによる裁定取引の機会を最小限に抑える9。 (3) トランザクションは次のとおりです。 常に最新の価格フィードが含まれるため、すぐに検証できます。 ただし、このアプローチは完璧ではありません。まず、この便乗ソリューションでは、 取引所のユーザーには、最新の oracle レポートを取得してレポートに添付する義務があります。 取引。第二に、相乗りは裁定取引の機会を最小限に抑えることはできますが、 オンチェーンコントラクトの有効性に影響を与えることなく、それらを完全に防止します。確かに、もし oracle レポートはブロック番号 n まで有効で、その後トランザクションがブロックに送信されます。 n + 1 には、新しい有効なレポートが必要になります。伝播に固有の遅延があるため、 oracles からユーザーにレポートを送信すると、ブロック n + 1 に対して有効な新しいレポートは次のようになります。 9 裁定取引は、利用可能な資産価格の差が無関係な価格差を超える場合にのみ価値がある。 資産の売買に必要な手数料（採掘者や取引所が徴収するものなど）。ブロック n + 1 がマイニングされる前に、たとえばブロック n −k で公開されるため、 短期間のアービトラージの機会が存在する k ブロックのシーケンスを作成します。私たち 次に、FSS がこれらの制限をどのように回避するかを説明します。 FSS を使用した oracle レポートの優先順位付け: FSS は oracle の最前線の問題に対処できます 上記の相乗りソリューションに基づいて問題を解決しますが、追加のソリューションをプッシュします。 oracle レポートを使用してトランザクションを強化する作業は、分散型 Oracle ネットワークに報告されます。 高いレベルでは、oracle ノードはオンチェーン交換に向けたトランザクションを収集します。 リアルタイムの価格フィードに同意し、収集されたトランザクションとともに価格フィードをメインチェーン コントラクトにポストします。概念的には、このアプローチは次のように考えることができます。 「データ拡張トランザクション バッチ処理」。oracle により、 価格フィードは常にトランザクションに追加されます。 FSS ソリューションは、取引所のユーザーに対して透過的に実装できます。 セクション 5.2 で詳しく説明するように、契約ロジックへの変更は最小限に抑えられます。確保する 新しい oracle レポートがユーザー トランザクションよりも常に優先されることは、ほんの一例にすぎません FSS が採用および強制できる順序付けポリシー。金監院の秩序確保方針 公平性については、セクション 5.3 でより一般的に説明されています。 5.1.2 フロントランニング ユーザー トランザクション ここで、上記の防御方法が適用される一般的なアプリケーションでのフロントランニングに移ります。 機能しません。この問題は、次のシナリオを通じて幅広く捉えることができます。 攻撃者は、P2P ネットワークに送信されたユーザー トランザクション tx1 を確認し、 独自の敵対的なトランザクション tx2 を使用して、tx2 が tx1 よりも前に処理されるようにします（たとえば、支払いによって） 取引手数料が高くなります）。たとえば、この種の先走りは、 DeFi システム [90] の裁定取引の機会を悪用し、次のユーザーに影響を与えたボット さまざまな分散アプリケーション [101]。取引間に公正な秩序を課す blockchain で処理されると、この問題が解決されます。 もっと基本的には、tx1 の詳細を確認する必要すらない場合もあります。 その単なる存在を知っているだけで、敵対者はその存在を介して tx1 をフロントランできる可能性があります。 tx2 を所有し、tx1 を作成した無実のユーザーを騙します。たとえば、ユーザーは次のようにします。 定期的に特定の資産を取引することが知られています。このような攻撃を防ぐには、次のことが必要です メタデータの漏洩も回避する緩和策 [62]。この問題に対するいくつかの解決策 存在しますが、遅延やユーザビリティ上の懸念が生じます。 ネットワーク注文から FSS による確定注文まで: 前線で活躍する機会 既存のシステムには、順序を保証するメカニズムがないために発生します。 トランザクションはイベントの順序と情報の流れを尊重してチェーン上に表示されます ネットワークの外側。これは、blockchain 上のアプリケーション (取引プラットフォームなど) の実装の不備から生じる問題を表しています。理想的には、 blockchain でトランザクションが以前と同じ順序でコミットされていることを確認します。 作成され、blockchain の P2P ネットワークに送信されます。しかし、blockchain ネットワーク以来

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

が分散されている場合、そのような順序は捕捉できません。したがって、FSS はメカニズムを導入します 分散されたことによってのみ生じる公平性の侵害を防ぐため blockchain ネットワークの性質。 5.2 FSSの詳細 図 12: 2 つの異なるトランザクション パスを持つ順序公平なメモリプール: 直接的かつ mempool ベース。 図 12 は、FSS の一般的な概略図を示しています。公平性を確保するために、FSS を提供する DON は、トランザクションが MAINCHAIN に入るときにトランザクションのフローを妨害する必要があります。 クライアント、MAINCHAIN 上の smart contract、またはその両方の調整が必要になる場合があります。高レベルでは、FSS によるトランザクションの処理は 3 つに分解できます。 以下に説明するフェーズ: (1) トランザクション監視。 (2) トランザクションの順序付け。そして (3) トランザクションの転記。トランザクションの順序付けに使用される順序付け方法に応じて、次のセクションで説明するように、追加のプロトコル手順が必要になります。 5.2.1 トランザクション処理 トランザクション監視: FSS が監視するには 2 つの異なるアプローチを想定しています。 特定の smart contract を宛先とするユーザー トランザクション (直接およびメモリプール ベース): • 直接: 直接アプローチは概念的には最も単純ですが、変更が必要です。 ユーザークライアントにより、トランザクションが分散型 Oracle に直接送信されるようになります。メインチェーンのノードではなく、ネットワークノード。 DON は収集します 特定の smart contract SC 宛てのユーザー トランザクションとそれらに基づく注文 いくつかの注文ポリシーに基づいて。 DON は、注文されたトランザクションを メインチェーン上のsmart contract。一部の注文メカニズムでは、トランザクションを作成するユーザーが暗号化する必要があるため、直接的なアプローチも必要となります。 FSS に送信する前に保護してください。 • Mempool ベース: FSS とレガシー クライアントの統合を容易にするために、DON Mempool Services (MS) を使用してメインチェーンの mempool を監視し、収集することができます。 取引。 多くの契約では直接送信が推奨される実装となる可能性が高く、 そして多くの場合、それはかなり実用的であるはずだと私たちは信じています。 既存の DApps を最小限の変更でサポートできる方法について簡単に説明します。 優れたユーザーエクスペリエンスを維持しながら直接送信します。アプローチについて説明します Ethereum と MetaMask [6] は現在最も人気のある選択肢であるため、使用しますが、 前述のテクニックは他のチェーンやウォレットにも拡張されるべきです。最近のEthereum 改善提案、「EIP-3085: ウォレット追加 Ethereum チェーン RPC メソッド」 [100]、 カスタム Ethereum チェーンを簡単にターゲットにできるようになります (異なる CHAIN ID を使用) MetaMask やその他のブラウザベースのウォレットからのリプレイ攻撃を防ぐための MAINCHAIN のセキュリティです。この提案の実装後、DApp は DON の使用を希望します。 フロントエンドに単一のメソッド呼び出しを追加するだけで、直接送信できるようになります。 Ethereum 互換 API を公開する DON へのトランザクション。その間、 「EIP-712: Ethereum 型付き構造化データ hash の作成と署名」 [49] は、わずかに より複雑ではあるが、すでに広く導入されている代替案であり、DApp ユーザーが使用できる DON トランザクションを指定して構造化データに署名するメタマスク。 DApp が送信できるのは、 この署名された構造化データは DON に送信されます。 最後に、ハイブリッドアプローチも可能であることに注意してください。 たとえば、レガシー クライアントはメイン チェーンのメモリプールにトランザクションを送信し続けることができますが、これは重要です トランザクション (oracle レポートなど) は DON ノード (特に、 価格フィードの更新などの oracle レポートを提供するノードのセットとノードのセット ただし、FSS が重複するか同一である可能性があります)。 トランザクションの順序付け: FSS の主な目的は、ユーザーのトランザクションが事前定義されたポリシーに従って順序付けされることを保証することです。このポリシーの性質上、 アプリケーションのニーズと、アプリケーションが要求する不当なトランザクション命令の種類によって異なります。 を防ぐことを目的としています。 DON の FSS はデータを処理し、ローカル状態を維持できるため、 彼らは、以下の情報に基づいて任意の順序付けポリシーを課す可能性があります。 oracles で入手できます。 特定の順序付けポリシーとその実装については、セクション 5.3 で後述します。トランザクション転記: ユーザーから直接受信した、またはメモリプールから収集されたユーザー トランザクションを収集して順序付けした後、DON はこれらのトランザクションをメイン チェーンに送信します。そのため、DON とメインチェーンの相互作用は残ります。 メインチェーンのマイナーによって管理される（不公平な可能性がある）トランザクション順序の影響を受けます。分散型トランザクション注文の利点を活用するには、ターゲットをスマートにします。 したがって、契約 SC は、DON を「一級」国民として扱うように設計されなければなりません。私たち 2 つのアプローチを区別します。 • DON のみのコントラクト: 最も単純な設計オプションは、メイン チェーンをスマートにすることです。 契約 SC は、DON によって処理されたトランザクションのみを受け入れます。これ smart contract が、提案された順序でトランザクションを処理することを保証します。 DON ですが、事実上、smart contract は委員会ベースのシステムで運営されるように制限されています (つまり、DON 委員会は現在、 トランザクションの注文と包含）。 • デュアルクラス コントラクト: メイン チェーンがスマートになる、より粒度の高い設計が推奨されます。 コントラクト SC は、DON とレガシーの両方から発生するトランザクションを受け入れます ただし、DON によって処理されなかったトランザクションには従来の「スピード バンプ」が発生します。たとえば、DON からのトランザクションが処理される可能性があります。 従来のトランザクションは smart contract によってすぐに「バッファリング」されます。 一定の期間。フロントランニングを防止するためのその他の標準メカニズム commit-reveal スキームや VDF [53] などはレガシーにも適用できます 取引。これにより、DON で注文されたトランザクションが確実に処理されます。 DON に望ましくない検閲権限を与えることなく合意された命令 取引。 FSS によるトランザクション順序付けの強制では、トランザクションが「オフチェーン」で集約される必要があるため、このソリューションは、オンチェーン処理コストの削減を目的とした他の集約手法と自然に組み合わされます。たとえば、収集した後、 トランザクションを注文すると、DON はこれらのトランザクションをメイン チェーンに送信する可能性があります。 単一の「バッチトランザクション」(例: rollup) により、トランザクションの総量が削減されます。 料金。 トランザクション順序の強制: DON 専用設計でもデュアルクラス設計でも、 DON のトランザクション順序が維持されることを保証するには、メイン チェーン smart contract SC と DON を共同設計する必要があります。ここでも、さまざまな状況を想定しています デザインオプション: • シーケンス番号: DON は各トランザクションにシーケンス番号を追加し、これらのトランザクションをメイン チェーンのメモリプールに送信できます。 メイン 10DON のトランザクション監視がメモリプールに基づいている場合、レガシー トランザクションは、DON によって収集されないように、DON トランザクションと区別できる必要があります (特別なタグなどを介して)。 トランザクションに埋め込むか、特定のガス価格を指定することによって、例えばDON トランザクションにはガスが発生しています 一定のしきい値を下回る価格。チェーン smart contract SC は、「順序を外して」到着したトランザクションを無視します。私たち この設定では、メインチェーンのマイナーが DON を無視することを決定できることに注意してください。 トランザクションの順序付けが行われるため、トランザクションが失敗します。 SC が (高価な) 状態を維持することで、ある程度正しいトランザクション順序を強制することが可能です。 TCP が、欠落したパケットが見つかるまで、順序が乱れたパケットをバッファリングする方法と同様です。 受け取りました。 • トランザクション nonces: 多くの blockchain、特に Ethereum については、 上記のシーケンス番号付けアプローチでは、組み込みトランザクション nonces を利用して、 メインチェーン smart contract SC がトランザクションを順番に処理するように強制します。 ここで、DON ノードは、DON ノード間で共有されるキーで保護された単一のメインチェーン アカウントを通じてトランザクションをメインチェーンに送信します。アカウントの トランザクション nonce は、トランザクションが正しい順序でマイニングおよび処理されることを保証します。 • トランザクションの集約: DON は、複数のトランザクションを rollup に集約できます。 (または rollup のようなバンドル内)。メインチェーン smart contract は次のようにする必要があります。 このような集約トランザクションを処理するように設計されています。 • メインチェーンプロキシによるトランザクションの集約: ここで、DON は同様にトランザクションをメインチェーンの 1 つの「メタトランザクション」にバンドルしますが、 カスタム プロキシ smart contract を使用してトランザクションを解凍し、 ターゲット契約SC。この手法はレガシー互換性に役立ちます。メタトランザクションは rollup と同様に動作しますが、非圧縮トランザクションで構成される点が異なります。 メインチェーンに一度ポストされたトランザクションのリスト。 最後の設計には、ユーザー トランザクションをシームレスにサポートするという利点があります。 DON のターゲットに到達する前に、メイン チェーン コントラクトを通じて自身がプロキシされます SCと契約。たとえば、あるウォレットにトランザクションを送信するユーザーを考えてみましょう。 コントラクトは内部トランザクションを SC に送信します。シーケンスの割り当て ユーザーのウォレット契約が正しくない限り、そのようなトランザクションに番号を付けるのは難しいでしょう。 すべての内部トランザクションでシーケンス番号を転送するように特別に設計されています。 SC。 同様に、そのような内部トランザクションを、SC に直接送信されるメタトランザクションに簡単に集約することはできません。さらなる設計上の考慮事項について説明します。 かかる代理取引は以下の通りです。 5.2.2 トランザクションの原子性 これまでの議論は、トランザクションが単一のオブジェクトと相互作用することを暗黙に想定してきました。 オンチェーン smart contract (例: ユーザーが取引所に購入リクエストを送信する)。それでも、 Ethereum などのシステムでは、単一のトランザクションが複数の内部トランザクションで構成される場合があります (たとえば、1 つの smart contract が別のコントラクト内の関数を呼び出すなど)。以下、私たちは、 「マルチコントラクト」トランザクションをシーケンスするための 2 つの高レベルの戦略について説明します。 トランザクションのアトミック性（つまり、トランザクションによって規定された一連のアクション）を維持する トランザクションはすべて正しい順序で実行されるか、まったく実行されません)。強力な原子性: 最も簡単な解決策は、上で説明したように、FSS を「複数契約」トランザクション全体に直接適用することです。つまり、ユーザーはトランザクションを送信します をネットワークに接続し、FSS がこれらのトランザクションを監視、シーケンスし、 メインチェーン。 このアプローチは技術的には簡単ですが、潜在的な制限が 1 つあります。 トランザクションは、公平性を活用することを希望する 2 つの契約 SC1 および SC2 と対話します。 シーケンス サービスの場合、これら 2 つの契約のシーケンス ポリシーは一貫している必要があります。つまり、それぞれが対話する 2 つの異なるトランザクション tx1 と tx2 があるとします。 SC1 と SC2 の両方で、SC1 のポリシーが tx2 よりも先に tx1 を順序付ける場合であってはなりません。 一方、SC2 のポリシーは逆の順序を規定しています。 対象となるシナリオの大部分では、さまざまな契約で採用される順序ポリシーが一貫していると想定されます。たとえば、SC1 と SC2 の両方 トランザクションを mempool へのおおよその到着時間によって順序付けしたい場合があります。 さらに、SC1 は、特定の oracle レポートが常に最初に配信されることを望む場合があります。として 後者の oracle レポート トランザクションは SC2 と対話せず、ポリシーは一貫しています。 弱い原子性: 完全に一般的に言えば、FSS は個人レベルで適用できます。 内部取引。 いくつかの初期値で構成される tx = { ˜txpre, ˜txSC, ˜txpost} という形式のトランザクションを考えてみましょう。 トランザクション 〜txpre。これにより、SC への内部トランザクション 〜txSC が発生します。 内部トランザクション ~txpost を発行します。 SC のシーケンス ポリシーによって、その方法が決定される場合があります。 内部トランザクション ~txSC は、送信される他のトランザクションに関して順序付けする必要があります ただし、~txpre と ~txpost のシーケンス順序はオープンのままにしておきます。 Ethereum などのシステムにおけるトランザクション処理の本質を考慮すると、特定の内部トランザクションを対象としたシーケンス サービスの開発は簡単ではありません。特別に設計されたコントラクト SC を使用すると、これは次のように実現可能です。 1. トランザクション TX がネットワークに送信され、(順序付けなしで) マイニングされます。 FSSによって実行されます）。最初の ˜txpre が実行され、 ˜txSC が呼び出されます。 2. SC は ~txSC を実行せずにリターンします。 3. FSS は SC への内部トランザクションを監視し、順序付けしてポストバックします。 ＳＣに送信する（すなわち、トランザクション〜ｔｘＳＣをＳＣに直接送信することによって）。 4. SCは、FSSから受信したトランザクション~txSCを処理し、~txSCから結果として生じる内部トランザクション~txpostを発行します。 このアプローチでは、トランザクションは完全にアトミックに実行されません（つまり、元の トランザクション TX は複数のオンチェーン トランザクションに分割されます)、ただし順序は 内部トランザクションは保存されます。 このソリューションには、多くの設計上の制約が伴います。たとえば、 ˜txpre は次のことはできません。 〜txSCと〜txpostが実行されると仮定します。さらに、SC は次のように設計する必要があります。 特定のユーザーに代わってトランザクション 〜txSC および 〜txpost を実行します。FSSから送られてきました。これらの理由により、より粗粒度の「強力なアトミック性」ソリューションが使用されます。 実際には上記の方が望ましいと思われます。 複数のトランザクションや それぞれの内部トランザクションには、FSS のトランザクション スケジューラに含まれる可能性があります。 リレーショナルのトランザクション マネージャーにあるものに似た複雑な関数 データベースマネージャー。 5.3 公正なトランザクションの順序付け ここでは、トランザクションの順序付けの公平性に関する 2 つの概念と、FSS によって実現される対応する実装について説明します。 ポリシーに基づく注文の公平性 FSS と安全な因果関係の保存によって課されるため、FSS での追加の暗号化手法が必要になります。 注文の公平性: 順序の公平性は、コンセンサスプロトコルにおける時間的な公平性の概念です これは Kelkar らによって初めて正式に導入されました。 [144]。 ケルカーら。取引が行われる自然な政策の形を達成することを目指します。 DON (または P2P ネットワーク、 メモリプールベースの FSS の場合)。ただし、分散型システムでは異なります。 ノードではトランザクションが異なる順序で到着する可能性があります。 トータルオーダーの確立 すべてのトランザクションに関する問題は、基礎となるコンセンサス プロトコルによって解決されます。 メインチェーン。 ケルカーら。 [144] したがって、次のような弱い概念を導入します。 これは、「ブロック順序の公平性」と呼ばれる分散型 Oracle ネットワークの助けを借りて実現されます。 DON が一定期間中に受信したトランザクションをグループ化します。 「block」を選択し、ブロックのすべてのトランザクションを同時に同じ位置に挿入します。 (つまり、高さ) を MAINCHAIN に追加します。したがって、それらは一緒に注文され、実行可能でなければなりません それらの間に矛盾を生じさせることなく、並行して実行します。 大まかに言うと、orderfairness は、ノードの大部分が τ2 より前にトランザクション τ1 を見た場合、次のように述べます。 τ1 は、τ2 より前または同じブロック内でシーケンスされます。そんな粗雑なことを課すことで、 トランザクション注文の粒度が向上するため、フロントランニング攻撃やその他の注文関連の攻撃の機会が大幅に減少します。 ケルカーら。 Aequitas [144] と呼ばれるプロトコル ファミリを提案します。 同期、部分同期、非同期ネットワーク設定など、さまざまな導入モデルに対応します。 Aequitas プロトコルは、基本的な BFT コンセンサスに比べて通信オーバーヘッドが大きいため、実用には理想的ではありません。 しかし、私たちは、使用できる Aequitas の実用的な亜種が出現すると信じています。 FSS およびその他のアプリケーションのトランザクション シーケンス用。いくつかの関連スキームには、 付随する形式主義が少なく、特性が弱いものはすでに提案されていますが、 例: [36、151、236] ですが、実際のパフォーマンスはより優れています。これらのスキームをサポートできます FSSでも。 「公平性」という用語が blockchain の他の場所に登場していることにも注目してください。 異なる意味を持つ文学、すなわち、機会という意味での公平性コミットされたリソース [106, 181] または validator 秒に比例するマイナー 機会均等 [153]。 安全な因果関係の保存: 分散プラットフォームにおけるフロントランニングやその他の順序違反を防ぐ最も広く知られているアプローチは、暗号化に依存しています。 テクニック。それらの共通の特徴は、トランザクション データ自体を非表示にし、次の処理が完了するまで待機することです。 コンセンサス層での順序が確立され、トランザクションデータが明らかになります 後で処理します。これにより、トランザクション間の因果関係が維持されます。 blockchain によって実行されます。関連するセキュリティ概念と暗号化プロトコル blockchain の出現よりかなり前に開発されました [71、190]。 「入力因果関係」[190] および「安全な因果関係保存」[71、97] のセキュリティ条件では、トランザクションに関する情報が一切知られないようにすることが形式的に要求されます。 グローバルな順序におけるこのトランザクションの位置が決定される前。敵対者は、暗号化された方法で、その時点までいかなる情報も推測できてはなりません。 強いセンス。 因果関係を維持するための 4 つの暗号化手法を区別できます。 • Commit-Reveal プロトコル [29、142、145]: トランザクションがアナウンスされる代わりに 平文では、トランザクションに対する暗号化されたコミットメントのみがブロードキャストされます。コミット済みだが非表示のトランザクションがすべて注文された後 (blockchain の初めに) MAINCHAIN 自体のシステム、ただしここでは FSS による）、送信者はコミットメントをオープンし、所定の時間間隔内にトランザクション データを明らかにする必要があります。 次にネットワークは、開口部が以前の約束を満たしていることを検証します。の このメソッドの起源は、blockchains の出現より前に遡ります。 このアプローチは特に単純ですが、かなりの欠点があり、2 つの理由から採用が簡単ではありません。まず、注文プロトコルのレベルではコミットメントのみが存在するため、トランザクションのセマンティクスは コンセンサス中に検証することはできません。クライアントとの追加の往復 が必要です。しかし、より厳しいのは、開口部がなくなる可能性である。 これはサービス妨害攻撃に相当する可能性があります。さらに、それは 一貫性のある分散型環境では、開口部が有効であるかどうかを判断するのは困難です。 すべての参加者がオープニングが到着したかどうかに同意する必要があるため、この方法で 時間。 • リカバリが遅延するコミット-リビールプロトコル [145]: に関する 1 つの課題 commit-reveal アプローチでは、クライアントは投機的にトランザクションにコミットし、後続のトランザクションによって収益が得られる場合にのみ、後でそれを公開することができます。あ commit-reveal アプローチの最近の変形により、これに対する回復力が向上します。 一種の不正行為。特に、TEX プロトコル [145] はこの問題に対処します。 暗号化されたトランザクションに復号キーが含まれる賢いアプローチを使用する 検証可能な遅延関数 (VDF) [53、221] を計算することで取得できます。クライアントの場合 トランザクションを適時に復号化できなかった場合、システム内の他のユーザーが復号化します。 彼女に代わって、適度に難しい暗号パズルを解くことでそれを解決します。• しきい値暗号化 [71、190]: この方法は、DON が実行する可能性があることを利用します。 しきい値暗号化操作。 FSS が暗号化パブリックを維持していると仮定します。 キー pkO と oracle は、対応する秘密キーをそれらの間で共有します。 その後、クライアントは pkO でトランザクションを暗号化し、FSS に送信します。 FSS命令 DON 上のトランザクションを解析し、それらを復号化して、最後にそれらを 固定順序での MAINCHAIN。したがって、暗号化により注文が確実に行われます。 トランザクションの内容に基づくのではなく、データ自体がいつでも利用可能であることを示します。 必要です。 この方法はもともと Reiter と Birman [190] によって提案され、後に Cachin らによって改良されました。 [71]、許可されたコンセンサスと統合されました プロトコル。より最近の研究では、しきい値暗号化の使用を検討しています。 一般的なメッセージ [33、97] および共有データ [41] を使用した一般的な計算のためのコンセンサス レベルのメカニズム。 commit-reveal プロトコルと比較して、しきい値暗号化は単純なサービス拒否攻撃を防止します (ただし、復号化の計算コストを考慮すると注意が必要です)。これにより、DON は自律的に、独自の速度で、何もせずに進むことができます。 さらなるクライアントのアクションを待っています。トランザクションは、復号化された後すぐに検証できます。さらに、クライアントはすべてのトランザクションを 1 つの暗号化キーで暗号化します。 DON のキーと通信パターンは他のものと同じままです 取引。しきい値キーを安全に管理し、ノードを変更する ただし、O はさらなる問題を引き起こす可能性があります。 • コミットされた秘密の共有 [97]: トランザクション データを暗号化する代わりに、 DON が保持するキーの場合、クライアントはそれを O のノードに対して秘密共有することもできます。 ハイブリッドで計算上安全な秘密共有スキームを使用すると、トランザクションは まず、ランダムなキーを使用した対称暗号を使用して暗号化されます。対応する対称キーのみが共有され、暗号文は DON に送信されます。 クライアントは、個別に暗号化されたメッセージを使用して、O の各ノードに 1 つのキー共有を送信する必要があります。残りのプロトコル手順はしきい値の場合と同じです ただし、トランザクション データは対称暗号化で復号化されます。 共有からトランザクションごとのキーを再構築した後のアルゴリズム。 この方法では、公開鍵暗号システムの設定や管理が不要です。 DON に関連付けられています。ただし、クライアントは次のノードを認識している必要があります。 O それぞれと安全なコンテキストで通信します。 クライアントのさらなる負担。 暗号化方式は情報に対する完全な保護を提供しますが、 送信されたトランザクションからネットワークに漏洩するため、メタデータは隠蔽されません。のために たとえば、送信者の IP アドレスまたは Ethereum アドレスは引き続き使用される可能性があります。 フロントランニングやその他の攻撃を実行する敵。さまざまなプライバシー強化 ネットワーク層 ([52、95、107] など) またはトランザクション層に導入された技術、 この目標を達成するには、たとえば [13, 65] が必要になります。特定の作品の影響 メタデータの内容、つまりトランザクションがどのコントラクトに送信されるかを（部分的に）隠すことができます同じ DON 上で多くのコントラクトを多重化することによって。暗号の隠蔽 トランザクション自体も、破損したトランザクションによるトランザクションの優先順位付けを妨げるものではありません。 DON ノードがトランザクション送信者と共謀しています。 暗号プロトコルによって保証される安全な因果関係は、あらゆるポリシーの順序の公平性の保証を補完するものであり、私たちはこの 2 つの組み合わせを検討するつもりです。 可能な場合はメソッドを使用します。敵対者が重大な利益を得ることができない場合、 メタデータを観察すると、安全な因果関係保存プロトコルを併用できます。 素朴な注文アプローチも同様です。たとえば、oracle ノードはトランザクションを書き込むことができます 重複することなく、受け取ったらすぐに L に送信します。トランザクションは次のようになります。 L 上の出現に従って順序付けされ、その後復号化されます。 また、公正な注文を強制する手段として TEE の使用を検討する予定です。のために たとえば、Tesseract [44] は因果的順序付けの形式を実現していると見なすことができますが、 TEE が明示的な形式でトランザクションを処理する能力によって強化されます。 秘密を保持します。 5.4 ネットワーク層の考慮事項 これまでのところ、FSS についての説明は主に、次のことを強制する問題に焦点を当ててきました。 最終的なトランザクションの順序は、ネットワーク内で観察された順序と一致します。以下、 ネットワーク層自体で発生する可能性のある公平性の問題を考慮します。 従来の電子市場の高頻度トレーダーは多額の投資を行っています [64] は優れたネットワーク速度を得るためにリソースを使用しており、暗号通貨取引所のトレーダーも同様の動作を示しています [90]。ネットワーク速度は、次の点で利点をもたらします。 他の当事者の取引を観察し、競合する取引を提出する。 実際に導入され、書籍『Flash Boys [155]』で普及した解決策の 1 つは次のとおりです。 最初に IEX 取引所 [128] で導入され、その後他の取引所でも導入された「スピード バンプ」 [179] を交換します (結果はさまざまです [19])。このメカニズムは、市場へのアクセスに遅延 (IEX では 350 マイクロ秒) を課し、市場における利点を中和することを目的としています。 スピード。経験的証拠、例: [128]、特定の取引を減らす効果を裏付ける 一般投資家にとってのコスト。 FSS は、単純に非対称を実装するために使用できます。 速度の上昇 - 受信トランザクションを遅らせるもの。 バディッシュ、クラムトン、シム [64] は、速度の利点を利用すると主張しています。 継続時間市場では避けられないものであり、市場における構造的救済策を主張しています。 バッチオークションベースの市場の形態。しかし、このアプローチは広く定着していない 既存の取引プラットフォームで。 従来の取引システムは集中化されており、通常は次の方法で取引を受け取ります。 単一のネットワーク接続。対照的に、分散型システムでは、次のことが可能です。 複数の有利な点からトランザクションの伝播を観察します。その結果、P2P ネットワークにおけるネットワーク フラッディングなどの動作を観察することが可能になります。 私たちは意図しています 開発者がポリシーを指定するのに役立つ FSS へのネットワーク層のアプローチを調査する このような望ましくないネットワーク動作を禁止します。5.5 エンティティレベルの公平性ポリシー 注文の公平性と安全な因果関係は、次のようなトランザクションに対して注文を強制することを目的としています。 作成され、最初にネットワークに送信された時刻が尊重されます。この公平性の概念の限界は、敵対者が行う攻撃を防ぐことができないことです。 システムに多くのトランザクションを溢れさせることで優位性を得るという戦略が観察されています token 売上 [159] において効果的なトランザクション スナイピングを実行する方法として広く普及しています。 混雑を引き起こし、債務担保ポジション (CDP) [48] の清算を引き起こします。 言い換えれば、注文の公平性は、プレイヤーではなくトランザクションに関する公平性を強制します。 CanDID システム [160] に示されているように、DECO などの oracle ツールを使用することが可能です または、Town Crier をノード委員会 (DON など) と連携して達成します。 プライバシーを保護しながら、さまざまな形のシビル耐性を実現します。ユーザーはアイデンティティを登録できます そして、身元自体を明らかにすることなく、その独自性の証拠を提供します。 シビル耐性のある認証情報は、トランザクションの順序付けを強化するための可能なアプローチを提供します フラッディング攻撃の機会を制限するような方法でポリシーを適用します。たとえば、 token 販売では、登録ユーザーごとに 1 つのトランザクションのみが許可される場合があります。 社会保障番号などの国民識別子の一意性の証明が必要です。 このようなアプローチは確実ではありませんが、トランザクション フラッディング攻撃を軽減するための有用なポリシーであることが証明される可能性があります。

خدمات التسلسل العادل

إحدى الخدمات المهمة التي نتوقع أن تقدمها 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

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

يتم توزيعها، ولا يمكن التقاط مثل هذا الطلب. لذلك يقدم 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 ソリューションの分散リソース サポートを提供します。 Decentralized Oracle Network Transaction-Execution Framework (DONTEF)、または略して TEF と呼ばれるもの。 現在、DeFi コントラクトの更新頻度はメイン チェーンのレイテンシによって制限されています。 たとえば、Ethereum [104] の 10 ～ 15 秒の平均ブロック間隔と、 大量のデータをチェーン上にプッシュし、計算/送信スループットが制限される— シャーディング [148、158、232] やレイヤー 2 実行 [5、 12、121、141、169、186、187]。トランザクション時間がはるかに速い blockchain であっても、 例: [120] は、オフチェーン計算 [168] を含むスケーリング戦略を提案しています。 TEF は、そのようなレイヤー 1 / MAINCHAIN システムのレイヤー 2 リソースとして機能することを目的としています。 TEF を使用すると、DONs は MAINCHAIN コントラクトでのより高速な更新をサポートできます。 メインチェーンによって提供される主要な信頼保証を保持します。 TEFがサポートできるのは rollups を含む、多数のレイヤー 2 実行技術およびパラダイムのいずれか、11 楽観的な rollups、Validium など、および DON が含まれるしきい値信頼モデル ノードはトランザクションを実行します。 TEF は FSS を補完するものであり、FSS をサポートすることを目的としています。言い換えれば、どれでも TEF で実行されているアプリケーションは FSS を使用できます。 11しばしば「zk-rollups」と呼ばれますが、これはゼロ知識証明を必ずしも必要としないため、誤った名称です。

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

6.1 TEFの概要 TEF は、パフォーマンスの高いハイブリッドを構築および実行するための設計パターンです。 smart contract SC。 ハイブリッド smart contracts の背後にある主な考え方に従って、TEF には以下が含まれます。 SC を 2 つの部分に分解: (1) TEF コンテキストでアンカーと呼ぶもの MAINCHAIN 上の契約 SCa と (2) DON ロジックは、TEF 実行可能ファイルと呼ばれます。 ここでは、SCa の組み合わせによって実装される論理コントラクトを示すために SC を使用します。 そして実行します。 (上で述べたように、私たちは、 SC をこれらのコンポーネントに自動的に契約します)。 TEF 実行可能ファイル exect は、SC でユーザーのトランザクションを処理するエンジンです。それ DON 上で実行されるため、パフォーマンスの高い方法で実行できます。これにはいくつかの機能があります。 • トランザクションの取り込み: exect はユーザーのトランザクションを受信または取得します。それはできる 直接、つまり、DON でのトランザクション送信を通じて、または MAINCHAIN 経由で MSを使用したmempool。 • 高速トランザクション実行: 内部の資産に関係するトランザクションを実行します。 SC。これはローカル、つまり DON 上で行われます。 • 高速かつ低コスト oracle / アダプター アクセス: exect は oracle レポートにネイティブ アクセスします。 およびその他のアダプター データにより、より高速、より安価、より正確な資産を実現 MAINCHAIN 実行よりも価格設定が異なります。さらに、オフチェーン oracle アクセスは減少します oracle の運用コスト、つまりシステムの使用コストを回避することで、 高価なオンチェーンストレージ。 • 同期: exect は定期的に更新を DON から MAINCHAIN にプッシュし、SCa を更新します。 アンカー コントラクトは、SC の MAINCHAIN フロント エンドです。 SC の高信頼コンポーネントとして、次のようないくつかの目的を果たします。 • 資産保管: ユーザーの資金は SCa に預け入れ、保持され、SCa から引き出しられます。 • 同期検証: SCa は、実行時に状態更新の正確さを検証する場合があります。 同期 (例: rollups に接続された SNARK)。 • ガード レール: SCa には、破損や障害から保護するための規定が含まれる場合があります。 実際に。 (詳細についてはセクション 7 を参照してください。) TEF では、ユーザーの資金は MAINCHAIN で保管されます。つまり、DON 自体は保管されていません。同期メカニズム (以下を参照) の選択に応じて、ユーザーは次のことが必要になる場合があります。 DON は、正確な oracle レポートと MAINCHAIN とのタイムリーな同期に対してのみ信頼されます。 結果として得られる信頼モデルは、オーダーブックベースの DEX のものと非常によく似ています (例: [2])。 現在、これには通常、注文照合用のオフチェーン コンポーネントと清算と決済用のオンチェーン コンポーネントが含まれています。決済システムの用語を使用すると、ex をコンポーネントと考えることができます。 SC が清算を担当し、SCa が決済を担当します。回路図については図 13 を参照してください。 TEFの描写。 図 13: TEF の回路図。この例では、トランザクションは mempool を通過します。 MAINCHAIN を MS 経由で DON に送信します。 TEF の利点: TEF には 3 つの主な利点があります。 • 高パフォーマンス: SC は、DON の MAINCHAIN よりもはるかに高いスループットを継承します。 トランザクションとoracleレポートの両方。さらに、exect は、MAINCHAIN のみでの実装よりもトランザクションをより速く処理し、oracle レポートにタイムリーに応答できます。 • 低料金: 同期プロセスはトランザクション処理ほど時間に依存せず、トランザクションは DON から MAINCHAIN にバッチで送信できます。 その結果、このアプローチによるトランザクションごとのオンチェーン料金 (ガスコストなど) は、MAINCHAIN 上でのみ実行されるコントラクトよりもはるかに低くなります。 • 機密性: DON の機密性メカニズムは、 SCでベア。

TEF の制限: TEF の制限の 1 つは、瞬間的なデータをサポートしていないことです。 引き出しはメインチェーン上でのみ発生します: 引き出しリクエストの送信時 SCa に対して、ユーザーは exect を含む状態更新を実行するまで待機する必要がある場合があります。 出金トランザクションが承認される前に行われます。いくつかの部分的な救済策について説明します。 ただし、セクション 6.2 に記載されています。 TEF のもう 1 つの制限は、DeFi の原子構成をサポートしていないことです。 MAINCHAIN 上のコントラクト、具体的には複数の DeFi を介してアセットをルーティングする機能 単一のトランザクションで契約します。ただし、TEF は、そのようなアトミック性をサポートできます。 DeFi 契約は同じ DON で実行されます。これに対処するいくつかの方法についても説明します セクション 6.2 の問題。 6.2 トランザクションルーティング SC のトランザクションは、ユーザーが DON に直接送信することも、経由してルーティングすることもできます。 MAINCHAIN の mempool (FSS 経由)。 4 つの異なるトランザクション タイプがあり、それぞれ 異なる処理が必要になる場合があります。 契約内取引: TEF はガス力学の複雑さを回避するため、SC にトランザクション処理の柔軟性を提供します。 レイヤ 1 契約で利用可能です。たとえば、Ethereum のメモリプール トランザクション中、 より高いガス価格の新しいトランザクションによって上書きされる可能性があり、SC は、SC 内の資産を操作するトランザクションが表示されるとすぐに、権限のあるトランザクションとして扱うことができます。 メンプールで。したがって、SC はトランザクションが確認されるまで待つ必要がありません。 ブロック内で実行されるため、レイテンシが大幅に短縮されます。 プロキシ: ユーザーは、ウォレットコントラクト経由でトランザクション τ を SC に送信するか、または MAINCHAIN 上の他のコントラクト。 DON は次の実行をシミュレートすることができます。 MAINCHAIN の τ を調べて、SC への後続トランザクションが発生するかどうかを判断します。 そうである場合、τ は、実行する SC の他のトランザクションと順序付けできます。いくつかあります DON がそのようなトランザクションを識別する方法の可能性: (1) DON はシミュレートできます。 メモリプール内のすべてのトランザクション (高価なアプローチ)。 (2) 特定の契約または ウォレットなどの契約タイプは、DON による監視のためにリストに登録できます。または (3) ユーザーは次のことができます。 DON 検査のためにトランザクションに注釈を付けます。 1 つのトランザクションが 2 つのトランザクションと相互作用する場合、問題はさらに複雑になります。 契約、SC1 および SC2 は、どちらも Fair Sequencing Services を使用しており、互換性のない注文ポリシーを持っています。 DON は、たとえば、最も遅い時間に τ をシーケンスする可能性があります。 それは両方と互換性があります。 預金: MAINCHAIN アセットを SC に預けるトランザクションは、SC がそれを有効なものとして扱う前に、ブロック内で確認される必要があります。マイニングを検出すると、 資産（例：イーサ）をSCaに送信するトランザクションを実行すると、即座に確認できます。デポジット。たとえば、oracle によって報告された DON の現在の価格を、 資産。 引き出し: 上で述べたように、TEF には出金が常に瞬時に実行できるとは限らないという制限があります。 rollup タイプの実行モデルでは、引き出しは 安全に実行するには、リクエストを他のトランザクションと並べる、つまりロールアップする必要があります。 加工された。ただし、この制限には部分的な解決策がいくつかあります。 DON が出金トランザクションまでの rollup 有効性証明を迅速に計算できる場合、メモリプール exect 内のユーザーのトランザクション τ を観察することで、より高いガス価格で τ の状態更新トランザクション τ ' を送信できます。これは一種の有益なフロントランニングです。 τ ' がメモリプールに到達する前に τ がマイニングされない場合、τ ' は τ に先行し、τ は 承認された引き出しが有効になります。 TEF バリアントでは、状態の更新を計算するために DON が使用されます (「 以下のしきい値署名バリアント)、DON は代わりにオフチェーンを決定することもできます 実行時の SC の状態を考慮して τ を承認すべきかどうか。 DON その後、完全なトランザクションに影響を与えることなく、出金 τ を承認するトランザクション τ ' を送信できます。 状態の更新。 このアプローチが不可能な場合、または成功しない場合は、DON によって開始される トランザクション τ ' は、τ に応答してユーザーに資金を送信できるため、ユーザーはその必要がなくなります。 追加のトランザクションを開始します。 6.3 同期中 TEF 実行可能ファイル exect は、更新を 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] を参照。) 以下では、これらの同期オプションを 3 つの主要なプロパティに関して比較します。 テフ: • データの可用性: SC の状態はどこに保存されますか?少なくとも 3 つの選択肢があります TEF で利用可能: MAINCHAIN、DON、またはサードパーティのストレージで利用可能 IPFS などのプロバイダー。さまざまなセキュリティ保証と可用性を実現します レベルとパフォーマンスプロファイル。簡単に言えば、MAINCHAIN に状態を保存すると、 オンチェーンの監査可能性により、状態の可用性を第三者に依存する必要がなくなります。 一方、状態をオフチェーンに保存すると、ストレージコストが削減され、パフォーマンスが向上します。 スループットは、ストレージプロバイダー (DON またはサードパーティ) を信頼することを犠牲にして、 データの可用性。もちろん、これらのオプションを組み合わせた柔軟なモデルも可能です。 可能です。データ利用に必要な形式を表 1 に示します。• 正確性の保証: SCa は更新の正確さをどのように確認しますか exによってプッシュされましたか？これは exect と SCa の計算負荷に影響します。 同期遅延 (下記を参照)。 • 遅延: 同期の遅延には 3 つの要因があります: (1) 所要時間 同期トランザクション τsync を生成する予定です。 (2) τsyncにかかる時間 MAINCHAIN で確認します。 (3) τsync が有効になるまでの時間 ＳＣａ． TEF では、レイテンシーは出金の場合に特に重要です (ただし、出金の場合はそれほど重要ではありません)。 契約内取引）のため、出金には必ず（少なくとも 部分的）状態の同期。 同期中 オプション データ 可用性 正しさ 保証する レイテンシ ロールアップ [5、12、16、69] オンチェーン 有効性の証明 生成にかかる時間 有効性の証明 (例: 現在のシステムの分) バリジウム [201] オフチェーン 有効性の証明 同上 楽観的 rollup [10, 11、141] オンチェーン 不正行為の証拠 チャレンジの長さ 期間 (例: 日 または 週間） しきい値署名 [24, 54、116、202] 柔軟な DON によるしきい値署名 瞬時 信頼できる実行環境 [80] 柔軟な ハードウェアベース 証明書 瞬時 表 1: TEF のさまざまな同期オプションとそのプロパティ。 表 1 は、TEF の 5 つの主要な同期オプションのこれらのプロパティをまとめたものです。 （注） これらのテクノロジーをスタンドアロンのレイヤー 2 スケーリングとして比較するつもりはありません。 ソリューション。これについては、[121] などを参照してください。) 次に、各同期オプションについて説明します。 ロールアップ: rollup [69] は、状態遷移が トランザクションのバッチはオフチェーンで計算されます。 その後、状態の変化が伝播されます メインチェーンに。 rollups を実装するために、アンカー smart contract SCa は、実際の状態のコンパクト表現 Rstate (マークル ルートなど) を格納します。同期するには、τsync = を送信します。 (T、R' state) を SCa に変換します。ここで、T は、前回のトランザクション以降に処理されたトランザクションのセットです。同期とR' 状態は、次の方法を適用して計算された新しい状態のコンパクトな表現です。 T のトランザクションを前の状態 Rstate に戻します。 SCa が τsync での状態更新を検証する方法が異なる 2 つの一般的な亜種があります。 最初の (zk-)rollups は、正確性の簡潔な引数を添付します。 遷移 Rstate →R' の妥当性証明 状態。このバリアントを実装するには、次を実行します τsync とともに有効性証明 (zk-SNARK 証明など) を計算して送信します。 R'を証明する state は、SCa の現在の状態に T を適用した結果です。アンカー 契約は証拠を検証した後にのみ状態の更新を受け入れます。 楽観的な rollup には正しさの引数が含まれていませんが、staking と 状態遷移の分散検証を容易にするチャレンジ手順。このために rollup のバリアント、SCa は τsync が正しいと仮定して暫定的に受け入れます (したがって楽観的です) ただし、τsync はチャレンジ期間が終わるまで有効になりません。 MAINCHAIN を監視すると、誤った状態更新を特定し、SCa に通知することができます。 必要なアクション (例: 状態をロールバックし、実行時にペナルティを課す) 両方の rollup バリアントは、トランザクションがポストされるため、オンチェーン データの可用性を実現します。 オンチェーンから完全な状態を構築できます。 zk-rollups のレイテンシは 有効性証明を生成するのに必要な時間が大半を占め、通常は 既存のシステム [16] では数分のオーダーであり、時間の経過とともに改善される可能性があります。 一方、楽観的な rollup の遅延は長くなります (例: 数日または数週間)。 不正行為の証明が機能するには、異議申し立て期間が十分に長い必要があるためです。の 確認が遅いことの意味は微妙であり、場合によってはスキームに特有のものであるため、 徹底的な分析は範囲外です。たとえば、特定のスキームでは支払いが考慮されています。 状態の更新が確認される前に、トランザクションは「トラストレス最終」[109] として保存されます。 通常のユーザーは、MAINCHAIN よりもはるかに迅速に rollup を検証できます。 バリジウム: Validium は、データをオフチェーンのみで利用できるようにする (zk-)rollup の形式です すべてのデータを MAINCHAIN 上に維持するわけではありません。具体的には、 exect は新しいもののみを送信します 状態と証拠は提供されますが、SCa への取引は提供されません。 Validium スタイルの同期では、次のようになります。 完全な状態を保存するのは、それを実行する DON だけです。 トランザクションを実行するもの。 zk-rollups と同様、同期の遅延は有効性によって左右されます。 証拠の生成時間。ただし、zk-rollups とは異なり、Validium スタイルの同期により、 ストレージコストが削減され、スループットが向上します。 DON によるしきい値署名: DON ノードのしきい値が正しいと仮定すると、 シンプルで高速な同期オプションは、DON ノードが集合的に新しい状態に署名することです。 このアプローチは、オンチェーンとオフチェーンの両方のデータ可用性をサポートできます。場合に注意してください。 ユーザーは oracle アップデートに対して DON を信頼します。受け入れるためにそれ以上信頼する必要はありません 状態の更新は、すでにしきい値信頼モデルに含まれているためです。 もう一つの利点は、 しきい値署名は低遅延です。新しいトランザクション署名形式のサポート EIP-2938 [70] で提案され、アカウント抽象化として知られているしきい値が作成されます。 署名はしきい値の必要性を排除するため、実装が大幅に容易になります。 ECDSA。かなり複雑なプロトコルが含まれます (例: [116、117、118])しきい値 Schnorr [202] 署名や BLS [55] 署名などの代替署名よりも優れています。 信頼された実行環境 (TEE): TEE は、強力なセキュリティ保護を提供することを目的とした分離された実行環境 (通常はハードウェアによって実現される) です。 内部で実行されているプログラム用。一部の TEE (例: Intel SGX [84]) はプルーフを生成できます。 証明書として知られ、出力が特定のプログラムによって正しく計算されていることを示します。 特定の入力12. TEE ベースの TEF 同期のバリアントは、次のように実装できます。 (zk-)rollups または Validium の証明をテクニックを使用した TEE 証明書に置き換える [80] から。 rollups や Validium で使用されるゼロ知識証明と比較すると、TEE ははるかに優れています。 より高性能に。しきい値署名と比較して、TEE は複雑さを解消します。 原則として必要な TEE は 1 つだけであるため、しきい値 ECDSA 署名を生成する 関与している。ただし、TEE を使用すると、ハードウェアに依存する追加の信頼仮定が導入されます。 TEE としきい値署名を組み合わせて回復力を生み出すこともできます この保護措置は、TEE インスタンスの一部の侵害に対しては適用されますが、 しきい値 ECDSA 署名の生成の複雑さが再び導入されます。 追加の柔軟性: これらの同期オプションは、次の方法でさらに柔軟に調整できるようになります。 • 柔軟なトリガー: TEF アプリケーションは、次の条件を決定できます。 同期がトリガーされます。たとえば、同期はバッチベースで行うことができます。 N トランザクションごと、時間ベース (例: 10 ブロックごと)、またはイベントベース (例: 発生) 目標資産価格が大きく変動するときはいつでも。 • 部分的な同期: 可能であり、場合によっては望ましい場合もあります (例: rollups、 部分的な同期によりレイテンシを短縮できます）。小規模な同期の高速同期を実現します。 完全な同期はおそらく定期的にのみ実行されます。たとえば、 実行者は、SCa のユーザーの残高を更新することで出金リクエストを承認できます それ以外の方法で MAINCHAIN 状態を更新する必要はありません。 6.4 再組織化 ネットワークの不安定性、または 51% 攻撃によっても引き起こされるブロックチェーンの再編成 メインチェーンの整合性に脅威を与える可能性があります。実際、敵対者はこれを使用してきました。 二重支出攻撃[34]を仕掛けるためです。大手チェーンに対するこのような攻撃は、 取り付けるのは難しいですが、一部のチェーン [88] では依然として実現可能です。 DON は MAINCHAIN から独立して動作するため、興味深い機能を提供します。 に関連する組織再編を観察し、それに対して何らかの保護を提供する可能性 攻撃します。 たとえば、DON は、MAINCHAIN 上の依存コントラクト 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"، وهي تسمية خاطئة، لأنها لا تحتاج بالضرورة إلى إثباتات المعرفة الصفرية.

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

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 データソースの認証 oracle の現在の運用モデルは、データ ソースがほとんどないという事実によって制約されています。 TLS がネイティブに署名しないことが主な理由で、省略されたデータにデジタル署名します。 データ。 TLS は、「ハンドシェイク」プロトコルでデジタル署名を利用します（確立するため）。 サーバーとクライアント間の共有キー）。したがって、HTTPS 対応サーバーには証明書があります 原則としてデータの署名に使用できる公開鍵ですが、通常は使用されません。 これらの証明書はデータ署名をサポートします。したがって、DON のセキュリティは次のようになります。 今日のoracleネットワークでは、データからデータを忠実に中継するoracleノードに依存しています。 契約のソース。 Chainlink における信頼の最小化に関する当社のビジョンの重要な長期的な要素には、データ署名のためのツールと標準のサポートを通じた強力なデータ ソース認証が含まれます。データ署名は、エンドツーエンドの整合性保証を強制するのに役立ちます。 原則として、契約がデータの一部を入力として受け入れる場合、データによって直接署名された D

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

図 14: このセクションで説明する信頼最小化メカニズムの軌跡。 1⃝データ ソースは 2⃝DON にデータを提供し、データの機能を依存関係に中継します。 3⃝smart contract。 さらに、DON または oracle ネットワークには 4⃝ ノードが含まれます 補償ノード、ガードなどの MAINCHAIN 上の管理 smart contracts レールなど。 ソースがあれば、oracle ネットワークは D を改ざんすることはできません。 OpenID Connect など、このようなデータ署名を可能にする取り組みが現れています。 主にユーザー認証 [9]、TLS-N を目的とした学術プロジェクトのために設計されています。 TLS 証明書を再利用することで TLS [191] を拡張し、TLS 証拠拡張機能 [63] を使用します。 ただし、OpenID Connect はある程度の採用が見られますが、TLS Evidence Extensions は および TLS-N はまだ採用されていません。 データ ソース認証のもう 1 つの潜在的な手段は、発行者独自の認証を使用することです。 Signed HTTP Exchange (SXG) [230]。Accelerated Mobile Pages (AMP) プロトコル [225] の一部としてコンテンツ配信ネットワークにキャッシュできます。 Chrome モバイル ブラウザは、AMP でキャッシュされた SXG のコンテンツを、あたかも SXG から提供されているかのように表示します。 キャッシュ サーバー ドメインの代わりに、発行者自身のネットワーク ドメインを使用します。このブランド化のインセンティブは、CloudFlare の Real URL [83] や Google の amppackager [124] などのサービスを使用して有効にするのが比較的簡単であることと相まって、キャッシュされたニュース コンテンツでの SXG の広範な採用につながる可能性があります。 有効な SXG で報告されたニュース価値のあるイベントで Chainlink oracle がトリガーされる方法。 一方、ニュース出版社からの AMP キャッシュされた SXG はハイテンポには役に立ちません。 取引データに関するレポートなどのアプリケーションは、カスタム データの安全なソースとなる可能性があります。 異常気象や選挙結果などの現実世界の出来事に関連する契約。 私たちは、シンプルな導入、成熟したツール、および柔軟性が不可欠であると信じています。 データソース署名の高速化。データプロバイダーが Chainlink ノードを次のように使用できるようにする 認証された API フロントエンドは有望なアプローチであると思われます。私たちは、ネットワークへの参加の有無にかかわらず、ノードがこのモードで機能するためのオプション 本格的なoracleとして。この機能を認証済みデータ生成と呼びます。 (ADO)。 ADO で Chainlink ノードを使用すると、データ ソースは次の利点を得ることができます。 Chainlink コミュニティによって開発されたデジタル機能の追加の経験とツールから 既存のオフチェーン API スイートに署名機能を追加します。彼らは逃げることを選択すべきか ノードを oracle として使用すると、さらに潜在的な新しい収益源を開拓できます 既存のデータプロバイダーと同じモデルの下、例: Kraken [28]、Kaiko [140]、 その他、Chainlink ノードを実行して API データをチェーン上で販売するものもあります。 7.1.1 認証されたデータ生成の制限 データ ソースによるデジタル署名は、認証の強化には役立ちますが、それ自体では、oracle の本来のセキュリティや運用上の目標をすべて達成するには十分ではありません。 ネットワーク。 まず、特定のデータ D は堅牢かつタイムリーに中継される必要があります。 データ ソースから smart contract または他のデータ コンシューマーまでの経路。つまり、 依存関係に事前にプログラムされたキーを使用してすべてのデータが署名される理想的な設定 契約の場合でも、ソースからデータを確実に通信するには DON が必要になります。 契約書に。 さらに、契約書やその他のoracleデータが 消費者は、計算されたさまざまな関数の認証された出力へのアクセスを望んでいます。 ソース データには次の 2 つの主な理由があります。 • 機密性: データ ソース API は機密データまたは専有データを提供する場合があります。 チェーン上で公開される前に、編集またはサニタイズする必要があります。 ただし、署名されたデータを変更すると、署名が無効になります。もう一つ入れて ちなみに、単純な ADO とデータのサニタイズには互換性がありません。例 3 に示します ADO の強化された形式を通じて、この 2 つをどのように調整できるか。 • データ ソースの障害: エラーと障害の両方がデータ ソースに影響を与える可能性がありますが、デジタル署名はどちらの問題にも対処しません。 [98]、Chainlink は当初から このような障害を修復するメカニズム、つまり冗長性がすでに組み込まれています。 oracle ネットワークによって発行されるレポートは通常、複数のデータを組み合わせたものを表します。 ソース。 次に、ソース データの機密性を強化し、複数のソースからのデータを安全に結合するために、ADO 設定で検討しているスキームについて説明します。 7.1.2 機密保持 データ ソースは、必要な API の全範囲を予測して利用できるようにしていない可能性があります。 ユーザーによる。 具体的には、ユーザーは、事前に処理されたデータにアクセスして、 機密保持。次の例は、この問題を示しています。例 3. アリスは、次のような分散型アイデンティティ (DID) 資格情報を取得したいと考えています。 彼女が 18 歳以上であること (したがって、たとえばローンを組むことができる)。やること したがって、彼女は自分の年齢に関するこの事実を DID 資格情報発行者に証明する必要があります。 アリスは、自分の州の陸運局 (DMV) からのデータを使用したいと考えています。 という目的のためのウェブサイト。 DMV には彼女の生年月日の記録があり、 次の形式のデジタル署名された証明書 A: A = {名前: アリス、生年月日: 1999 年 2 月 16 日}。 この例では、アリスが DID に証明するには、証明書 A で十分である可能性があります。 資格情報の発行者は彼女が 18 歳以上であることを証明しました。しかし、機密情報が不必要に漏洩します: アリスの 正確なDoB。理想的には、アリスが代わりに DMV に求めているのは、 「アリスは 18 歳以上です」という単純なステートメント A'。言い換えれば、彼女が望んでいるのは、 彼女の誕生日 X に対する関数 G の出力。ここで、(非公式に) A' = G(X) = True の場合 現在の日付 -X ≥18 歳。それ以外の場合、G(X) = False。 一般的に言うと、アリスはデータ ソースから署名付きのデータをリクエストできるようにしたいと考えています。 形式の証明書 A': A' = {名前: アリス、機能: 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 (価格データの中央値化)。価格フィード、つまり 1 つの値を提供するため ある資産 (例: ETH) を別の資産 (例: USD) と比較すると、oracle ネットワークは通常、 取引所などの多くの情報源から現在の価格を取得します。 oracle ネットワーク 通常、これらの値の中央値を従属契約 SC に送信します。 データ署名のある環境では、正しく機能する oracle ネットワークは、 データ ソースから S = {S1, . 。 。 , SnS} 一連の値 V = {v1, v2, ... 。 。 、vnS}から ソース固有の署名を伴う nS ソース Σ = {σ1, σ2, ... 。 。 、σnS}。次第 署名を検証し、価格 v = median(V ) を SC に送信します。残念ながら、oracle ネットワークが中央値を送信する簡単な方法はありません。 例 4 の値 v を、v が正しく計算されたことの簡潔な証明 σ∗ とともに SC に送信します。 符号付き入力を超えます。 単純なアプローチは、すべての nS データ ソースの公開キーを SC でエンコードすることです。 oracle ネットワークは (V, Σ) を中継し、SC が V の中央値を計算できるようにします。 ただし、これでは証明 σ のサイズが O(nS) になります。つまり、σ∗ は簡潔ではありません。 また、SC ではすべての署名を検証する必要があるため、高額なガスコストが発生します。 Σ。 対照的に、SNARK を使用すると、正しく結合された認証されたソース値の簡潔な証明が可能になります。実際には実行可能かもしれないが、かなりの負担がかかる 証明者では計算コストがかかり、チェーンではガスのコストが若干高くなります。の使用 Town Crier も可能ですが、TEE の使用が必要であり、すべてに適しているわけではありません。 ユーザーの信頼モデル。 ソースから結合されたデータに署名するという一般的な問題に対する解決策を組み立てる有用な概念は、関数署名として知られる暗号化ツールです [59、132]。 簡単に言うと、機能署名を使用すると、署名者は次のような署名機能を委任できます。 デリゲート者は、署名者が選択した関数 F の範囲内のメッセージにのみ署名できます。 付録 D では、この機能的制約が範囲を制限するためにどのように機能するかを示します。 データ ソースによって署名された値の関数として DON によって出力されるレポート値。 また、離散化関数シグネチャと呼ばれる新しいプリミティブも導入します。これには、精度の要件が緩和されていますが、潜在的にはるかにパフォーマンスが向上します。 SNARKsなどのアプローチよりも。 ソース認証を含む方法でデータ ソースを結合する際の問題 出力の一部は、CoinCap、CoinMarketCap、CoinGecko などのデータ アグリゲーターにも適用されます。 CryptoCompare など、多数の取引所からデータを取得します。 場合によっては公開される方法論を使用して、体積に基づいた重み付けを行う 他の場合には独自のものになります。値を公開したいアグリゲータ ソース認証は、ノードの集合体を集約する場合と同じ課題に直面します。 ソースデータ。 7.1.4 ソースデータの処理 洗練された smart contract は、カスタム集計統計に依存する可能性があります。 多くの資産における最近の価格履歴のボラティリティなどの主要なデータ ソース、または 関連イベントに関するニュースのテキストと写真。 DON では計算と帯域幅が比較的安価であるため、これらの統計は— 多くの入力を持つ複雑な機械学習モデルであっても、blockchain に送られる出力値が十分に簡潔である限り、経済的に処理できます。 DON 参加者が異なる処理を行う可能性がある計算集約型ジョブの場合 複雑な入力に関する見解では、結果を計算する前に入力に関する合意を確立するために、DON 参加者間で追加のコミュニケーションが必要になる場合があります。 最終的な値が入力によって完全に決定される限り、入力のコンセンサスが確立されると、各参加者は単純に値を計算して他の参加者にブロードキャストできます。参加者に部分署名を付けるか、それをアグリゲーターに送信します。 7.2 DON 信頼の最小化 DON のコンポーネントに対する信頼を最小限に抑えるには、主に 2 つの方法を想定しています。 フェールオーバー クライアントとマイノリティ レポート。 7.2.1 フェイルオーバークライアント 暗号化および分散システムの文献における敵対的モデルは通常、 ノードのサブセットを破壊 (つまり侵害) できる敵を考えてみましょう。 たとえば、多くの BFT プロトコルでは 3 分の 1 未満です。一般的に観察されることですが、 すべてのノードが同一のソフトウェアを実行している場合、攻撃者が致命的なエクスプロイトを特定する可能性があります。 原則として、すべてのノードが多かれ少なかれ同時に侵害されます。この設定は多くの場合、 ソフトウェアモノカルチャー[47]と呼ばれます。 この問題に対処するために、ソフトウェアおよびソフトウェア構成を自動的に多様化するためのさまざまな提案が提出されている (例: [47, 113])。 [47] に記載されているように、 ただし、ソフトウェアの多様性は複雑な問題であり、慎重な検討が必要です。たとえば、ソフトウェアの多様化は、モノカルチャーよりもセキュリティが悪化する可能性があります。 システムの攻撃対象領域が増加し、その結果、可能性のある攻撃ベクトルが超過します。 セキュリティのメリットが得られます。 私たちは、堅牢なフェイルオーバー クライアント (つまり、どのノードに接続するクライアント) のサポートが重要であると考えています。 壊滅的な出来事に直面すると切り替えることができます。これは特に魅力的な形態です。 ソフトウェアの多様化。フェイルオーバークライアントは潜在的なベクトルの数を増加させません これらはメインライン ソフトウェアとして展開されていないため、攻撃の危険性が高まります。それらは明らかな利点を提供します。 ただし、第二の防衛線として。 DONs でフェイルオーバー クライアントをサポートする予定です。 これは、単一クライアントへのセキュリティへの依存を軽減するための重要な手段です。 Chainlink には、フェイルオーバー クライアントの堅牢なシステムがすでに導入されています。私たちのアプローチ これには、実戦テストされた以前のクライアント バージョンの維持が含まれます。たとえば、現在、オフチェーン レポート (OCR) をプライマリ クライアントとして使用する Chainlink ノードにはサポートが含まれています。 必要に応じて、Chainlink の以前の FluxMonitor システム用。ある程度使用されていたので FluxMonitor はセキュリティ監査とフィールド テストを受けています。同じものを提供します OCR としての機能を利用するには、コストがかかるだけです。コストは必要な場合にのみ発生します。 7.2.2 マイノリティ・レポート オマイノリティ (多数派による不正行為を観察する誠実なノードの一部) が十分に大きい少数派セットである場合、少数派を生成するのに役立つ可能性があります。 報告する。これは並行レポートまたはフラグであり、オンチェーンの従属契約 SC に中継されます。 オマイノリティによる。 SC は、独自の契約固有のポリシーに従ってこのフラグを使用できます。 たとえば、生存性や応答性よりも安全性が重要である契約の場合、少数派の報告により、契約は補足報告を要求する可能性があります。 別の DON から接続するか、サーキット ブレーカーをトリガーします (次のセクションを参照)。たとえ大多数が正直であっても、少数派の報告は重要な役割を果たすことができます。 なぜなら、レポート集計スキームは、機能的シグネチャを使用する場合でも、 oracle またはデータ障害に対する回復力を確保するために、しきい値方式で動作します。で 言い換えれば、次の入力に基づいて有効なレポートを作成できなければなりません。 kS < nS oracles、あるしきい値 kS の場合。 これは、破損した DON には、 優先 kS 値を選択することにより、レポート値を操作する自由度が高くなります。 すべてのソースが正直である場合でも、V では oracle の完全なセットによって nS が報告されます。 たとえば、関数型を使用するシステムで nS = 10 および kS = 7 であると仮定します。 ETH の USD 価格の V に対する中央値の計算を認証するための署名。 5 つの情報源が \(500, while the other five report \)1000 の価格を報告しているとします。 次に、下位 7 つのレポートを中央値化することにより、DON は有効な値 v = $500 を出力できます。 そして最高値を中央値化すると、v = $1000 が出力されます。 DON プロトコルを強化して、すべてのノードがどのデータがあったかを認識できるようにする 利用可能なデータ、およびレポートの作成に使用されたデータをノードが検出してフラグを立てることができます。 あるセットのレポートを別のセットのレポートよりも好むという統計的に有意な傾向があり、 結果として少数派の報告書となる。 7.3 ガードレール DONs の信頼モデルは、MAINCHAIN をより高いセキュリティとより高い特権として扱います。 DONs よりもシステムが優れています。 (この信頼モデルは必ずしも当てはまらないかもしれませんが、より簡単です DON の方がセキュリティが高い状況に結果のメカニズムを適応させるため プラットフォームはその逆です)。 したがって、自然な信頼最小化戦略には、smart contracts (MAINCHAIN フロントエンドのいずれか) での監視およびフェイルセーフ メカニズムの実装が含まれます。 DON の場合、または従属契約 SC 内で直接。これらのメカニズムを次のように呼びます。 ガードレール、そして最も重要なものをここにいくつか列挙します。 • サーキットブレーカー: SC は、状態更新自体の特性 (例: シーケンシャル間の大きな差異など) のいずれかの関数として、状態更新を一時停止または停止することがあります。 レポート）、または他の入力に基づいて。たとえば、サーキットブレーカーが落ちる可能性があります。 oracle レポートが時間の経過とともに信じられないほど変化する場合。サーキットブレーカーが作動する可能性があります マイノリティレポートにもつまずかれる。したがって、サーキットブレーカーはDONを防ぐことができます 著しく誤った報告をしないこと。 サーキットブレーカーは、追加の介入を検討するための時間を提供することができます または運動した。そのような介入の 1 つは避難ハッチです。 • 避難用ハッチ: 管理者、コミュニティ token 保持者、またはその他の受託者団体によって特定された不利な状況下では、契約によって以下の措置が講じられる場合があります。 緊急設備は避難ハッチ [163] とも呼ばれます。脱出ハッチ SC を何らかの方法でシャットダウンしたり、保留中の終了を引き起こしたり、場合によっては 今後の取引。たとえば、保管されている資金をユーザーに返還する場合があります ([17])、契約条件 [162] を終了するか、保留中の取引および/または今後の取引 [173] をキャンセルする場合があります。避難ハッチは、あらゆるタイプの契約に導入できます。 DON に依存するものですが、それらは潜在的なバッファーとして興味深いものです。 DON 不正行為。 • フェイルオーバー: SC が重要なサービスについて DON に依存しているシステムでは、SC がフェイルオーバー メカニズムを提供して、たとえ DON の失敗または不正行為の場合。たとえば、TEF (セクション 6) では、次のようになります。 アンカー コントラクト SCa は、オンチェーンと オフチェーン実行インターフェイスは、特定の重要な操作 (例: 引き出し）、または通常のトランザクションの場合は、DON トランザクションのフロントランニングを防ぐために適切な遅延が発生します。データ ソースがデータに署名する場合、ユーザーは DON が失敗した場合にも、SCa に報告書を提出します。 さまざまな形式の楽観的 rollup に対して提案されている不正証明 (セクション 6.3 を参照)、 風味が似ており、上で列挙したメカニズムを補完します。彼らは また、オンチェーン監視の形式と潜在的な障害に対する保護も提供します。 オフチェーン システム コンポーネント。 7.4 信頼を最小限に抑えたガバナンス すべての分散システムと同様、Chainlink ネットワークにはガバナンス メカニズムが必要です 時間の経過とともにパラメータを調整し、緊急事態に対応し、その進化を導きます。 これらのメカニズムの一部は現在 MAINCHAIN 上に存在しており、今後も存続する可能性があります。 DONs の展開でもそうしてください。一例として、支払いメカニズムが挙げられます。 oracle ノード プロバイダー (DON ノード) の場合。 DON MAINCHAIN 上のフロントエンド コントラクト ガードレールなどの追加の機構が含まれており、定期的な規制を受ける可能性があります。 改造。 私たちは、進化型と緊急型という 2 つの種類のガバナンス メカニズムを予測しています。 進化的ガバナンス: Chainlink エコシステムに対する多くの変更は、 実装が緊急の問題ではないようにします: パフォーマンスの向上、 機能強化、（緊急ではない）セキュリティ アップグレードなど。 Chainlink はガバナンスへの参加者をさらに増やす方向に徐々に移行しており、多くの参加者や参加者が増えることが予想されます。 このような変更のほとんどは、影響を受ける特定の DON のコミュニティによって承認される必要があります。 変化します。暫定的に、そしておそらく最終的には並行メカニズムとして、私たちは次のように信じています。 一時的な最小特権の概念は、進化的ガバナンスを実装する有用な手段となり得るということです。非常に簡単に言うと、変更を段階的に展開して、 コミュニティは彼らに応える機会です。たとえば、新しいものへの移行 MAINCHAIN コントラクトは、新しいコントラクトをデプロイする必要があるように制約することができます 有効化の少なくとも 30 日前までに。緊急時のガバナンス: MAINCHAIN の悪用可能な脆弱性または悪用された脆弱性 契約やその他の形式の生存性または安全性の欠陥では、壊滅的な結果を防ぐために即時介入が必要になる場合があります。私たちの目的はマルチシグをサポートすることです あらゆる組織による不正行為を確実に防止するための介入メカニズム。 署名者は組織全体に分散されます。署名者の一貫した可用性を確保する 緊急事態の許可のための適切な指揮系統へのタイムリーなアクセス 変更には、慎重な運用計画と定期的なレビューが必要であることは明らかです。これら 課題は、他のサイバーセキュリティ インシデント対応のテストに伴う課題と似ています。 能力 [134] は、警戒力の低下 [223] などの一般的な問題に対処するための同様の必要性を伴います。 DON のガバナンスは、多くの分散システムのガバナンスとは異なります。 潜在的な異質性の程度。各 DON には、個別のデータ ソース、実行可能ファイル、稼働時間などのサービス レベル要件、ユーザーが含まれる場合があります。 Chainlink ネットワークの ガバナンスメカニズムは、そのような変化に対応できる十分な柔軟性を備えていなければなりません。 運用上の目標とパラメータ。私たちはデザインのアイデアを積極的に検討しており、次のことを計画しています。 将来的にはこのテーマに関する研究を発表する予定です。 7.5 公開鍵インフラストラクチャ 分散化が進むにつれて、 DON ノードを含むネットワーク参加者。特に、Chainlink には強力な 公開鍵インフラストラクチャー (PKI)。 PKI は、キーを ID にバインドするシステムです。のために たとえば、PKI はインターネットの安全な接続 (TLS) システムを支えています。 HTTPS (例: https://www.chainlinklabs.com) を介して Web サイトに接続し、 ブラウザにロックが表示されます。これは、ドメイン所有者の公開キーが 権限によって、具体的にはデジタル署名を通じてその所有者に結び付けられています。 いわゆる証明書。認証局 (CA) の階層システムは、そのトップレベルのルート認証局が一般的なブラウザに組み込まれており、証明書の確実な発行に役立ちます。 ドメインの正当な所有者にのみ発行されます。 Chainlink は最終的には分散型ネーム サービスを利用することになると予想しています。 最初は、PKI の基盤として、Ethereum ネーム サービス (ENS) [22] を使用しました。として その名前が示すように、ENS は DNS (マッピングを行うドメイン ネーム システム) に似ています。 (人間が読める) ドメイン名をインターネット上の IP アドレスに変換します。ただし、ENS は代わりに、人間が判読できる Ethereum 名を blockchain アドレスにマッピングします。 ENSだから Ethereum blockchain 上で動作し、鍵の侵害や改ざんがない限り、 名前空間は原則として、それを管理する契約を改ざんするのと同じくらい難しい および/または基礎となるblockchain。 (対照的に、DNS は歴史的に脆弱でした) スプーフィング、ハイジャック、その他の攻撃から保護します。) 私たちは data.eth を Ethereum メインネット上の ENS に登録しており、 これをルート名前空間として確立し、その下に oracle データ サービスの ID と 他の Chainlink ネットワーク エンティティが存在します。 ENS のドメインは階層構造になっており、各ドメインに参照が含まれる可能性があります。 その下の他の名前に。 ENS のサブドメインは、組織化および委任の信頼。 data.eth の主な役割は、オンチェーン ディレクトリ サービスとして機能することです。 データフィード。従来、oracles の開発者とユーザーはオフチェーン ソースを使用してきました。 (例: docs.chain.link や data.chain.link などの Web サイト、または次のようなソーシャル ネットワーク Twitter) oracle データ フィード アドレス (ETH-USD 価格など) を公開および取得する フィード）。 data.eth などの信頼性の高いルート名前空間を使用すると、代わりに、smart contract アドレスなどへの eth-usd.data.eth のマッピングを確立することができます。 ETH-USD 価格フィード用のオンチェーン oracle ネットワーク アグリゲーターの。これは 誰もがblockchainを信頼できる情報源として参照できる安全なパスを作成します。 その価格/名前ペア (ETH-USD) のデータ フィード。したがって、ENS のそのような使用は、 オフチェーン データ ソースでは利用できない 2 つの利点を実現します。 • 強力なセキュリティ: ドメインに対するすべての変更と更新は不変に記録されます。 Web サイト上のテキスト アドレスとは対照的に、暗号化によって保護されています。 これら 2 つのセキュリティ特性のどちらも享受できません。 • 自動化されたオンチェーン伝播: データフィードの smart contract の基礎となるアドレスを更新すると、依存するスマートに伝播する通知をトリガーできます。 契約を作成し、たとえば、依存する契約を自動的に更新できます。 新しいアドレス.13 ただし、ENS のような名前空間は、正当な所有権を自動的に検証しません。 アサートされた名前の。したがって、たとえば、名前空間に次のエントリが含まれている場合、 ⟨「Acme Oracle Node Co.」、addr⟩、 そうすれば、ユーザーは、addr が Acme という名前の主張者に属しているという保証を得ることができます。 Oracle Node Co. ネームスペース管理に関する追加のメカニズムがなければ、 ただし、その名前が合法的に実体に属しているという保証は得られていません。 現実世界では意味のある意味で Acme Oracle Node Co. と呼ばれます。 名前の検証に対する私たちのアプローチ、つまり、対応する正当な現実世界のエンティティによる名前の所有権の確保は、いくつかのコンポーネントに依存しています。今日、Chainlink 研究室 Chainlink ネットワークの CA として効果的に機能します。 Chainlink ラボは継続します 名前を検証するために、PKI は次の 2 つの方法でより分散化されたモデルに進化します。 • Web-of-trust モデル: 階層型 PKI の分散型モデルは、多くの場合、web-of-trust と呼ばれます。14 バリアントは 1990 年代から提案されてきました。 例: [98]、そして多くの研究者は、blockchain が世界的に一貫した形式で証明書を記録することによって、アイデア (例: [227]) の使用を容易にすることができることを観察しています。 台帳。私たちは、エンティティの身元を検証するために、このモデルのバリアントを調査しています。 Chainlink ネットワーク内でより分散化された方法で。 13A 従属契約には、手動検査を可能にするための所定の遅延をオプションで含めることができます。 および従属契約管理者による介入。 14Phil Zimmermann が PGP [238] のために作った用語。• 検証データへのリンク: 現在、かなりの量の oracle ノード パフォーマンス データがチェーン上で表示され、アーカイブ的にノード アドレスにバインドされています。 このようなデータは、ネットワークへの (信頼できる) 参加の歴史的証拠を提供することによって、PKI のアイデンティティを強化すると見なすことができます。さらに、ツール DECO および Town Crier [160] に基づく分散型アイデンティティのノードの有効化 実世界のデータから得られた認証情報を蓄積します。ほんの一例として、 ノードオペレーターは、所有を証明する資格情報をその PKI ID に添付できます。 ダンとブラッドストリートの評価の。これらの補足的な検証形式では、 ネットワークのセキュリティを保証するために、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 の既存の Web サイトから data.eth にリンクする（例: https://docs.chain.link. (インターネット ドメインに対する PKI のもう 1 つの暗黙的な使用。) • このホワイトペーパーを含むさまざまな文書を通じて 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 موقعة مباشرة بواسطة البيانات

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

الشكل 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 をより広範に使用できるようにすることです。 任意の実行可能ファイルを起動します。後でサポートされる予定です。 このような注意が必要な理由の 1 つは、最近のフラッシュ ローン ベースの攻撃のように、smart contract の構成には複雑で意図しない危険な副作用が生じる可能性があるためです。 たとえば[127、189]に示されています。同様に、smart contract、アダプター、および 実行可能ファイルには細心の注意が必要です。 DONs の最初の展開では、テンプレート化された実行可能ファイルとアダプターの事前構築済みセットのみを含める予定です。これにより、構成的安全性の研究が可能になります。 形式的な手法 [46、170] やその他のアプローチを使用して、これらの機能を解析します。そうなります また、価格設定も簡素化します。機能の価格設定は、一般化されたメータリングではなく、機能ごとに基づいて DON ノードによって確立できます。このアプローチは採用されています。 例: [156]。また、Chainlink コミュニティが作成に参加することも期待しています。 追加のテンプレートを使用して、さまざまなアダプターと実行可能ファイルを組み合わせて、 数千ではないにしても、数百の個人によって実行できる便利な分散型サービス DON秒。 さらに、このアプローチは、状態の肥大化、つまり DON の必要性を防ぐのに役立ちます。 ノードを使用して、作業不可能な量の状態を作業メモリに保持します。この問題は パーミッションレス blockchain ではすでに発生しており、「ステートレス」などのアプローチが動機付けられています。 クライアント」（[206] などを参照）。高スループットのシステムではより深刻になる可能性があり、モチベーションが高まります。 DON が状態サイズに最適化された実行可能ファイルのみをデプロイするアプローチ。 DON が進化し成熟し、セクション 7 で説明した堅牢なガード レール、セクション 9 で説明した暗号経済およびレピュテーション ベースのセキュリティ メカニズム、および DON ユーザーに高度な保証を提供するその他の機能が組み込まれるにつれて、私たちは また、より広範な立ち上げと使用を促進するためのフレームワークとツールを開発することも期待されています。 コミュニティによるDONs。理想的には、これらのツールによりノード オペレーターのコレクションが可能になります。 oracle ネットワークとして統合し、パーミッションレスで独自の DON を起動します。 またはセルフサービス方式、つまり一方的に行うことができます。 8.2 動的 DON メンバーシップ 特定の DON を実行するノードのセットは、時間の経過とともに変化する可能性があります。 2つのアプローチがあります O の動的メンバーシップが与えられた skL の鍵管理に。 1 つ目は、メンバーシップの変更時にノードが保持する skL のシェアを更新することです。 pkL を変更しないままにします。 [41、161、198] で検討されているこのアプローチには利点があります。 証明書利用者が pkL を更新することを要求しないこと。[122] で導入された共有再共有の古典的な手法は、簡単な機能を提供します。 そしてそのような共有の更新を実現する効率的な方法。シークレットの転送が可能になります 1 つのノードのセット O(1) と、おそらく交差する 1 つのノード O(2) との間。この中で アプローチ、各ノード O(1) 私は 秘密共有の (k(2), n(2)) 秘密共有を実行します。 n(2) = |O(2)| の O(2) 内のノードおよび望ましい（おそらく新しい）閾値 k(2)。さまざまな検証可能な秘密共有 (VSS) スキーム [108] は、次のような敵に対してセキュリティを提供できます。 ノードを積極的に破壊します。つまり、プロトコルに悪意のある動作を導入します。 [161] の技術は、通信の複雑さを軽減し、提供することを目的としています。 暗号強度の仮定における失敗に対する回復力。 2 番目のアプローチは、レジャーキー pkL を更新することです。これには前進する利点があります セキュリティ: pkL の古い共有 (つまり、以前の委員会ノード) が侵害されることはありません 現在のキーが侵害される可能性があります。ただし、pkL のアップデートには 2 つの欠点があります。 (1) pkL で暗号化されたデータはキー更新時に再暗号化する必要がある、および (2) 主要な更新は信頼当事者に伝播する必要があります。 私たちは両方のアプローチと、その 2 つのハイブリッド化を検討するつもりです。 8.3 DON 説明責任 既存の Chainlink oracle ネットワークと同様に、DONs には、正しいノード動作の記録、監視、強制などの説明責任のメカニズムが含まれます。 DON は 既存の多くの許可のない blockchain よりもはるかに大きなデータ容量、 特に外部の分散ストレージに接続できる機能を考慮すると、その結果、ノードのパフォーマンス履歴を詳細に記録できるようになり、 よりきめの細かい説明責任メカニズム。たとえば、次のオフチェーン計算 資産価格には、中央値の結果が送信される前に破棄される入力が含まれる場合があります。 チェーン。 DON には、これらの中間結果を記録できます。したがって、DON 内の個々のノードによる不正な動作やパフォーマンスの低下は、修正またはペナルティを受ける可能性があります。 DON をきめ細かい方法で確認します。構築するためのアプローチについても説明しました。 システム障害による契約固有の影響に対処するセクション 7.3 のガード レール。 ただし、DON 自体にフェイルセーフ メカニズムを設けることも重要です。 具体的には、システム全体の、潜在的に壊滅的なDON障害に対する保護です。 これから説明するように、フォーク / あいまいさおよびサービス レベル アグリーメント (SLA) の失敗について説明します。 分岐/曖昧さ: 障害のあるノードが十分に多い場合、DON はフォークする可能性があります または曖昧で、L 内に 2 つの別個の矛盾したブロックまたはブロックのシーケンスが生成されます。 ただし、DON は L の内容にデジタル署名するため、 メインチェーン MAINCHAIN を使用して、あいまいな表現を防止および/またはペナルティを課します。 DON は、MAINCHAIN 上の監査コントラクト内の L からの状態を定期的にチェックポイントできます。 将来の状態がチェックポイント設定された状態から逸脱した場合、ユーザー/監査人は証拠を提示できます。 この不正行為を監査契約に反映させます。このような証拠は、アラートを生成するために使用できます。 または、コントラクト内のスラッシュによって DON ノードにペナルティを課します。後者のアプローチでは、次のようなことが起こります。 特定の oracle フィードの場合と同様のインセンティブ設計の問題であり、それに基づいて構築することができます 私たちの取り組みについてはセクション 9 で概説します。サービスレベル契約の強制: DON は必ずしも次のことを意図しているわけではありませんが、 無期限に実行されるため、サービス レベル アグリーメント (SLA) に準拠することが重要です ユーザーとともに。基本的な SLA の適用はメイン チェーンで可能です。たとえば、 DON ノードは、特定の日付まで DON を維持すること、またはサービス終了の事前通知 (例: 3 か月前の通知) を提供することを約束する場合があります。に関する契約 MAINCHAIN は、基本的な暗号経済 SLA 強制を提供できます。 たとえば、チェックポイントが設定されている場合、SLA 契約では DON が預け入れた資金を削減できます。 必要な間隔で提供されていない。ユーザーは資金を入金し、DON に挑戦できます。 チェックポイントが一連の有効なブロックを正しく表していることを証明するため(ある方法) たとえば、に似ています。 [141])。もちろん、ブロックの生成はトランザクションと同等ではありません ただし、SLA 契約は後者を強制する役割も果たします。たとえば、 FSS のレガシー互換バージョンでは、トランザクションがメモリプール (セクション 5.2 を参照) からフェッチされ、トランザクションは最終的にマイニングされてチェーン上に配置されます。ユーザー SLA 契約に以下のトランザクションを提供することで、DON の不正行為を証明できます。 マイニングされましたが、ターゲット コントラクトによる処理のために DON によって送信されませんでした 適切な時間内に。15 よりきめ細かい SLA の存在を証明し、罰則を課すことも可能です 実行可能ファイルを使用した計算エラーを含む失敗（たとえば、メカニズムを介して） セクション 6.3 で概説されているオフチェーン状態のトランザクションが正しいこと、または実行に失敗したことを証明するため DON で表示されるイニシエーターに基づく実行可能ファイル、DON 上のデータの中継に失敗する タイムリーなメインチェーンなど。

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 プロトコルに準拠します。このセクションでは、アプローチについて説明します 経済的インセンティブ、別名暗号経済によってそのような行為の強制を支援すること インセンティブ。 これらのインセンティブは、明示的と暗黙的、実現化の 2 つのカテゴリに分類されます。 それぞれ staking および将来の手数料機会 (FFO) を通じて。 ステーキング: Chainlink でのステーキングには、他の blockchain システムと同様に、ネットワーク参加者、つまり oracle ノードが関与し、ロックされた資金を LINK token の形式で預け入れます。これら ファンド（ステークまたは明示的ステークとも呼ばれます）は、明示的なインセンティブです。彼らは ノードの障害または不正行為により、権利が剥奪される可能性があります。 blockchain のコンテキストでは、 この手順は、多くの場合、スラッシュと呼ばれます。 ただし、Chainlink の oracle ノードによるステーキングは、staking とは根本的に異なります。 validators による、権限のない blockchains です。バリデーターは、トランザクションを曖昧にしたり、敵対的に順序付けたりすることで不正行為を行う可能性があります。 基礎となるコンセンサスプロトコル 15ユーザーはメモリプール内のトランザクションを置き換えることができるため、マイニングされたトランザクションと DON によって送信されたトランザクションが正しく対応するように注意する必要があります。ただし、権限のない blockchain は、厳格なブロック検証ルールと暗号化プリミティブを使用して、validator が無効なブロックを生成するのを防ぎます。対照的に、 プログラムによる保護では、不正な oracle ネットワークによる生成を防ぐことはできません。 無効なレポート。その理由は、2 つのタイプのシステム間の重要な違いです。blockchains のトランザクション検証は内部一貫性の特性であるのに対し、正確性は内部一貫性の特性です。 blockchain に関する oracle のレポートは、外部データ、つまりオフチェーン データのプロパティです。 私たちは、Chainlink ネットワークベースの予備的な staking メカニズムを設計しました。 外部データを利用する可能性がある oracle ノード間の対話型プロトコル上で。これ このメカニズムは、明示的な報酬を使用して、正しい行動に対する金銭的インセンティブを生み出します。 ペナルティ（斬り）。経済的な仕組みなので、ノードの発生を防ぐことができます。 攻撃者が金融リソースを使用してノードを破壊することによる破壊 賄賂。 (そのような敵対者は非常に一般的であり、例えば、協力しているノードにまで広がります。 彼らの集団的な不正行為から価値を引き出す。） 私たちが設計した Chainlink staking メカニズムには、いくつかの強力で斬新な機能が備わっています。 16 そのような主な機能は、超線形 staking 衝撃 (具体的には 2 次) です。 敵は、ノードが預けた資金を大幅に超えるリソースを持っている必要があります。 メカニズムを破壊するために。当社の staking メカニズムは、同様のシステムでこれまで考えられていたよりも強力な敵対者に対する保護も提供します。 ノードの将来の行動に条件を付けて賄賂を生み出すことができる敵。さらに、DECO などの Chainlink ツールが 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 ノードに対する 2 つの主な経済的インセンティブを要約すると、 開発中の Chainlink ネットワークでの動作は次のようになります。 • ステーキング（賭け金） ああ 明示的なインセンティブ • 将来の手数料機会 (FFO) ああ 暗黙のインセンティブ これら 2 つの形式のインセンティブは補完的です。 Oracle ノードは同時に Chainlink staking プロトコルに参加し、からの継続的な収益源を享受します。 ユーザーの継続的な善良な行動から、全員が利益を得ることができます。したがって、両方のインセンティブが oracle ネットワークによって提供される暗号経済セキュリティに貢献します。さらに、 2 つのインセンティブは相互に強化したり、相互にトレードしたりすることができます。たとえば、 実績履歴も収入源もない新しいoracleオペレーターは、 誠実な行動を保証するための大量のリンクがユーザーを引き付ける そして手数料。逆に、確立された oracle オペレーターは、長くて比較的障害が少ない パフォーマンス履歴により、大規模なユーザー ベースから多額の料金が請求される可能性があるため、 暗黙のインセンティブとして FFO をより重視します。 一般に、ここで検討するアプローチは、指定された量の oracle-ネットワークを目的としています。 合理的な目的のためにChainlinkで可能な限り最大の経済的インセンティブを生み出すためのリソース エージェント、つまり財務的効用を最大化するノードは誠実に行動する必要があります。もう一つ入れて つまり、目標は、敵対者が攻撃するために必要な財務リソースを最大化することです ネットワークが正常に接続されました。 staking プロトコルを数学的に適切に定式化することにより、 私たちは、経済安全保障を定義し、また IIF を使用して、経済安全保障の強さを測定することを目指しています。 Chainlink のインセンティブをできるだけ正確に。依存契約の作成者は、 そうすれば、oracle ネットワークが条件を満たしているかどうかを強い自信を持って判断できるようになります。 必要な暗号経済セキュリティのレベル。 経済安全保障の好循環: このセクションで説明するインセンティブ、staking と FFO は、セキュリティの強化を超えた影響を及ぼします。 DON秒。彼らは、私たちが経済安全保障の好循環と呼ぶものを誘発すると約束しています。 超線形 staking の影響 (およびその他の規模の経済) により、運用効率が低下します。 DON のセキュリティが増大するにつれてコストが増加します。低コストにより、DON に追加のユーザーが集まります。追加料金の支払い。手数料支払いの増加は引き続き成長を促進します。 ネットワークを構築し、好循環を永続させます。 私たちは、経済安全保障の好循環はほんの一例にすぎないと信じています。 特に規模の経済性とネットワーク効果については、このセクションで後ほど説明します。 セクションの構成: ステーキングは、注目すべき技術的および概念的な課題を提示します。 斬新な機能を備えた機構を設計しました。したがって、ステーキングは次のようになります。 このセクションの主な焦点は次のとおりです。 この文書で紹介する staking アプローチの概要をセクション 9.1 で説明し、続いてセクション 9.2 ～ 9.5 で詳細に説明します。 IFFを紹介します セクション9.6に記載されています。 Chainlink ネットワーク インセンティブの概要をセクション 9.7 に示します。 セクション 9.8 では、私たちが提案する staking アプローチが oracle ネットワークにもたらすことができる経済安全の好循環について説明します。最後に、その他の可能性について簡単に説明します。 セクション 9.9 の Chainlink ネットワークの成長を促進する効果があります。 9.1 ステーキングの概要 ここで紹介する staking メカニズム設計には、上で述べたように、oracle ノード間の対話型プロトコルが含まれており、 外部データのレポート。ステーキングは、合理的な oracle ノードからの誠実な動作を保証することを目的としています。したがって、staking プロトコルを攻撃する敵をモデル化できます。 賄賂: 敵対者の戦略は、金銭的インセンティブを利用して oracle ノードを破壊することです。 敵対者は、改ざんに成功することで将来的に資金を得る可能性がある oracle レポートを使用して、たとえば、結果として得られた利益を破損したノードと共有することを提案します。 私たちは staking メカニズム設計において、次の 2 つの野心的な目標を同時に目指しています。 1. 強力な敵に対抗する: staking メカニズムは、 oracle ネットワークは、複雑な攻撃を行うことができる広範なクラスの敵に対して対抗します。 賄賂を提供する見込賄賂を含む、条件付き賄賂戦略 事後的に身元が判明したoracleに（例：賄賂を提供するなど） oracle は高優先度のアラート用にランダムに選択されます)。他のoracleデザインは 現実的な攻撃の全機能を持たない狭い範囲の攻撃を検討してきました。 敵対者、私たちが知る限り、私たちが導入する敵対的メカニズム ここは、広範な賄賂戦略に明示的に取り組み、その結果を示した最初の企業です。 このモデルの抵抗。私たちのモデルは、攻撃者以外のノードが （正直ではなく）経済的に合理的であり、私たちは、 通常の使用法では法外に高価だが入手可能な信頼できる情報源 意見の相違がある場合には（以下でさらに説明します）。 2. 超線形 staking 効果の達成: 私たちの目的は、合理的なエージェントで構成される oracle ネットワークがレポートを確実に実行できるようにすることです。 正直なところ、超線形の予算を持つ攻撃者の存在下でもです。ネットワーク全体によって預けられた賭け金の合計に相当します。既存の staking システムでは、 n 個のノードのそれぞれが $d を賭けると、攻撃者は要求に応じて信頼できる賄賂を発行することができます。 ノードは、わずかに高い金額の支払いと引き換えに不正な行為を行う \(d to each node, using a total budget of about \)dn。これはすでに高いハードルです 攻撃者は、次の預金を合わせた程度の流動的な予算を持っている必要があります。 ネットワーク内のすべての関係者。私たちの目標は、さらに強力な経済安全保障です。 このすでに大きなハードルよりも。私たちは最初のstakingシステムを設計することを目指しています n 単位の超線形予算で一般攻撃者のセキュリティを実現できます。 以下で説明するように、実際的な考慮事項の影響は小さくなる可能性がありますが、 私たちの予備設計では、敵対的な予算要件を超える予算が達成されます。 $dn2/2、つまり n で 2 次スケーリングし、賄賂をほとんど非現実的にする ノードが中程度の金額のみをステーキングする場合。 これら 2 つの目標を達成するには、インセンティブ設計の革新的な組み合わせが必要です そして暗号化。 重要なアイデア: 私たちの staking アプローチは、ウォッチドッグ優先度と呼ばれる考え方に基づいています。 Chainlink oracle ネットワークによって生成され、信頼するコントラクトに送信されるレポート （例えば、資産価格について）参加ノードによって提供された個々のレポートから（例えば、中央値を取ることによって）集約されます。通常はサービス レベル アグリーメント (SLA) レポートの許容偏差範囲、つまりノードのレポートがどこまで許容できるかを指定します。 集計レポートからの逸脱、および集計がどの程度まで許容されるべきか 正しいとみなされる真の値から逸脱していること。 staking システムでは、特定のレポート ラウンドで、各 oracle ノードが次のように機能します。 ウォッチドッグは、集計レポートが正しくないと思われる場合にアラートを生成します。それぞれに レポート ラウンドでは、各 oracle ノードには、公開優先度が割り当てられます。 アラート (存在する場合) が処理される順序。私たちの仕組みは報酬を目的としています これは、アラートを発生させる最も優先度の高いウォッチドッグが、 障害のあるノードの預金を没収することで得られる報酬全体。 当社の staking システム設計には 2 つの層が含まれます。最初のデフォルト層と 2 番目の層です。 バックストップ層。最初の層は oracle ネットワーク自体であり、n 個のノードのセットです。 (簡単にするために、 n は奇数であると仮定します。) 大多数のノードが誤った値を報告すると、ノードのウォッチドッグが 第 1 層には、警告を発する強い動機が与えられています。アラートが発生した場合、レポートは その後、ネットワークの決定は第 2 層にエスカレートされます。これは、ネットワーク サービス レベル アグリーメントでユーザーが指定できる、高コストで信頼性が最大のシステムです。 これは、たとえば、強力なノードのみで構成されるシステムである可能性があります。 過去の信頼性スコア、またはそれよりも oracle 秒が桁違いに多いスコア 最初の層。さらに、セクション 9.4.3 で説明したように、DECO または Town Crier はサービスを提供できます。 第 2 段階での効率的かつ最終的な判決を確保するための強力なツールとして機能します。 簡単にするために、この第 2 層システムが正しいレポートに到達すると仮定します。 値。 すべてのレポートを生成するために第 2 層に依存するだけでも魅力的に見えるかもしれませんが、 私たちの設計の利点は、そのセキュリティ特性を一貫して達成できることです。一般的なケースでは、第 2 層システムの運用コストのみを支払います。 第一層システム。 ウォッチドッグの優先順位により、次のように超線形 staking の影響が生じます。 第 1 層 oracle ネットワークが誤った結果と多数のウォッチドッグ ノードを出力します アラートが発生すると、staking インセンティブ メカニズムにより、最も優先度の高いウォッチドッグに報酬が与えられます。 (大多数の) 不正動作をしているノードのデポジットから $dn/2 を超える額が引き出されます。の したがって、報酬総額はこの 1 人の監視者の手に集中します。 敵対者が潜在的な監視者に約束しなければならない最低限の事項を決定する 警戒しないように奨励します。私たちのメカニズムでは、すべての oracle が確実に より優先度の高い番犬が賄賂を受け取った場合、番犬として行動するチャンス （そして警告しないことを選択した）、したがって、敵対者は以上の賄賂を提供する必要があります。 アラートの発生を防ぐために、すべてのノードに $dn/2 を追加します。 n 個のノードがあるため、 敵対者が賄賂を成功させるために必要な予算は、dn2/2 ドルを超えます。 は、ネットワーク内のノード数 n の二次関数です。 9.2 背景 staking に対する私たちのアプローチは、ゲーム理論とメカニズムの分野の研究に基づいています。 デザイン (MD) (教科書の参照については、[177] を参照)。ゲーム理論は数学的には 戦略的相互作用の正式な研究。この文脈では、ゲームはそのようなモデルです。 通常は現実世界において、利用可能なアクションのセットを体系化したインタラクション。 プレイヤーとして知られるゲームの参加者。ゲームでは、得られる報酬も指定されます 個々のプレイヤーによる報酬 - プレイヤーが選択したアクションと 他のプレイヤーの行動。おそらくゲームで研究されたゲームの最もよく知られた例 この理論は囚人のジレンマ [178] です。ゲーム理論家は通常、次のことを理解することを目指しています。 特定のゲームで表現される均衡 (存在する場合)。平衡というのは、 どのプレイヤーもより高いレベルを獲得できないような一連の戦略 (各プレイヤーに 1 つ) 戦略から一方的に逸脱することで利益を得る。 一方、メカニズムデザインは、次のようなインセンティブをデザインする科学です。 インタラクション (およびそれに関連するゲーム) の平衡には、望ましい特性があります。 MD はゲーム理論の逆とみなされるかもしれません: ゲームにおける標準的な質問 理論は、「インセンティブとモデルが与えられた場合、均衡はどうなるでしょうか?」というものです。 MDでは、 代わりに問題となるのは、「どのようなインセンティブがゲームに望ましい均衡をもたらすのか?」ということです。 メカニズム設計者の典型的な目標は、「インセンティブと互換性のある」メカニズムを作成することです。これは、メカニズムへの参加者 (例: オークションやその他の情報) を意味します。 引き出しシステム [228]) は、ある事柄について真実を報告するよう奨励されます (例: どのように 彼らは特定のアイテムを高く評価します）。ヴィックリー（セカンドプライス）オークションはおそらく 参加者が非公開入札を提出する、最もよく知られたインセンティブ互換メカニズム アイテムの場合、最高額入札者がアイテムを落札しますが、2 番目に高い価格を支払います [214]。クリプトエコノミクスは、暗号を利用するドメイン固有の形式の MD です。 分散システム内で望ましい均衡を生み出すための技術。 贈収賄と共謀は、MD の分野全体に重大な問題を引き起こします。ほとんどすべてのメカニズムは、側の契約として定義される共謀が存在すると機能しません。メカニズムに参加する当事者間 [125、130]。外部の関係者が新たなインセンティブをゲームに導入する贈収賄は、さらに困難な問題を引き起こします 共謀よりも。共謀はゲーム間の贈収賄の特殊なケースとみなされる可能性がある 参加者。 ブロックチェーン システムは、多くの場合、金銭 (暗号通貨ベース) の利益を伴うゲームとして概念化できます。簡単な例は、Proof-of-Work マイニングです。マイナーにはアクション スペースがあります。 ここでは、ブロックのマイニングに使用するhashレートを選択できます。マイニングの報酬は、保証されたマイナスの報酬 (電気と設備のコスト) に確率的報酬を加えたものです。 他のアクティブなマイナーの数に応じたプラスの報酬 (マイニング補助金) [106、172] および取引手数料。 SchellingCoin [68] のようなクラウドソースの oracle は別の例です。アクション スペースは、oracle が送信できる一連のレポートです。 報酬は、oracle メカニズムによって指定された報酬です。たとえば、支払いは状況に応じて異なります。 oracle のレポートが他のレポートの中央値にどの程度近いか [26、68、119、185]。 ブロックチェーン ゲームは、共謀や贈収賄攻撃の絶好の機会を提供します。確かに、 smart contracts はそのような攻撃を容易にすることさえあります [96、165]。おそらく最もよく知られているのは クラウドソーシング oracles に対する贈収賄攻撃は、p-plus-epsilon 攻撃 [67] です。この攻撃 これは、プレーヤーがブール値のレポート (つまり、偽または真) を送信し、同意した場合に p が与えられるというシェリングコインのようなメカニズムのコンテキストで発生します。 過半数の提出。 p プラス イプシロン攻撃では、攻撃者は確実に次のことを約束します。 たとえば、過半数の提出が正しい場合にのみ、偽の投票に対してユーザーに $p + ϵ を支払います。 その結果、すべてのプレイヤーが虚偽の報告をするよう動機づけられる均衡が生まれます。 他のプレイヤーが何をしているかに関係なく。その結果、賄賂はノードを誘導することができます。 実際に賄賂を支払わずに虚偽の報告をするという約束の賄賂によって（！）。 ただし、oracle、特にクラウドソーシングではない oracle に関連した他の賄賂戦略の検討は、かなり弱い敵対者に限定されています。 モデル。たとえば、PoW 環境では、研究者は結果に応じた条件を研究しました。 賄賂、つまり、対象メッセージが検閲に成功し、検閲されなかった場合にのみ支払われる賄賂。 個々のマイナーのアクションに関係なく、ブロック内に表示されます [96、165]。場合によっては ただし、p-plus-epsilon 攻撃以外では、oracle 件の攻撃のみが認識されています。 賄賂を受け取る者が条件付きで賄賂を送るという、厳密に限定された贈収賄モデル。 結果としての結果ではなく、個々のプレイヤーの行動です。 ここでは、インセンティブを維持する情報引き出しメカニズムの設計をスケッチします。 次のサブセクションで説明するように、強力な敵対的モデルでも互換性があります。 9.3 モデリングの仮定 このサブセクションでは、プレイヤーの行動と能力をモデル化する方法について説明します。 私たちのシステム、特に第 1 層 oracle ノード、第 2 層のノード (判定) レイヤーと敵。9.3.1 第一層インセンティブ モデル: 合理的なアクター 多くの blockchain システムは、ある程度の正直者を前提としたセキュリティに依存しています。 参加ノード。ノードは、たとえプロトコルに従った場合でも正直であると定義されます。 そうすることが経済的利益にならない場合。 Proof-of-Work システムは通常、 正直に言うとhashのパワーの大部分が必要ですが、プルーフ・オブ・ステーク・システムでは通常、正直に参加するすべてのステークの2/3以上が必要です。また、次のようなレイヤー2システムでさえも必要です。 仲裁 [141] には、少なくとも 1 人の誠実な参加者が必要です。 staking メカニズムのモデル化では、はるかに弱い仮定を立てます。 (なるように 明確で弱い仮定は、より強力なセキュリティ特性を意味するため、推奨されます。) 敵対者が一部 (少数派) のコントロールを破損していると仮定します。 第 1 層 oracle ノードの一部。残りのノードは正直なエージェントとしてモデル化されません。 しかし、合理的な期待効用最大化手段として。これらのノードは完全に利己的な金銭的インセンティブに従って動作し、期待される金銭的利益をもたらすアクションを選択します。 利益を得る。たとえば、ノードが報酬よりも多額の賄賂を提供された場合、 正直な行動をすれば、賄賂を受け取ります。 敵対的ノードに関する注意: 共通の信頼モデリングに従って、 分散型システムでは、すべてのノードが合理的である、つまり、ノードを最大化しようとしていると仮定します。 悪意のある敵によって制御されるのではなく、純収益が向上します。しかし、私たちの主張は— 特に超線形または二次 staking 衝撃 - 漸近的に提供されるホールド 敵対的に制御されるノードのセットは最大でも (1/2 −c)n であること (肯定的な場合) 定数 ｃ． 9.3.2 第 2 段階の裁定モデル: 仮定による正しさ セキュリティの実現に役立つ staking メカニズムの重要な機能を思い出してください。 合理的なノードに対するのは、その 2 層目のシステムです。 私たちが提案する staking メカニズムでは、oracle は次のことを示すアラートを生成する可能性があります。 メカニズムの出力が正しくないと考えられます。アラートにより高い信頼が得られます 第 2 層システムがアクティブ化され、正しい結果が報告されます。したがって、主要なモデリングは 私たちのアプローチの要件は、正しい判決、つまり、政府による正しい報告です。 第二層システム。 私たちの staking モデルは、腐敗せず、信頼性が最も高い信頼性の高い情報源として機能する第 2 層システムを前提としています。このようなシステムは高価で時間がかかる可能性が高いため、 一般的なケースでの使用には不適切です。ただし、均衡の場合、つまり、 第 1 層システムが正しく機能する場合、第 2 層システムは呼び出されません。 代わりに、その存在により、oracle システム全体のセキュリティが強化されます。 信頼性の高いバックストップ。 高信頼で高コストの裁定レイヤーの使用は、控訴プロセスに似ています ほとんどの司法制度の中心です。 oracle のデザインでもすでに一般的になっています。 システム、例: [119, 185]。第 2 層の実現へのアプローチについて簡単に説明します セクション9.4.3のメカニズムに記載されています。私たちの staking プロトコルは、第 2 層システムの想定される正しい判定を信頼できる脅威として使用し、oracle ノードによる正しいレポートを強制します。プロトコル によって識別されるレポートを生成する oracle ノードのステークの一部またはすべてを没収します。 第 2 層システムは正しくありません。これにより、Oracle ノードの誤動作が防止されます。 その結果生じる経済的ペナルティによって。このアプローチは、で使用されているものと風味が似ています。 楽観的な rollup、例: [141, 10]。 9.3.3 敵対的モデル 当社の staking メカニズムは、広範で明確に定義されたクラスの敵に対するセキュリティを実現しながら、真実の情報を引き出すように設計されています。以前の作品を改良しており、 これは、明示的な敵対的モデルを省略するか、敵対者の狭いサブクラス、たとえば、上で説明した p-plus-epsilon 敵対者に焦点を当てるかのいずれかです。私たちの目標は、staking を設計することです。 あらゆる種類の敵に対して正式に証明されたセキュリティを備えたメカニズム 実際に遭遇することになる。 私たちは、敵を固定の (パラメータ化可能な) 予算を持つものとしてモデル化します。 $B.攻撃者は、各 oracle と個別かつ機密に通信できます。 ネットワークを介して、個人oracleに秘密裏に賄賂の支払いを提供することができます。 メカニズムの公的に観察可能な結果次第です。結果を決定する 賄賂には、たとえば、oracle によって報告された金額や、あらゆる公開メッセージが含まれる場合があります。 任意の oracle によってメカニズムに送信され (アラートなど)、他のメカニズムによって報告された値 oracles、およびメカニズムによって出力された値。 無制限の機能を持つ攻撃者に対して安全を確保できるメカニズムはありません。したがって、一部の動作は非現実的または範囲外であると考えられます。攻撃者を想定します 標準の暗号化プリミティブを破ることはできず、上で述べたように、修正された暗号化プリミティブがあります ( 大規模になる可能性があります) 予算 B ドル。さらに、敵が制御していないと仮定します。 oracle ネットワーク内の通信、具体的には実質的に遅延できないこと 第 1 層ノードおよび/または第 2 層ノード間のトラフィック。 (攻撃者がそのような通信を観察できるかどうかは、以下で説明するように、特定のメカニズムによって異なります。) ただし、非公式ではありますが、上で述べたように、敵対者は次の可能性があると想定しています。(1) 腐敗 oracle ノードの一部 (定数 c の (1/2 −c) の一部)、つまり完全制御 (2) 支払いを保証して、希望するノードに賄賂を提供する 上で説明したように、敵対者によって指定された結果に基づいて。 私たちは敵対者の完全な正式なモデルや完全な分類を提供していませんが、 このホワイトペーパーではさまざまな賄賂権限について説明していますが、ここでは賄賂の種類の例を示します。 私たちのモデルには賄賂が含まれます。簡単にするために、oracles がブール値を出力すると仮定します。 正しい値 (w.l.o.g.) が true であり、最終結果が次のように計算されることをレポートします。 smart contract を使用するユーザーによって使用されるこれらのレポートの集合体。賄賂の 目的は、最終結果が不正確、つまり偽になることです。 • 無条件の賄賂: 賄賂は虚偽の報告をした oracle に $b の賄賂を提供します。 • 確率的賄賂: 賄賂は、oracle に対して、一定の確率 q で $b の賄賂を提供します。 それは虚偽の報告をします。• 虚偽の結果を条件とする賄賂: 賄賂は、最終結果が虚偽であることを条件として、虚偽を報告した oracle に $b の賄賂を提供します。 • 警戒条件なしの賄賂: 賄賂は報告するoracleに$bの賄賂を提供します。 アラートが発生しない限り false。 • p-plus-epsilon 賄賂: 賄賂は、虚偽の報告をした oracle に $b の賄賂を提供します。 oracle の大部分が false を報告しない限り。 • 賄賂候補者: 賄賂は、oracle が選択された方に前払いで $b の賄賂を提供します。 ランダム化された役割に対しては false が報告されます。私たちが提案する staking プロトコルでは、すべて ノードは潜在的なウォッチドッグとして機能し、ランダム化を示すことができます。 監視機関の優先事項は、贈収賄の可能性には適さない。多くのproof-of-work、proof-of-stake、および許可されたシステムは、将来の悪影響を受けやすいです。 しかし、贈収賄については、敵対関係においてそれを考慮することの重要性を示しています。 モデルを作成し、staking プロトコルがモデルに対して復元力があることを確認します。付録 E を参照 詳細については。 9.3.4 どれくらいの暗号経済セキュリティがあれば十分ですか? 合理的な攻撃者は、利益が得られる場合にのみ、システムを攻撃するために資金を費やします。 その支出よりも大きい。 したがって、敵対的モデルと提案された staking については、 このメカニズムでは、$B は敵対者が獲得できる潜在的な利益の尺度としてみなされる可能性があります。 oracle ネットワークを破損し、それを引き起こすことで、依存する smart contracts から抽出する 間違ったレポートまたはレポートのセットを生成するため。 oracle ネットワークかどうかを決定する際 目的に応じて十分な程度の暗号経済的セキュリティを提供するため、ユーザーは次のことを行う必要があります。 この観点からネットワークを評価してください。 実際の設定におけるもっともらしい敵対者の場合、$B は一般に次のようになることが予想されます。 smart contracts に依存する総資産よりも大幅に小さい。ほとんどの場合、それは 攻撃者がこれらの資産全体を抽出することは不可能です。 9.4 ステーキングメカニズム: スケッチ ここでは、staking メカニズムの主なアイデアと一般的な構造を示します。 現在検討中です。 プレゼンテーションを容易にするために、単純だが遅いものについて説明します。 (マルチラウンド) プロトコルについては、このサブセクションで説明します。ただし、この計画は非常に危険であることに注意してください。 実用的。このメカニズムによって提供される経済的保証、つまり障害のあるノードに対するペナルティとその結果としてのインセンティブを考慮すると、多くのユーザーは喜んでそうするかもしれません。 報告を楽観的に受け入れます。言い換えれば、そのようなユーザーは、事前にレポートを受け入れることができます。 第二段階による裁定の可能性。 レポートを楽観的に受け入れたくないユーザーは、プロトコルが確立されるまで待つことを選択できます。 実行は、つまり、第 2 層への潜在的なエスカレーションが発生するまで終了します。これ、 ただし、レポートの確認時間が大幅に遅くなる可能性があります。したがって、簡単に説明します図 15: アラートを備えた staking スキームの回路図。この例では、1⃝過半数 のノードが破損または賄賂を受けており、正しい値ではなく誤った値 ˜r を発行しています レポート値 r。ウォッチドッグ ノード 2⃝ は第 2 層委員会にアラートを送信します。 3⃝正しいレポート値 r を決定して出力するため、ノードが破損します。 デポジットは没収され、各 $d がウォッチドッグ ノード 4⃝ に送られます。 多少なりとも高速化 (シングルラウンド) をもたらすいくつかの最適化の概要を説明します。 セクション 9.5 の複雑な設計。 staking メカニズムの最初の層は、基本的な oracle で構成されていることを思い出してください。 ネットワークそのもの。 上で説明したように、私たちのメカニズムの主な構造は、各ラウンドで、 各ノードは、ある程度の優先順位を持って「ウォッチドッグ」として機能することができるため、次のような機能を備えています。 メカニズムが正しい出力ではなく、誤った出力 ˜r に到達した場合にアラートを生成します。 1r。このアラートにより、第 2 層の解決が引き起こされ、正しい解決策が得られると想定されます。 報告する。不正確なレポートを持つノードは、その賭け金が報われるという意味で罰せられます。 切り取られ、監視員に授与された。この基本構造は oracle システムに共通です。 例: [119, 185]。 上で簡単に述べたように、私たちの設計における重要な革新は、すべてのノードが 潜在的なウォッチドッグの順序付けにおいて明確な優先順位が割り当てられます。つまり番犬 優先順位に従って警告する機会が与えられます。ノードに 警告を発することが最優先であり、あらゆる不正行為に対して減額されたデポジット $d が受け取られます。 合計が \(dn/2 = \)d × n/2 を超えるノード。正しくないレポートは、 不良ノードの大部分。したがって、敵は少なくともこの報酬を支払わなければなりません。 任意のノードに賄賂を渡す。したがって、大多数のノードに賄賂を渡すには、敵は報酬を支払わなければなりません。 大多数のノード、つまり厳密には $dn2/2 以上への多額の賄賂。 図 15 に、アラートとウォッチドッグのエスカレーションがどのように機能するかを概略的に示します。9.4.1 メカニズムの詳細 ここでさらに詳しく説明する贈収賄防止システムは、 私たちが建設しようとしている二層構造。私たちの焦点のほとんどは説明にあります 第 1 層ネットワーク (以下、文脈から明らかでない場合は単に「ネットワーク」とします) インセンティブ メカニズムと第 2 段階へのエスカレーション手順を備えています。 以下を担当する n 個の oracle ノードで構成される Chainlink ネットワークを考えてみましょう。 定期的に (例: 1 分に 1 回) ブール値を報告します (例: 市場が BTC の時価総額は ETH の時価総額を上回ります）。 staking メカニズムの一部として、ノード 2 つのデポジットを提供する必要があります: デポジット $d は、意見の相違があった場合には減額される可能性があります。 過半数と監視機関が$dwを預金し、欠陥があった場合には削減の対象となる エスカレーション。ノードは他のノードの送信をコピーできないと仮定します。 セクション 5.3 で説明した commit-reveal スキームを通じて。各ラウンドでは、まずノードが レポートにコミットし、すべてのノードがコミットしたら (またはタイムアウトが経過したら)、 ノードはレポートを公開します。 生成される各レポートについて、すべてのノードにはランダムに選択された 1 から n までのウォッチドッグ優先順位も与えられます。1 が最優先です。この優先順位により、 報酬が 1 人の監視者の手に集中する。すべてのレポートが公開された後、 警告フェーズが続きます。一連の n (同期) ラウンドにわたって、ノードは 優先度 i にはラウンド i で警告する機会があります。 ノードが明らかになった後、メカニズムで考えられる結果を考えてみましょう。 彼らのレポート。ここでもバイナリ レポートを想定し、正しい値が true であると仮定します。 間違っているものは偽です。また、第 1 層メカニズムが次を出力すると仮定します。 最終レポートとしてノードによって出力される多数決値 r。 このメカニズムでは、次の 3 つの結果が考えられます。 • 完全な一致: 最良の場合、ノードは完全に一致しています: すべてのノード が利用可能であり、同じ値 r (true のいずれか) のタイムリーなレポートを提供しています。 または偽）。この場合、ネットワークは r を信頼するコントラクトに転送するだけで済みます。 そして、各ノードにラウンドごとの固定支払い $p を報酬として与えますが、これははるかに少額です $dよりも。 • 部分一致: 一部のノードがオフラインであるか、どの値が正しいかについて意見が一致していない可能性がありますが、ほとんどのノードは true を報告し、 少数派が虚偽の報告をしている。このケースも単純明快です。過半数の値 (true) が計算され、正しいレポート r が生成されます。 r を報告したすべてのノードは、 誤って報告したoracleがデポジットを持っている間、報酬として$pが与えられます たとえば10ペンスなど、控えめに値下げされました。 • アラート: ウォッチドッグがネットワークの出力が正しくないと判断した場合、 これにより、アラートが公にトリガーされ、メカニズムが第 2 層ネットワークにエスカレートされます。 その場合、考えられる結果は 2 つあります。 – 正しいアラート: 第 2 層ネットワークが、図 16: 集中的な警告報酬による賄賂のコストの増大。賄賂 敵は、警告を発することで得られる報酬以上の報酬を各ノードに賄賂として贈らなければなりません。 (赤いバーで表示)。アラート報酬が共有される場合、この報酬は相対的に高くなります。 小さい。集中アラート報酬により、単一ノードが獲得できる報酬が増加します。 (赤い長いバー) を取得します。したがって、実行可能な賄賂に対する敵対者による支払総額は、 (灰色の領域) は、アラート報酬が共有よりも集中しているため、はるかに大きくなります。 第 1 層ネットワークが間違っていたため、警告を発したウォッチドッグ ノードが報酬を受け取ります すべての削減された預金で構成されるため、$dn/2 を超えます。 – 障害アラート: 第 2 層と第 1 層の oracle が同意した場合、エスカレーションは次のようになります。 故障とみなされ、警告ノードは $dw デポジットを失います。 レポートを楽観的に受け入れた場合、ウォッチドッグ アラートは発生しません。 依存契約の実行における変更。待つことを目的とした契約の場合 第二層委員会による仲裁の可能性、監視機関の警報は遅れるが、 契約の実行を凍結しないでください。契約書で指定することも可能です 判定期間中のフェイルオーバー DON。 9.4.2 二次ステーキングの影響 厳密なノード優先順位と組み合わせて、すべてのノードがウォッチドッグとして機能する機能 集中的な報酬を確保し、二次関数を達成するメカニズムを有効にします staking セクション9.3.3で説明されている各種の賄賂攻撃者への影響。これを思い出してください これは、特に私たちの設定において、それぞれがデポジットを持つ n 個のノードを持つネットワークの場合を意味します。 $d、成功した賄賂 (上記の種類のいずれか) は、 $dn2/2。 正確に言うと、賄賂は少なくとも (n+1)/2 ノードを破壊する必要があります。 n 個のノードの大部分が破損します (奇数 n の場合、仮定により)。したがって、ウォッチドッグは次のことを行います。 $d(n + 1)/2 の報酬を獲得します。したがって、賄賂はこの金額をすべての者に支払わなければなりません。node to ensure that none acts as a watchdog. We are working to show formally that if 賄賂の予算は最大 $d(n2 + n)/2 であり、サブゲームは完全な均衡になります。 賄賂者とoraclesの間のゲーム、言い換えれば、均衡 ゲームのプレイ中のどの時点でも、賄賂を受け取る側は賄賂を発行しません。 それぞれの oracle は、その真の値を正直に報告します。 上で、賄賂を成功させるためにどのようにして贈賄が要求される可能性があるかを説明しました。 ノードのデポジットの合計よりも大幅に大きい予算。これを説明すると 直感的な結果として、図 16 は集中アラート報酬の影響をグラフで示しています。 そこに見られるように、監視機関の警告に対する報酬、つまり賄賂の預金があった場合、 false を報告するノード) - すべての潜在的なアラートに分割され、合計量は 個々のアラート ノードは比較的小さいと予想されます。 $d。 賄賂は、d ドルを超える支払いがありそうもないことを知っていて、次のような手段を講じることができます。 n ノードのそれぞれに、 $d + ϵ。 直観に反しますが、図 16 は、報酬を広範囲に分配するシステムを示しています。 アラートを通知するノード間では、報酬を集中させるノードよりもはるかに弱いです。 the hands of a single watchdog. パラメータの例: 各ノードが n = 100 個ある (第 1 層) ネットワークを考えてみましょう。 depositing \(d = \)20K.このネットワークには合計 200 万ドルが入金されることになりますが、 予算\(100M = \)dn2/2の賄賂から保護されます。数を増やす もちろん、oracles は $d を増やすより効果的であり、劇的な効果が得られる可能性があります。 n = 300 ノードと \(d = \)20K のデポジットを持つネットワークは、 briber with budget up to $900M. staking システムは多くの場合、次の smart contract を保護できることに注意してください。 提供されている贈収賄防止レベルよりも価値のあるもの。 This is because an adversary これらの契約を攻撃しても、多くの場合、最大限の価値を引き出すことはできません。たとえば、 Chainlink を利用した契約で 10 億ドルの価値を確保するには、 そのような敵は利益を引き出すことができるため、1億ドルの資金を賄賂に渡す of only 10% of the value of the contract. 注: ネットワークの価値は二次関数的に増加する可能性があるという考えは、次のように表現されます。 よく知られているメトカーフの法則 [167, 235] では、ネットワークの価値は次のように述べられています。 接続されたエンティティの数は二次関数的に増加します。 Metcalfe’s Law, however, これは、潜在的なペアワイズ ネットワーク接続の数の増加から生じます。これは、インセンティブにおける 2 次 staking の基礎となる影響とは異なる現象です。 仕組み。 9.4.3 Realization of Second Tier 2 つの運用上の特徴により、高信頼性の 2 層目の実現が容易になります。 (1) oracle ネットワークでは第 2 層の裁定はまれなイベントであるはずなので、 第 1 層の通常の運用よりも大幅にコストがかかること、および (2)楽観的に受け入れられた報告書、または仲裁を待って実行できる契約書など 2 番目の層はリアルタイムで実行する必要はありません。 これらの機能により、さまざまな結果が得られます。 特定の DON の要件を満たすための 2 番目の層の構成オプション。 アプローチの例として、第 2 層委員会は、委員会によって選択されたノードで構成できます。 Chainlink 内で最も長くサービスを提供し、最も信頼性の高いノードからの DON (つまり、第 1 層) ネットワーク。オペレータは、相当な運用経験に加えて、 このようなノードの多くは、FFO に、欲望を動機付ける暗黙のインセンティブをかなり持っています。 Chainlink ネットワークの信頼性を高く保つため。彼らはまた、公に 信頼性の透明性を提供する利用可能なパフォーマンス履歴。注目に値するのは、第 2 層ノードは第 1 層ネットワークの参加者である必要はなく、 複数の第 1 層ネットワークにわたる障害を判断する場合があります。 特定の DON 内のノードは、そのような n ' 個のセットを事前に指定し、公にコミットできます。 DON の第 2 層委員会を構成するノード。さらに、DON ノードは、第 2 層の投票数を決定するパラメーター k' ≤n' を公開します。 第 1 層ノードにペナルティを与えるために必要です。特定のレポートに対してアラートが生成されると、 第 2 層のメンバーは、それぞれが提供する値の正しさに投票します。 第 1 層ノードの。 k' 個の否定票を受け取った第 1 層ノードはその権利を失います。 ウォッチドッグノードにデポジットします。 判決が下されることは稀であり、執行時間が延長される可能性があるため 前述したように、第 1 層とは対照的に、第 2 層のノードは次のことができます。 1. 裁判を行うことで高額の報酬を得る。 2. 最初の企業が使用する多様なセットを超えた追加のデータ ソースを利用します。 3. 手動および/または専門家の検査と介入に頼って、たとえば、特定および ソースデータのエラーを調整し、中継している誠実なノードを区別します。 欠陥のあるデータと誤動作するノード。 二次ノードの選択と判定を管理するポリシーについて説明したアプローチは、大きな枠組みの中の 1 点にすぎないことを強調します。 第 2 層の実現可能な設計空間。当社のインセンティブメカニズムが提供するもの 第 2 層の実現方法に関する完全な柔軟性。したがって、個々のDONは 特定の要件を満たす第 2 層のルールを構成および設定する 参加ノードとユーザーの期待。 判定ツールとしての DECO と Town Crier: ２層目では必須ですね 私たちのメカニズムでは、敵対的な第 1 層ノードを区別できるようになります。 意図的に誤ったレポートと、意図せずに正直な第 1 層ノードを作成する 送信元で不正なデータを中継します。そうして初めて第 2 層が実装できるようになります 私たちのメカニズムの目標である不正行為を阻止するためにスラッシュを行うことです。 DECOとタウンクライヤー は、第 2 層ノードがこの重要な区別を行えるようにする強力なツールです。 確実に。場合によっては、第 2 層ノードは使用されるデータ ソースを直接クエリできる場合があります。 第 1 層ノードによって実行するか、ADO セクション 7.1 を使用して、レポートが正しくないかどうかを確認します。 データ ソースの欠陥が原因です。ただし、他の場合には、第 2 層ノードに不足している可能性があります。 第 1 層ノードのデータ ソースへの直接アクセス。このような場合、正しい判決が下されると、 実行不可能であるか、主観的な判断に頼る必要があるように見えます。前 oracle 紛争システムは、このような問題に対処するために、非効率でエスカレートする投票ラウンドに依存してきました。 課題。 ただし、DECO または Town Crier を使用すると、第 1 層ノードが正しい動作を証明できます。 第 2 層ノードに。 (2 つのシステムの詳細については、セクション 3.6.2 を参照してください。)具体的には、 第 2 層ノードは、第 1 層ノードが欠陥のあるレポート値 ˜r を出力したと識別し、 第 1 層ノードは DECO または Town Crier を使用して改ざん防止の証拠を生成できます。 第 2 層ノードは、(TLS 対応の) ソースから正しく中継されているかどうかを確認します。 DON によって権威あるものとして認識されています。重要なのは、第 1 層ノードがこれを実行できることです。 データ ソースへの直接アクセスを必要とする第 2 層ノードは必要ありません。17 その結果、 Chainlink では、任意のデータ ソースに対して正しい判断が可能です。 9.4.4 保険の虚偽報告 当社のstakingメカニズムによって達成される強力な贈収賄防止は、根本的に依存しています 警告者に与えられる資金の削減について。金銭的な報酬がなければ、警告者は 賄賂を拒否する直接的な動機はありません。しかし、その結果、削減された資金は 誤った報告によって被害を受けたユーザー（金銭を失ったユーザーなど）を補償するために利用可能 誤った価格データが smart contract に中継された場合。 仮定として、レポートが承認された場合、間違ったレポートは問題を引き起こしません。 潜在的な裁定、つまり第 2 層による措置の後にのみ契約を締結します。説明どおり ただし、可能な限り最高のパフォーマンスを達成するために、契約では代わりに上記に依存する場合があります。 正しい報告を強制するメカニズムについて楽観的に考えており、これは受け入れられることを意味します。 潜在的な第二段階の裁定の前に報告する。 確かに、そのような楽観的な行動は、 予算が上限を超えない合理的な敵を想定したモデルでは安全です。 staking メカニズムの影響。 ユーザーは、機構の故障というありえない事態を懸念しており、 たとえば、圧倒的な資金力を持つ敵対者は、保険の虚偽報告という形で経済的安全の追加層を採用したいと考えるかもしれません。私たちは知っています 複数の保険会社がすでにこの種のスマートコントラクトに裏付けられた保険を提供するつもりです Chainlink で保護されたプロトコルは、DAO (例: [7]) などの革新的なメカニズムを通じて、近い将来実現されます。 Chainlink のパフォーマンス履歴の存在 ノードおよびそのステーク額などのノードに関するその他のデータは、保険数理によるリスク評価の非常に強力な基礎を提供し、保険契約の価格設定を可能にします。 保険契約者にとっては安価でありながら、保険会社にとっては持続可能な方法で。 17Town Crier を使用すると、第 1 層ノードがローカルで証明書を生成することも可能になります 出力されたレポートの正確性を検証し、これらの証明書を第 2 層ノードに提供します。 必要に応じてベース。誤報保険の基本的な形式は、信頼できる方法で実装できます。 smart contracts を使用した効率的な方法。簡単な例として、パラメトリック保険 当社のインセンティブメカニズムが有効であれば、契約SCinsは保険契約者に自動的に補償することができます。 2 番目の層は、1 番目の層で生成されたレポートのエラーを特定します。 保険契約を希望するユーザ U、例えばターゲットの作成者 契約 SC は、分散型保険会社に保険金額のリクエストを送信できます 契約は百万ドル。 U を承認すると、保険会社は継続的な (例: 毎月) を設定できます。 SCins で $P のプレミアム。 U が保険料を支払っている間、彼女の保険は有効のままです。 SC でレポートの失敗が発生した場合、結果としてペア (r1、r2) が出力されます。 SC の競合するレポート。ここで、r1 はメカニズムの最初の層によって署名されており、 r2 (対応する修正レポート) は、第 2 層によって署名されます。 U が提供する場合 このような有効なペア (r1、r2) を SCins に指定すると、契約により自動的に $M が彼女に支払われます。 彼女の保険料の支払いは最新のものです。 9.5 シングルラウンドのバリエーション 前のサブセクションで説明したプロトコルでは、第 2 層委員会は、ウォッチドッグが警告を発したかどうかを判断するために n ラウンド待機する必要があります。 これ この要件は、楽観的なケース、つまり最初の層が機能している場合でも当てはまります。 正しく。レポートを楽観的に受け入れたくないユーザー、つまり潜在的な可能性が生じる前に 判決が下されると、そのアプローチに伴う遅延は実行不可能になります。 このため、私たちは 1 つだけを必要とする代替プロトコルも検討しています。 丸い。このアプローチでは、すべての oracle ノードが、次のいずれかを示す秘密ビットを送信します。 彼らは警告を発したいと考えています。次に、第 2 層委員会がこれらの値をチェックします。 優先順位。大まかなスケッチを提供するには、このようなスキームには次のものが含まれる可能性があります。 手順: 1. ウォッチドッグ ビットの送信: 各ノードは 1 ビットのウォッチドッグ値を秘密共有します。 生成されるレポートごとに、第 2 層のノード間で wi ∈{アラートなし、アラート} が発生します。 2. 匿名ヒント: 任意の oracle ノードは、ウォッチドッグ ビットが送信されるのと同じラウンドで、匿名のヒント α を第 2 層委員会に送信できます。このヒントα 現在のレポートに対してアラートが発生したことを示すメッセージです。 3. ウォッチドッグ ビット チェック: 第 2 層委員会は oracle ノードのウォッチドッグを明らかにします ビットを優先順位順に並べます。 ノードは、アラートを出さないときはアラート ウォッチドッグ ビットを送信してはならないことに注意してください。そうしないと、トラフィック分析によってすべてのノードのビットが明らかになります。プロトコルはアラートなしを明らかにします 最も優先順位の高いアラート ウォッチドッグよりも高い優先順位を持つノードのウォッチドッグ ビット。 明らかになったものは、n ラウンド プロトコルのものと同じであることに注目してください。報酬もそのスキーム、つまり最初に特定されたウォッチドッグと同様に分配されます。 は、誤ったレポートを提出したノードの削減されたデポジットを受け取ります。匿名のヒントを使用すると、警告が発せられていない場合でも第 2 層委員会は非対話型のままとなり、コミュニケーションの複雑さが軽減されます。 一般的なケースでは。警告を発する監視機関には、匿名のヒントを提出する経済的インセンティブがあることに注意してください。ヒントが提出されない場合、報酬は支払われません。 ノード。 匿名の情報αの送信者Oiが特定できないようにするため。 ネットワーク データに基づいて敵対者に匿名の情報を送信することができます。 たとえば、Tor 経由、またはより現実的には、クラウド サービス プロバイダー経由でプロキシされたチャネルです。へ チップが O から発信されたものであると認証すると、Oi はリング署名を使用して α に署名できます [39、192]。 あるいは、悪意のある oracle ノードによる第 2 層委員会に対する原因不明のサービス拒否攻撃を防ぐために、α を匿名の資格情報にすることもできます。 取り消し可能な匿名性 [73]。 このプロトコルは、実際には実現可能ですが、やや重いエンジニアリングを必要とします。 要件（これを削減する方法を検討中です）。たとえば、第 1 層ノードは次のようになります。 第 2 層ノードと直接通信する必要があるため、ディレクトリのメンテナンスが必要になります。匿名チャネルとリング署名の必要性によりエンジニアリングが増加します スキームの複雑さ。最後に、特別な信頼要件について簡単に説明します。 以下のメモにあります。したがって、私たちは、依然として達成できるより単純なスキームも模索しています。 超線形 staking の影響はありますが、おそらく 2 次よりは小さいでしょう。たとえば、賄賂が漸近的に少なくとも $n log n のリソースを必要とする場合です。以下のスキームの一部 考慮事項には、ウォッチドッグとして機能するノードの厳密なサブセットのランダムな選択が含まれます。 この場合、将来的な贈収賄は特に強力な攻撃となります。 備考: この単一ラウンド staking メカニズムのセキュリティには、利用できないことが必要です oracle と第 2 層ノード間のチャネル - 投票 [82、138] などの耐強制性システムの標準要件であり、実際には合理的な要件です。 ただし、さらに、賄賂と協力しようとするノード Oi は、 特定の暗号化を行ったことを賄賂に示すような方法で秘密共有を行う 値。たとえば、Oi が賄賂がどのノードを制御しているかわからない場合、Oi は次のことができます。 価値ゼロの株式をすべての委員会メンバーに提出します。贈収賄者はその後、Oi の内容を確認できます。 確率的にコンプライアンスを達成します。シングルラウンドプロトコルでこの問題を回避するには、次のようにします。 Oi は、少なくとも 1 つの正直な第 2 層ノードの ID を知っている必要があります。 各第 2 層ノードがランダム化を追加する対話型プロトコルを使用 株式の要因となるため、贈収賄者ができる最善のことは、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 ノードを選択する際の重要な要素を提供します (または、出現により DON の、DON の選択）。好調なパフォーマンス履歴は、 継続的な高い収益と相関関係があります。18 18私たちが取り組む予定の重要な研究課題は、改ざんされたサービス量の検出です。図 17: 単一データ フィード (ETH-USD) で Chainlink ノードが獲得した収益 2021年3月の代表的な週。 • データ アクセス: oracles はオープン API からさまざまな形式のデータを取得できますが、 特定の形式のデータまたは特定の高品質のソースは、 サブスクリプションベースまたは契約上の合意を通じて。特定のものへの特権アクセス データ ソースは、安定した収益源を生み出す役割を果たすことができます。 • DON への参加: DONs の出現により、ノードのコミュニティが登場します。 特定のサービスを提供するために連携します。多くの DON には次のものが含まれると予想されます。 選択ベースでオペレーターを選択し、評判の高い DON への参加を確立します。 市場での特権的な地位を確保し、安定した収益源を確保します。 • クロスプラットフォームのアクティビティ: 一部のノードオペレーターは、他のコンテキスト (PoS validator や blockchain 以外のコンテキストのデータ プロバイダー。これらの他のシステムでのパフォーマンス (データが信頼できる形式で利用可能な場合) が評価に影響を与える可能性があります。 彼らの演奏履歴。同様に、Chainlink ネットワークでの誤った動作 ユーザーを遠ざけることにより、これらの他のシステムの収益を危険にさらす可能性があります (FFO など) プラットフォーム間で拡張できます。 9.6.2 投機的FFO ノード オペレーターは、収益を生み出すためだけではなく、Chainlink ネットワークに参加します。 業務を遂行するだけでなく、ジョブを実行するための新しい機会を活用するために自らを立ち上げ、配置することも必要です。つまり、ネットワーク内の oracle ノードによる支出も DeFi およびその他のスマート コントラクト アプリケーションの将来についての前向きな声明 ドメインだけでなく、oracle ネットワークの新興の非blockchain アプリケーションも同様です。現在、ノード オペレーターは既存の Chainlink ネットワークで利用可能な料金を得ると同時に、 これらは、問題がより簡単であることを除けば、インターネット サイト上の偽レビューとほぼ似ています。 oracle 設定は、商品 (レポートなど) が注文されたかどうかの決定的な記録があるためです。 たとえば、オンライン ショップで注文した物理的な商品とは対照的に、配送されます。別の言い方をすると、oracle 設定を変更すれば、顧客の真実性が証明できない場合でも、パフォーマンスを検証できます。評判、実績履歴、運用上の専門知識を構築し、 将来のネットワークで利用できる手数料を有利に稼ぐことができます（もちろん、条件付きですが）。 正直な行動について）。現在 Chainlink エコシステムで動作しているノードは、 Chainlink として追加料金を稼ぐ点で、新規参入者よりも有利な感覚を持っています。 サービスが利用可能になります。この利点は、新しい通信事業者だけでなく、定評のあるテクノロジー企業にも当てはまります。たとえば、T-Systems は従来の テクノロジープロバイダー (ドイツテレコムの子会社)、および大規模な集中型サービスである Kraken Exchange は、Chainlink エコシステムで初期の存在感を確立しました [28、143]。 oracle ノードによる将来の機会へのそのような参加は、それ自体とみなされます 一種の投機的な FFO として、Chainlink における一種の株式を構成します。 ネットワーク。 9.6.3 外部からの評判 IIF は、これまで説明したように、厳密に匿名化されたネットワーク内で動作できます。 つまり、関係する人々や現実世界のエンティティは開示されません。 ただし、ユーザーがプロバイダーを選択する際に潜在的に重要な要素の 1 つは外部要因です。 評判。外部の評判とは、偽名ではなく現実世界のアイデンティティに付随する信頼性の認識を意味します。風評リスクが伴う 現実世界のアイデンティティは、暗黙のインセンティブの一形態とみなすことができます。評判を見る IIFのレンズを通して、つまり暗号経済的な意味で、 FFO の推定値に組み込まれる可能性のあるクロスプラットフォームのアクティビティ。 FFO の推定の要素として外部の評判を使用することの利点とは対照的に 仮名リンクとは、外部の評判がパフォーマンスにリンクするだけでなく、 オペレーターの既存の活動だけでなく、将来の活動にも適用されます。例えば評判が悪い場合 個人に執着すると、その人の将来の事業を汚す可能性があります。別の言い方をすると、外部の評判は匿名よりも広範囲の FFO を捉えることができます。 個人または確立された不正行為の影響としての業績記録 会社から逃れるのは、偽名運営に関連する会社よりも困難です。 Chainlink は、分散型 ID テクノロジー (セクション 4.3) と互換性があります。 IIF での外部レピュテーションの使用のサポートを提供できます。このような技術 検証することができ、それによってオペレータが主張する現実世界の真実性を保証するのに役立ちます アイデンティティ.19 9.6.4 IIF アナリティクスを開く すでに述べたように、IIF は信頼できるオープンソース データとツールを提供することを目的としています。 暗黙的なインセンティブ分析。 目標は、コミュニティ内でプロバイダーを有効にすることです 組織のさまざまな部分のリスク評価ニーズに合わせた分析を開発するため Chainlink ユーザー ベース。 19分散型アイデンティティ認証情報では、必要に応じて、検証済みの仮名を装飾することもできます。 補足情報。たとえば、ノード オペレータは原則としてそのような認証情報を使用して、 フォーチュン 500 企業であることを証明しますが、どの企業であるかは明らかにしません。ノードの収益とパフォーマンスに関する大量の履歴データ 信頼性の高い不変形式でチェーン上に存在します。ただし、私たちの目標は、 オフラインでのみ表示される行動に関するデータを含む、可能な限り最も包括的なデータ チェーン (オフチェーン レポート (OCR) や DON アクティビティなど)。このようなデータは、潜在的に ボリュームがあること。それを保管し、その完全性を確保するための最良の方法、つまり、次のようなことから保護します。 改ざんは、DON の助けを借りて、ここで説明した手法を使用して行われると考えられます。 セクション 3.3 で説明します。 staking など、一部のインセンティブは直接的な測定形式に適しています。 デポジットと基本的な FFO。投機的な FFO や評判など、他のものはより困難です。 客観的な方法で測定しますが、次のような形式のデータをサポートすることが重要であると考えています。 Chainlink エコシステムの歴史的成長、ソーシャルメディアの評判指標など、 は、これらの定量化が難しい要素についても IIF 分析モデルをサポートできます。 専用の DON は、特に監視、検証、および監視のために発生すると想像できます。 ノードのオフチェーンパフォーマンス記録に関連する記録データおよびその他のデータ IIF で使用される、検証された ID 情報など。これらの 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 が増加します。おかげで 私たちのインセンティブ システム設計の超線形な影響、経済的安全性 システムは n よりも速く立ち上がります (たとえば、セクション 9.4 で説明するメカニズムでは n2 のように)。 その結果、経済的安全保障の平均コスト、つまり貢献する出資額は 経済安全保障の 1 ドルは減少するでしょう。したがって、ネットワークはユーザーに料金を請求することができます 手数料が安くなる。 oracle サービスの需要は柔軟であると仮定します (たとえば、概要については [31] を参照してください) 説明）、需要が増加し、追加料金と FFO が発生します。 この点を次の例で説明します。 例 5. インセンティブによる oracle ネットワークの経済的安全性 スキームは \(dn2 for stake \)dn、1 ドルの賭け金によって経済的安全が提供されます は n なので、経済安全保障の 1 ドルあたりの平均コスト、つまり賭け金の額となります。 1 ドルの経済安全保障への貢献は 1/n です。 経済的インセンティブが完全に FFO で構成され、上限が設定されているネットワークを考えてみましょう。 ノードあたり\(d ≤\)10K。ネットワークに n = 3 個のノードがあると仮定します。そうすると平均費用は 経済安全保障は 1 ドルあたり約 0.33 ドルです。 ネットワークの合計 FFO が \(30K (e.g., to \)31K を超えると仮定します。与えられた ノードごとの FFO の上限を設定すると、ネットワークは (少なくとも) n = 4 まで拡大します。ここで、平均コストは次のようになります。 経済安全保障は 1 ドルあたり約 0.25 ドルに低下します。 oracle ネットワークにおける経済安全保障の完全な好循環を図 18 に概略的に示します。 我々は、経済安全保障の好循環は次のような効果から生まれることを強調する。 料金をプールするユーザーの割合。 より大きな組織に有利に働くのは、彼らの集合的な FFO です。 ネットワークの規模が大きくなり、集団的なセキュリティが強化されます。また、好循環にも注目します。 経済的安全の確保は、DON が経済的な持続可能性を達成するのに有利に働きます。一度 ユーザーのニーズに対応する DON が作成され、その時点以上に成長する必要があります。 手数料による収益が oracle ノードの運用コストを超えています。

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

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

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

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

図 18: Chainlink staking の好循環の概略図。利用料の値上げ oracle ネットワーク 1⃝への支払いはネットワークを成長させ、経済成長につながります セキュリティ 2⃝。この超直線的な成長により、Chainlink ネットワークのスケールメリットが実現します 3⃝。具体的には、経済安全保障の平均コストの削減を意味します。 手数料の支払いまたはその他の出資源から生じる1ドルあたりの経済的安全性 が増加します。コストの削減がユーザーに還元され、oracle の需要が増加します サービス4⃝。 9.9 ネットワークの成長を促進する追加の要因 Chainlink エコシステムが拡大し続けるにつれて、その魅力はさらに高まると考えています。 ユーザーにとっての重要性が高まり、blockchain 経済のインフラとしての重要性が加速します。 oracle ネットワークによって提供される値は超線形であり、より速く成長することを意味しますネットワーク自体のサイズよりも。 この価値の増加は、次の両方に由来します。 スケールメリット - サービス量の増加に伴うユーザーあたりのコスト効率の向上 - そして ネットワーク効果 - ユーザーが DON をより広く採用するにつれて、ネットワーク ユーティリティが増加します。 既存の smart contract には引き続き、より多くの価値が確保され、まったく新しいものとなります。 smart contract アプリケーションは、より分散化されたサービスによって可能になり、合計 DON の使用および支払われる料金の総額は増加するはずです。 手数料プールの増加 さらに分散化されたサービスを作成するための手段とインセンティブに変換されます。 好循環が生まれます。 この好循環により、卵が先か鶏が先かという重大な問題が解決されます。 ハイブリッド smart contract エコシステムの問題: 革新的な smart contract 機能 多くの場合、まだ存在しない分散型サービスが必要になります (例: 新しい DeFi 市場が頻繁に存在します) 新しいデータフィードが必要ですが、その実現には十分な経済的需要が必要です。 既存の DON に対するさまざまな smart contract による料金のプールは、 拡大するユーザーベースからの追加の分散型サービスが誕生し、 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 العقد.

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

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

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

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

الشكل 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 contract 秒。 DON を将来の分散型サービスの基盤として使用し、Chainlink は、パフォーマンスが高く機密性が強化された oracle 機能を提供することを目指します。その oracle ネットワークは強力な信頼の最小化を提供します staking や 慎重に考えられたガードレールと、依存するメインチェーンに対するサービスレベルの強制。 DONs は、レイヤー 2 システムがトランザクションに対して柔軟で公平な順序付けポリシーを適用し、メモリプール経由のトランザクションのガスコストを削減するのにも役立ちます。まとめると、 これらの機能はすべて、安全で機能豊富なハイブリッド スマートの方向に推進します。 契約。 DONs の柔軟性により、既存の 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 من خلال الاتصال العالمي والتأسيس التكنولوجيات اللامركزية باعتبارها العمود الفقري للجيل القادم من الخدمات المالية في العالم والأنظمة القانونية. شكر وتقدير شكرًا لجوليان ألتريني وشون لي على تقديم الأرقام الواردة في هذه الورقة.