체인링크: 분산형 오라클 네트워크
概要
このホワイトペーパーでは、元の 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 네트워크의 역할이 점차 확대되고 있으며, 빠르고 안정적이며 기밀성을 유지하는 범용 연결 및 오프체인 계산 smart contracts. 우리 계획의 기초는 분산형 Oracle 네트워크라고 부르는 것입니다. 줄여서 DONs입니다. DON은 Chainlink 위원회에서 유지 관리하는 네트워크입니다. 노드. 선택한 oracle 기능을 무제한으로 지원합니다. 위원회에 의한 배치. 따라서 DON은 강력한 추상화 계층 역할을 합니다. 광범위한 오프체인 리소스에 대한 smart contracts에 대한 인터페이스를 제공하고 DON 자체 내 효율적이면서도 분산된 오프체인 컴퓨팅 리소스입니다. DONs를 발판으로 Chainlink은 7개 분야의 발전에 집중할 계획입니다. 주요 분야: • 하이브리드 smart contracts: 온체인을 안전하게 구성하여 기존 smart contract 기능을 강화하기 위한 강력하고 일반적인 프레임워크 제공 그리고 오프체인 컴퓨팅 리소스를 우리가 하이브리드 smart contract라고 부르는 것으로 만들었습니다. • 복잡성 추상화: 개발자와 사용자에게 간단한 설명을 제공합니다. 기능을 사용하면 복잡한 기본 기능에 익숙할 필요가 없습니다. 프로토콜 및 시스템 경계. • 확장: oracle 서비스가 지연 시간 및 처리량을 달성하도록 보장 고성능 분산 시스템이 요구하는 것입니다. • 기밀성: blockchains'를 결합한 차세대 시스템 구현 민감한 정보에 대한 강력한 새 기밀 보호 기능을 갖춘 타고난 투명성 데이터. • 거래에 대한 주문 공정성: 다양한 방식으로 거래 순서 지원 최종 사용자에게 공정하고 선행 공격 및 기타 공격을 방지합니다. 봇과 착취적인 광부. • 신뢰 최소화: 매우 신뢰할 수 있는 지원 계층 생성 smart contracts 및 기타 oracle 종속 시스템은 분산화, 높은 보안 수준의 강력한 고정 blockchains, 암호화를 통해 기술 및 암호화폐 경제 보장. • 인센티브 기반(암호경제적) 보안: DONs의 노드가 자원이 풍부한 적들 앞에서도 안정적이고 올바르게 행동할 수 있는 강력한 경제적 인센티브를 갖도록 하는 메커니즘을 엄격하게 설계하고 강력하게 배포합니다. 우리는 Chainlink 커뮤니티의 예비적이고 지속적인 혁신을 제시합니다. 각 영역에서 확장되고 점점 더 커지는 그림을 제공합니다. Chainlink 네트워크에 강력한 기능이 계획되어 있습니다.
導入
ブロックチェーン 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 で紹介します。
図 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 ノードでの機密性を強化することも可能です。 それ自体が可視性を持たないデータを計算します。
• 機密のレイヤー 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 ノード間でレポート生成を分散化することで、一部のノードが破損した場合でもセキュリティを確保できます。
図 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 の選択。
소개
블록체인 oracle은 오늘날 한 가지 목표를 가진 분산형 서비스로 간주되는 경우가 많습니다. 오프체인 리소스의 데이터를 blockchains로 전달합니다. 짧은 걸음이지만, 데이터 전달부터 컴퓨팅, 저장, 양방향 전송까지. 이러한 관찰은 oracles의 기능에 대한 훨씬 더 광범위한 개념을 정당화합니다. 너무도 smart contracts의 증가하는 서비스 요구 사항을 수행하고 점점 더 다각화됩니다. oracle 네트워크에 의존하는 기술. 간단히 말해서, oracle는 다음을 수행할 수 있고 필요합니다. 온체인 시스템과 오프체인 시스템 간의 범용, 양방향, 컴퓨팅 지원 인터페이스입니다. blockchain 생태계에서 오라클의 역할은 smart contract의 성능, 기능 및 상호 운용성을 다양한 산업에 새로운 신뢰 모델과 투명성을 제공합니다. 이러한 변화는 하이브리드 smart contract의 사용 확대를 통해 이루어질 것입니다. blockchains의 특별한 속성은 다음과 같은 오프체인 시스템의 고유한 기능을 갖추고 있습니다. oracle 네트워크를 구축하여 온체인 시스템보다 훨씬 더 큰 도달 범위와 성능을 달성합니다. 고립되어 있습니다. 이 백서에서 우리는 원래 Chainlink 백서 [98]의 초기 개념을 뛰어넘는 Chainlink의 진화인 Chainlink 2.0에 대한 비전을 명확히 설명합니다. 우리는 oracle 네트워크의 역할이 점점 더 확장될 것으로 예상합니다. 하이브리드를 위한 빠르고 안정적이며 기밀성을 유지하는 범용 연결 및 계산을 제공하여 기존 및 새로운 blockchain을 보완하고 향상합니다. smart contracts. 우리는 oracle 네트워크가 유틸리티로 발전할 것이라고 믿습니다. 높은 무결성의 blockchain급 데이터를 blockchain 이상의 시스템으로 내보내는 데 사용됩니다. 생태계. 오늘날 다양한 개체 집합이 운영하는 Chainlink 노드는 oracle 네트워크에 모여 보고서라고 알려진 데이터를 smart contract에 전달합니다. 우리는 그러한 것을 볼 수 있습니다 oracle 노드는 고전적 합의 blockchain [72]과 유사한 위원회로서, 그러나 독립된 기능을 제공하기보다는 기존 blockchain을 지원하는 것이 목표입니다. 검증 가능한 무작위 함수(VRF) 및 오프체인 보고 (OCR), Chainlink은(는) smart contract에 필요한 계산 리소스를 제공하기 위한 범용 프레임워크 및 인프라로 이미 발전하고 있습니다. 고급 기능. Chainlink 2.0에 대한 우리 계획의 기초는 우리가 분산형 Oracle이라고 부르는 것입니다. 네트워크, 줄여서 DON입니다. "oracle 네트워크"라는 용어를 도입한 이후 원본 Chainlink 백서 [98], oracles는 더욱 풍부한 기능과 적용 범위가 넓습니다. 본 논문에서는 다음과 같은 용어에 대한 새로운 정의를 제공합니다. Chainlink 생태계에 대한 미래 비전을 소개합니다. 이 보기에서 DON은 네트워크입니다. Chainlink 노드로 구성된 위원회에서 유지관리합니다. 합의 프로토콜에 뿌리를 두고 있으며, 배포를 위해 선택한 oracle 기능을 무제한으로 지원합니다. 위원회. 따라서 DON는 blockchain 추상화 계층 역할을 하여 인터페이스를 제공합니다. smart contracts 및 기타 시스템 모두에 대한 오프체인 리소스에 연결됩니다. 그것은 또한 제공합니다 매우 효율적이면서도 분산화된 오프체인 컴퓨팅 리소스에 액세스할 수 있습니다. 일반적으로, DON은 메인 체인에서의 작업을 지원합니다. 그 목표는 안전하고 유연한 서비스를 제공하는 것입니다.온체인 및 오프체인 계산을 결합한 하이브리드 smart contracts 외부 리소스에 대한 연결. 우리는 DONs에서 위원회를 사용하더라도 Chainlink 자체가 본질적으로 허가가 없는 상태로 유지됩니다. DONs는 무허가형의 기초 역할을 합니다. 노드가 함께 모여 사용자 정의 oracle 네트워크를 구현할 수 있는 프레임워크 허가되거나 허가되지 않을 수 있는 노드 포함에 대한 자체 체제. DONs를 기반으로 Chainlink 2.0에서는 7개 분야의 발전에 집중할 계획입니다. 핵심 영역: 하이브리드 smart contracts, 복잡성 추상화, 확장성, 기밀성, 거래 주문 공정성, 신뢰 최소화 및 인센티브 기반(암호경제적) 보안. 이 백서 소개에서는 분산화의 개요를 제시합니다. 섹션 1.1의 Oracle Networks와 섹션 1.2의 7가지 주요 혁신 영역. 섹션 1.3에서 이 문서의 나머지 부분의 구성을 설명합니다. 1.1 분산형 오라클 네트워크 분산형 Oracle 네트워크는 기능을 향상하고 확장하도록 설계되었습니다. 대상 blockchain 또는 다음 기능을 통한 메인 체인의 smart contract 기본적으로 사용할 수 없습니다. 그들은 다음의 세 가지 기본 리소스를 제공하여 이를 수행합니다. 컴퓨팅 시스템: 네트워킹, 저장 및 계산. DON은(는) 다음을 제공하는 것을 목표로 합니다. 강력한 기밀성, 무결성 및 가용성 속성을 지닌 이러한 리소스는1 책임감도 그렇고. DONs는 특정 목적을 달성하기 위해 협력하는 oracle 노드 위원회로 구성됩니다. 직업을 갖거나 지속적인 서비스를 제공하기 위해 장기적인 관계 구축을 선택합니다. 클라이언트에게. DON은 blockchain에 구애받지 않는 방식으로 설계되었습니다. 그들은 다음과 같은 역할을 할 것을 약속합니다. 애플리케이션 개발자가 오프체인 지원을 생성할 수 있는 강력하고 유연한 도구입니다. 지원되는 메인 체인의 smart contracts. DON의 기능을 실현하는 두 가지 유형의 기능: 실행 파일 및 어댑터. 실행 파일은 DON에서 분산 방식으로 지속적으로 실행되는 프로그램입니다. 메인체인 자산을 직접 저장하지는 않지만 고성능 및 기밀 수행 능력을 포함한 중요한 이점이 있습니다. 계산. 실행 파일은 DON에서 자율적으로 실행되며 결정론적 수행을 수행합니다. 운영. DON을 외부 리소스에 연결하는 어댑터와 함께 작동합니다. 실행 파일에 의해 호출될 수 있습니다. DONs에 대해 우리가 구상한 어댑터는 오늘 Chainlink의 외부 어댑터 일반화. 기존 어댑터 중 일반적으로 데이터 소스에서만 데이터를 가져오며 어댑터는 양방향으로 작동할 수 있습니다. 안으로 DONs, 그들은 추가로 DON 노드의 공동 계산을 활용하여 다음을 달성할 수 있습니다. 개인 정보 보호 소비를 위한 보고서 암호화와 같은 추가 기능 실행 파일. DON의 기본 작동에 대한 이해를 제공하기 위해 그림 1은 개념적으로 DON은(는) blockchain에 보고서를 보내는 데 사용되어 기존의 oracle 기능을 달성할 수 있습니다. DONs는 그 이상의 많은 추가 기능을 제공할 수 있습니다. 1정보 보안의 "CIA 3대 요소" [123, p. 26, §2.3.5].Chainlink의 기존 네트워크. 예를 들어, 그림 1의 일반적인 구조 내에서, 실행 파일은 가져온 자산 가격 데이터를 DON에 기록할 수 있습니다. 예를 들어 보고서의 후행 평균을 계산합니다. 그림 1: 분산형 Oracle 네트워크가 기본 oracle 기능(예: 오프체인 데이터를 계약서에 전달)을 실현하는 방법을 예로 보여주는 개념적 그림. 안 실행 파일은 어댑터를 사용하여 오프체인 데이터를 가져와서 계산하고 출력을 보냅니다. 다른 어댑터를 통해 대상 blockchain에 연결합니다. (어댑터는 DON, 작은 파란색 상자로 표시됩니다. 화살표는 이에 대한 데이터 흐름 방향을 나타냅니다. 특정 예.) 실행 파일은 추가로 로컬 DON을 읽고 쓸 수 있습니다. 상태를 유지하고/하거나 다른 실행 파일과 통신하기 위한 저장소입니다. 여기에 제시된 DONs의 유연한 네트워킹, 계산 및 저장 기능을 통해 다양한 새로운 기능을 사용할 수 있습니다. 응용 프로그램. DONs의 주요 이점은 새로운 blockchain 서비스를 부트스트랩하는 기능입니다. DONs 기존 oracle 네트워크가 서비스 애플리케이션을 신속하게 구축할 수 있는 수단입니다. 이를 위해서는 오늘날 특수 목적으로 구축된 네트워크를 구축해야 합니다. 우리는 여러 가지를 제공합니다 섹션 4에 그러한 적용 사례가 나와 있습니다. 섹션 3에서는 DON에 대한 자세한 내용을 제공하고 해당 기능을 설명합니다. 개발자와 사용자에게 제공되는 인터페이스의 용어입니다. 1.2 7가지 주요 설계 목표 여기서는 위에서 열거한 7가지 핵심 초점을 간략하게 검토해 보겠습니다. Chainlink, 즉:하이브리드 smart contracts: Chainlink에 대한 우리 비전의 핵심은 보안이라는 아이디어입니다. smart contracts에서 온체인 및 오프체인 구성 요소를 결합합니다. 우리는 계약을 참조 이 아이디어를 하이브리드 smart contract 또는 하이브리드 계약으로 실현합니다.2 블록체인은 분산형 서비스에서 두 가지 중요한 역할을 수행하고 있으며 앞으로도 계속 그럴 것입니다. 생태계: 둘 다 암호화폐 소유권이 표현되는 장소입니다. 분산형 서비스를 위한 강력한 기반입니다. 따라서 스마트 계약은 체인에서 표현되거나 실행되어야 하지만 온체인 기능은 심각하게 제한됩니다. 순전히 온체인 계약 코드는 느리고, 비용이 많이 들고, 고립되어 있어 실제 세계의 이점을 누릴 수 없습니다. 다양한 형태의 기밀 계산, (의사)무작위성 생성 등 체인에서 본질적으로 달성할 수 없는 다양한 기능과 데이터 광부 / validator 조작 등에 대한 반대 따라서 smart contracts가 잠재력을 최대한 실현하려면 smart contracts가 필요합니다. 온체인 부분(일반적으로 SC로 표시)의 두 부분으로 구성됩니다. 그리고 DON에서 실행되는 실행 파일인 오프체인 부분(일반적으로 실행). 목표는 다음과 같은 온체인 기능의 안전한 구성을 달성하는 것입니다. DONs가 제공하고자 하는 다양한 오프체인 서비스. 두 부분이 함께 하이브리드 계약을 맺습니다. 우리는 그림 2에 개념적으로 아이디어를 제시합니다. 이미 오늘, Chainlink 데이터 피드 및 VRF와 같은 서비스3는 다른 방법으로는 달성할 수 없는 기능을 제공합니다. smart contract 애플리케이션은 DeFi에서 공정하게 생성된 NFT에 이르기까지 분산형 보험에 이르기까지 보다 일반적인 프레임워크를 향한 첫 번째 단계입니다. Chainlink 서비스로 이 백서의 비전에 따라 더 많은 성능을 확장하고 성장시킵니다. 모든 blockchain에 걸쳐 smart contract 시스템의 성능을 발휘하게 됩니다. 이 백서에 있는 다른 6가지 주요 초점은 서비스에서 작동하는 것으로 볼 수 있습니다. 첫째, 하이브리드 계약 중 가장 중요한 것 중 하나입니다. 이러한 초점에는 가시적인 제거가 포함됩니다. 하이브리드 계약으로 인한 복잡성으로 인해 추가적인 오프체인 서비스가 생성됩니다. 더욱 강력한 하이브리드 계약을 구축하고, 신뢰 최소화의 경우 하이브리드 계약을 통해 달성된 보안 속성을 강화합니다. 우리는 아이디어를 떠난다 논문의 대부분에 걸쳐 암묵적으로 혼합 계약이 존재하지만, DON이 포함된 MAINCHAIN 로직은 하이브리드 계약으로 볼 수 있습니다. 복잡성 추상화: DON은 분산화를 사용하도록 설계되었습니다. 종종 복잡한 기계를 추상화하여 개발자와 사용자가 쉽게 사용할 수 있는 시스템 DONs의 강력하고 유연한 서비스를 지원합니다. 기존 Chainlink 서비스 이미 이 기능이 있습니다. 예를 들어, 오늘날 Chainlink의 데이터 피드는 개발자가 프로토콜 수준의 세부 사항에 대해 걱정할 필요가 없는 온체인 인터페이스를 제공합니다. 2온체인/오프체인 계약 구성에 대한 아이디어는 이전에 다양한 제약 조건에서 나타났습니다. 양식(예: 레이어 2 시스템, TEE 기반 blockchains [80] 등)을 지원하고 일반화하는 것이 우리의 목표입니다. 이러한 접근 방식을 통해 오프체인 데이터 액세스 및 기타 키를 포괄할 수 있는지 확인합니다. oracle 서비스. 3Chainlink 서비스는 다음을 통해 제공되는 다양한 분산형 서비스와 기능으로 구성됩니다. 네트워크. 다양한 oracle 네트워크로 구성된 수많은 노드 운영자가 제공합니다. 생태계 전반에 걸쳐.그림 2: 온체인/오프체인 계약 구성을 나타내는 개념적 그림. 에이 하이브리드 smart contract 3⃝은 두 가지 보완적인 구성 요소, 즉 온체인으로 구성됩니다. blockchain에 상주하는 구성 요소 SC 1⃝ 및 오프 체인 구성 요소 exec 2⃝ DON에서 실행됩니다. DON은 두 구성요소 사이의 브리지 역할도 합니다. 웹 서비스 등 오프체인 리소스와 하이브리드 컨트랙트를 연결하는 등 blockchains, 분산형 저장소 등 분산된 노드 세트. DONs는 Chainlink이 개발자에게 추상화 계층을 제공할 수 있는 서비스 범위 높은 수준의 서비스를 위한 간소화된 인터페이스를 제공합니다. 이 접근 방식을 강조하는 몇 가지 응용 사례를 섹션 4에 제시합니다. 예를 들어 우리는 DONs를 보안 미들웨어의 한 형태로 사용하는 기업을 구상합니다. 레거시 시스템을 blockchain에 연결하세요. (섹션 4.2 참조) DON을 사용하면 일반적인 blockchain 역학(수수료, 재구성 등)의 복잡성이 추상화됩니다. 그것은 또한 특정 blockchain의 기능을 추상화하여 기업이 기존 시스템을 계속 확장되는 blockchain 시스템 어레이에 연결할 수 있도록 합니다. 이러한 시스템 또는 더 일반적으로는 분산형 시스템 개발에 대한 전문 지식이 필요합니다. 궁극적으로 우리의 목표는 Chainlink에 의해 달성된 추상화 수준을 높이는 것입니다. 우리가 분산형 메타레이어라고 부르는 것을 구현하는 지점까지 말이죠. 그러한 층 모든 계층의 개발자에 대한 온체인/오프체인 구분을 추상화합니다. 및 DApp 사용자를 통해 분산형 서비스를 원활하게 생성하고 사용할 수 있습니다.개발 프로세스를 단순화하기 위해 개발자는 메타 레이어의 DApp 기능을 통합 머신 모델의 가상 애플리케이션으로 지정할 수 있습니다. 그들은 할 수 있었다 그런 다음 분산형 금속층 컴파일러를 사용하여 DApp을 자동으로 인스턴스화합니다. blockchains, DONs에 걸쳐 상호 운용되는 분산 기능 세트 및 외부 서비스. (이러한 외부 서비스 중 하나는 엔터프라이즈 시스템일 수 있으므로 레거시 엔터프라이즈 시스템과 관련된 애플리케이션에 메타레이어를 유용하게 만듭니다.) 컴파일은 최신 컴파일러 및 소프트웨어 개발 키트(SDK)와 유사합니다. 이기종 하드웨어의 잠재력을 최대한 활용하는 일반 프로그래머 지원 범용 CPU와 GPU와 같은 특수 하드웨어로 구성된 아키텍처, 기계 학습 가속기 또는 신뢰할 수 있는 엔클레이브. 그림 3은 이 아이디어를 개념적 수준으로 제시합니다. 하이브리드 smart contract는 이 비전과 메타 계약이라고 부르는 개념을 향한 첫 번째 단계입니다. 메타 계약은 분산형 시스템에 코딩된 애플리케이션입니다. 메타레이어는 온체인 로직(smart contracts)뿐만 아니라 오프체인 계산 및 다양한 blockchains와 기존 오프체인 간의 연결을 암시적으로 포함합니다. 서비스. 언어 및 컴파일러 지원의 필요성을 고려하여 새로운 보안 모델 및 서로 다른 기술의 개념적, 기술적 조화는 실현되지만, 진정한 분산형 금속층을 구축하는 것은 우리가 오랫동안 열망해 온 야심찬 목표입니다. 시간 지평선. 그럼에도 불구하고 읽는 동안 명심해야 할 유용한 이상적인 모델입니다. 이 문서는 여기에 자세히 설명되어 있지 않지만 향후 작업에서 집중할 계획입니다. Chainlink. 스케일링: 진화하는 디자인에서 가장 중요한 목표는 Chainlink 네트워크는 blockchain 생태계의 증가하는 확장 요구 사항을 충족합니다. 기존 무허가형 환경에서는 네트워크 정체가 반복적으로 문제가 되면서 blockchains [86], 새롭고 더 성능이 뛰어난 blockchain 디자인이 사용되기 시작했습니다. 예를 들어 [103, 120, 203]과 보완적인 레이어 2 스케일링 기술(예: [5, 12, 121, 141, 169, 186, 187]. Oracle 서비스는 지연 시간과 처리량을 달성해야 합니다. 온체인 수수료를 최소화하면서 이러한 시스템의 성능 요구 사항을 충족합니다. (예: 가스 비용) 계약 운영자와 일반 사용자 모두에게 적용됩니다. DONs, Chainlink 사용 기능은 더 나아가 순수한 웹 기반 시스템에 충분히 높은 성능을 제공하는 것을 목표로 합니다. DONs는 blockchains와 결합된 빠른 위원회 기반 또는 무허가 합의 프로토콜을 사용하여 많은 성능 향상을 얻습니다. 그들은 지원합니다. 우리는 서로 다른 구성을 가진 많은 DON이 병렬로 실행될 것으로 예상합니다. 다양한 DApp과 사용자는 기본 합의 선택에서 트레이드오프를 탐색할 수 있습니다. 그들의 신청 요구 사항에 따라. DON은 사실상 레이어 2 기술로 볼 수 있습니다. 우리는 그 중에서 다른 서비스에서는 DONs가 TEF(Transaction Execution Framework)를 지원합니다. DON 및 oracle을 다른 고성능 제품과 효율적으로 통합할 수 있습니다. 레이어 2 시스템(예: rollups, 달성하기 위해 오프체인 트랜잭션을 번들로 묶는 시스템) 성능 개선. 섹션 6에서 TEF를 소개합니다.
그림 3: 분산형 금속층의 이상적인 구현을 보여주는 개념적 그림. 에 대한 개발의 용이성을 위해 개발자는 분홍색으로 강조된 DApp을 가상 애플리케이션으로 지정합니다. 통합 기계 모델에 적용. 분산형 메탈레이어 컴파일러는 해당 상호 운용 기능을 자동으로 생성합니다: smart contracts(표시됨) SC별), DONs의 논리(exec로 표시됨), 대상 외부 서비스에 연결하는 어댑터 등은 노란색으로 강조 표시됩니다. 그림 4는 DONs가 blockchain(smart contract) 스케일링을 어떻게 개선하는지 개념적으로 보여줍니다. 거래 및 oracle-보고서 처리를 온체인이 아닌 오프체인에 집중함으로써 체인. 계산의 주요 위치가 바뀌면 트랜잭션 대기 시간이 줄어들고 거래 처리량을 높이는 동시에 수수료를 부과합니다. 기밀성: 블록체인은 smart contracts 및 그들이 실현하는 애플리케이션에 대해 전례 없는 투명성을 제공합니다. 그러나 투명성과 기밀성 사이에는 기본적인 긴장이 있습니다. 예를 들어, 오늘날 사용자의 분산형 교환 거래는그림 4: 분산형 Oracle 네트워크가 어떻게 성능을 향상시키는지를 보여주는 개념적 그림 blockchain 활성화된 smart contract의 크기 조정. 그림 A ⃝는 기존의 oracle을 보여줍니다. 건축. 거래는 oracle 보고서와 마찬가지로 blockchain로 직접 전송됩니다. 따라서 노란색으로 강조 표시된 blockchain은 트랜잭션 처리의 주요 위치입니다. 그림 B⃝는 blockchain에 대한 계약을 지원하기 위해 DON을 사용하는 것을 보여줍니다. A DON 실행 파일은 외부 시스템의 데이터와 함께 트랜잭션을 처리하고 전달합니다. 결과(예: 번들 트랜잭션 또는 트랜잭션 효과로 인한 계약 상태 변경)를 blockchain에 보냅니다. 따라서 노란색으로 강조 표시된 DON가 주요 트랜잭션 처리를 위한 위치입니다. 활동은 체인에 기록되므로 교환 활동을 쉽게 모니터링할 수 있을 뿐만 아니라 사용자의 금융 거래를 공개적으로 표시합니다. 마찬가지로 데이터가 스마트로 전달됩니다. 계약은 체인에 남아 있습니다. 이를 통해 이러한 데이터를 편리하게 감사할 수 있지만 다음과 같은 역할을 합니다. smart contract에 민감하거나 민감한 데이터를 제공하려는 데이터 제공자에게는 방해가 됩니다. 독점 데이터. 우리는 oracle 네트워크가 차세대 촉매 역할을 할 것이라고 믿습니다. blockchains의 타고난 투명성과 새로운 기밀 보호 기능을 결합한 시스템입니다. 이 문서에서는 세 가지 주요 접근 방식을 사용하여 이를 수행하는 방법을 보여줍니다. • 기밀 유지 어댑터: 계획된 배포가 포함된 두 가지 기술 Chainlink의 네트워크 DECO [234] 및 Town Crier [233]에서 oracle 노드를 활성화합니다. 사용자 개인정보와 데이터를 보호하는 방식으로 오프체인 시스템에서 데이터를 검색합니다. 기밀성. 이는 DONs용 어댑터 설계에서 중요한 역할을 합니다. (이 두 기술에 대한 자세한 내용은 섹션 3.6.2를 참조하세요.) • 기밀 계산: DONs는 blockchains에 의존하지 않도록 자신의 계산을 숨길 수 있습니다. 안전한 다자간 계산 및/또는 신뢰할 수 있는 실행 환경을 사용하면 DON 노드에서 더 강력한 기밀성이 가능합니다. 자신이 볼 수 없는 데이터에 대해 계산합니다.
• 기밀 레이어 2 시스템 지원: TEF는 다양한 레이어 2 시스템을 지원하도록 설계되었으며, 그 중 다수는 영지식 증명을 사용하여 다음을 제공합니다. 다양한 형태의 거래 기밀성. 섹션 3에서 이러한 접근 방식을 논의합니다(섹션 6, 부록 B.1 및 부록 B.2의 추가 세부정보 포함). 그림 5는 기밀 유지 어댑터를 통해 민감한 데이터가 외부 소스에서 smart contract로 어떻게 흐를 수 있는지에 대한 개념적 보기를 제공합니다. DON의 기밀 계산. 그림 5: DON의 기밀 유지 작업에 대한 개념 다이어그램 민감한 데이터(노란색으로 강조 표시됨) 웹의 민감한 소스 데이터(검은색 원) 서버는 기밀 유지 어댑터(파란색, 이중 화살표 선)를 사용하여 DON로 추출됩니다. DON는 이러한 어댑터로부터 파생된 데이터(빈 원)를 수신합니다. 민감한 소스에 기능이나 비밀 공유 등을 적용한 결과 데이터. DON의 실행 파일은 파생된 데이터에 기밀 계산을 적용할 수 있습니다. 보고서(이중 원)를 구성하여 어댑터를 통해 blockchain로 보냅니다. 우리는 기밀 데이터를 처리하는 강력한 도구가 전체를 열어줄 것이라고 믿습니다. 응용 범위. 그 중에는 민간 분산형(및 중앙집중형) 금융, 분산형 신원, 신용 기반 온체인 대출, 보다 효율적이고 섹션 4에서 논의한 바와 같이 사용자 친화적인 고객 파악 및 인증 프로토콜. 거래의 주문 공정성: 오늘의 blockchain 디자인에는 약간 더러운 부분이 있습니다. 공개 비밀: 일시적으로 중앙 집중화되어 있습니다. 광부와 validators는 거래를 주문할 수 있습니다.그들이 선택한 행동. 거래 순서는 다음과 같이 사용자가 조작할 수도 있습니다. 그들이 지불하는 네트워크 수수료의 함수(예: Ethereum의 가스 가격) 및 일부 빠른 네트워크 연결을 활용하여 확장합니다. 그러한 조작은 다음과 같은 경우에 발생할 수 있습니다. 예를 들어, 채굴자와 같은 전략적 행위자가 참여하는 선행 실행(front-running) 형태를 취합니다. 사용자의 거래를 관찰하고 자신의 악용 거래를 이전 거래에 삽입합니다. 동일한 블록에 위치 - 사용자 거래에 대한 사전 지식을 활용하여 사용자로부터 효과적으로 돈을 훔칩니다. 예를 들어, 봇이 구매 주문을 할 수 있습니다. 사용자 앞에. 그러면 이는 다음으로 인한 자산 가격 상승을 활용할 수 있습니다. 사용자의 거래. 일반 사용자에게 해를 끼치는 일부 봇의 선행 실행(고빈도와 유사) 월스트리트에서의 거래는 이미 널리 퍼져 있으며 관련 내용이 잘 문서화되어 있습니다 [90] 백러닝 [159] 및 [195]을 모방한 자동 트랜잭션과 같은 공격. 채굴자들의 주문 착취를 체계화하려는 제안도 최근에 표면화되었습니다([110]). rollups와 같은 레이어 2 기술은 문제를 해결하지 못하고 단지 재중앙화만 합니다. 주문하여 rollup을 생성하는 개체의 손에 넘겨줍니다. 우리의 목표 중 하나는 Chainlink에 Fair Sequencing이라는 서비스를 도입하는 것입니다. 서비스 (FSS) [137]. FSS는 smart contract 디자이너가 공정한 주문을 보장하도록 돕습니다. 트랜잭션을 방지하고 사용자 트랜잭션은 물론 oracle 보고서 전송과 같은 기타 유형의 트랜잭션에 대한 선행 실행, 역실행 및 관련 공격을 방지합니다. FSS [144]에 도입된 엄격하고 일시적인 질서 공정성 개념과 같은 아이디어를 DON에서 구현할 수 있습니다. 부수적인 이점으로 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 contracts 및 기타 oracle 종속 시스템에 대한 신뢰할 수 있는 지원 계층 분산화, 암호화 도구 및 암호화 경제 보장을 통해. DON 자체는 분산되어 있으며 사용자는 사용 가능한 DON 중에서 선택할 수 있습니다. 추가 DON을 운영하거나 생성하려는 메인 체인을 지원합니다. 그들이 신뢰하는 노드 위원회를 통해. 그러나 일부 애플리케이션, 특히 smart contracts, Chainlink 사용자의 경우 DON이 지원하는 메인 체인을 더 신뢰할 수 있는 것으로 취급하는 신뢰 모델을 선호합니다. DON 자체보다. 그러한 사용자를 위해 우리는 이미 Chainlink 네트워크의 아키텍처 계약을 가능하게 하는 다양한 메커니즘 DONs가 제공하는 보안 보증을 강화하기 위해 메인 체인에 동시에 데이터 소스가 손상될 가능성에 대비한 보호 조치도 시행합니다. DON이 데이터를 얻는 웹 서버와 같은 것입니다. 우리는 섹션 7에서 이러한 메커니즘을 설명합니다. 이는 다섯 가지 주요 제목으로 분류됩니다. • 데이터 소스 인증: 데이터 공급자가 디지털 서명을 할 수 있게 해주는 도구 데이터를 수집하여 원산지와 원산지 간의 관리 사슬을 강화합니다. 의존 계약. • DON 소수 보고서: DON 노드의 소수 하위 집합에서 발행한 플래그입니다. DON에서 대부분의 불법 행위를 관찰했습니다. • 가드레일: 비정상적인 조건을 감지하고 일시 중지하는 메인 체인의 로직 또는 계약 실행을 중단합니다(또는 다른 수정 조치를 호출합니다). • 신뢰가 최소화된 거버넌스: 점진적인 릴리스 업데이트를 사용하여 커뮤니티 검사를 촉진하고 분산형 긴급 개입을 통해 신속한 조치를 취합니다. 시스템 장애에 대한 대응. • 분산형 엔터티 인증: 공개 키 인프라(PKI)를 사용하여 다음을 수행합니다. Chainlink 네트워크의 엔터티를 식별합니다. 그림 7은 신뢰 최소화 목표의 개념적 개략도를 나타냅니다. 인센티브 기반(암호경제적) 보안: oracle 노드 전반에 걸쳐 보고서 생성을 분산화하면 일부 노드가 손상된 경우에도 보안을 보장할 수 있습니다.
그림 7: Chainlink의 신뢰 최소화 목표에 대한 개념적 묘사 DON 및 웹과 같은 데이터 소스의 올바른 동작에 대한 사용자의 요구를 최소화합니다. 서버. 그림의 노란색 강조 표시는 신뢰 최소화 위치를 나타냅니다: DON 및 개별 또는 소수의 웹 서버 세트. 분홍색 강조 표시는 시스템 구성 요소를 나타냅니다. 가정에 의해 매우 신뢰할 수 있는 것: blockchain에 대한 계약 및 대다수 웹 서버의 수, 즉 웹 서버 전체를 의미합니다. 하지만 마찬가지로 중요한 것은 노드가 올바르게 행동할 수 있는 재정적 인센티브를 갖도록 보장하는 것입니다. 스테이킹, 즉 노드가 LINK 예치금을 제공하고 슬래싱하도록 요구 (압수) 잘못된 행동이 있을 경우 이러한 예금은 Chainlink에서 핵심적인 역할을 할 것입니다. 이미 다수의 blockchain에서 사용되고 있는 중요한 인센티브 디자인입니다. 예를 들어 [81, 103, 120, 204]. 그러나 Chainlink에 스테이킹하는 것은 독립 실행형의 staking과 매우 다르게 보입니다. blockchains. blockchains에 스테이킹하는 것은 합의에 대한 공격을 방지하는 것을 목표로 합니다. 그것은 Chainlink의 다른 목표: 올바른 oracle 보고서를 적시에 전달하는 것입니다. oracle 네트워크를 위해 잘 설계된 staking 시스템은 뇌물 수수와 같은 공격을 렌더링해야 합니다. 목표가 높은 smart contract인 경우에도 적에게는 이익이 되지 않습니다. 금전적 가치. 본 논문에서는 세 가지 핵심을 통해 Chainlink의 staking에 대한 일반적인 접근 방식을 제시합니다. 혁신:1. 기존에서 간과된 공격을 포괄하는 강력한 적대 모델 접근합니다. 한 가지 예는 우리가 장래 뇌물 수수라고 부르는 것입니다. 이것은 다음과 같은 형태입니다. 어떤 노드가 조건부로 뇌물을 받는지 결정하는 뇌물 수수. staking 메커니즘이 선택한 노드에 미리 보장된 뇌물을 제공합니다. 특정 역할에 대해 무작위입니다(예: 보고서 심사 실행). 2. 초선형 staking 영향, 즉 성공하려면 적의 예산이 모든 oracle의 예금을 합친 것보다 $B 더 커야 함을 비공식적으로 의미합니다. 노드. 보다 정확하게는 n의 함수로서 \(B(n) ≫\)dn이 각각 고정 입금액 $d를 갖는 n oracle 노드의 네트워크(보다 공식적으로는 \(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에서 보안 모델과 표기법을 제시하고 분산형 보안의 개요를 설명합니다. 섹션 3의 Oracle Network API. 섹션 4에서는 다음과 같은 여러 가지 예를 제시합니다. DONs가 매력적인 배포 플랫폼을 제공하는 애플리케이션입니다. 독자는 다음을 수행할 수 있습니다. 지금까지 읽으면 논문의 주요 개념 대부분을 배울 수 있습니다. 문서의 나머지 부분에는 더 자세한 내용이 포함되어 있습니다. 우리는 공정한 순서를 설명합니다 섹션 5의 서비스(FSS) 및 섹션 6의 거래 실행 프레임워크(TEF). 섹션 7에서는 신뢰 최소화에 대한 접근 방식을 설명합니다. 중요한 DON 배포 요구 사항, 즉 기능의 점진적 출시, 동적 원장 멤버십 및 섹션 8의 책임. 마지막으로 섹션 9에서 다음을 제공합니다. 인센티브 디자인에 대한 우리의 개발 접근 방식에 대한 개요입니다. 섹션 10에서 결론을 내린다. 이 문서의 개념에 익숙하지 않은 독자를 돕기 위해 우리는 부록 A에 용어집을 제공합니다. DON 인터페이스에 대한 자세한 내용을 제시합니다. 및 기능은 부록 B에 나와 있으며 부록 C에는 몇 가지 어댑터 예시가 나와 있습니다. 부록 D에서는 신뢰가 최소화된 데이터 소스에 대한 암호화 기본 요소를 설명합니다. 기능 서명이라는 인증을 도입하고 이산화된 기능 서명이라는 새로운 변형을 도입합니다. 우리는 위원회와 관련된 몇 가지 고려 사항을 논의합니다. 부록 F의 DON에 대한 선택
セキュリティモデルと目標
分散型 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 노드 세트에 의해 실행됩니다. 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: 그 목적은 blockchain 및 기타 시스템을 지원하는 것입니다. 블록체인은, 물론 신뢰할 수 있는 원장을 실현하는 한 가지 방법이지만 다른 방법도 있습니다. 우리는 기대한다 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을 사용하지 않더라도 L에 기록됩니다.2.3 표기법 원장을 실행하는 n oracle 노드 집합을 O = {Oi}n으로 나타냅니다. 나는 = 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 표기법을 사용하여 다음을 수행합니다. 그러한 계약을 나타냅니다. 우리는 일반적으로 DON이 단일 메인 체인 MAINCHAIN을 지원한다고 가정하지만, 섹션 4의 예에서 볼 수 있듯이 여러 체인을 지원할 수 있습니다. A DON은 MAINCHAIN에서 여러 의존 계약을 지원할 수 있으며 일반적으로 지원할 것입니다. ( 위에서 언급했듯이 DON은 blockchain이 아닌 서비스를 대안으로 지원할 수 있습니다.) 2.4 신뢰 모델에 대한 참고 사항 위에서 언급했듯이 DON은 위원회 기반 합의 프로토콜 위에 구축될 수 있으며, 그들은 일반적으로 그러한 프로토콜을 사용할 것으로 예상합니다. 강력한 주장이 많다. 위원회 기반 또는 무허가 blockchains의 두 가지 대안 중 하나는 다음을 제공합니다. 다른 것보다 보안이 더 강력합니다. 위원회 기반 보안과 무허가 보안의 보안을 인식하는 것이 중요합니다. 분산형 시스템은 비교할 수 없습니다. PoW 또는 PoS 침해 blockchain 51% 공격을 통해 적이 일시적으로 대부분의 자원을 획득해야 하며 예를 들어 PoW 시스템에서 hash 전력을 임대함으로써 잠재적으로 익명으로 가능합니다. 그러한 실제로 공격은 이미 여러 blockchains [200, 34]에 영향을 미쳤습니다. 대조적으로, 위원회 기반 시스템을 손상시키는 것은 노드의 임계값(일반적으로 1/3)을 손상시키는 것을 의미합니다. 여기서 노드는 공개적으로 알려지고 리소스가 풍부하며 그리고 신뢰할 수 있는 실체. 반면에 위원회 기반 시스템(및 무허가형 "하이브리드") 위원회를 지원하는 시스템)은 엄격하게 규정된 것보다 더 많은 기능을 지원할 수 있습니다.미션리스 시스템. 여기에는 다음과 같은 지속적인 비밀을 유지하는 기능이 포함됩니다. 서명 및/또는 암호화 키는 우리 설계의 한 가지 가능성입니다. 우리는 DON이 원칙적으로 위원회 기반 또는 무허가 합의 프로토콜 및 DON 배포자는 궁극적으로 채택을 선택할 수 있습니다. 어느 쪽이든 접근합니다. 신뢰 모델 강화: 오늘날 Chainlink의 주요 기능은 사용자가 다음을 수행할 수 있다는 것입니다. 논의된 대로 성능 기록의 분산된 기록을 기반으로 노드를 선택합니다. 섹션 3.6.4. 섹션 9에서 소개하는 staking 메커니즘과 암시적 인센티브 프레임워크는 함께 광범위하고 엄격한 메커니즘 설계를 구성합니다. DONs의 보안을 측정할 수 있는 크게 확장된 기능을 사용자에게 제공하는 프레임워크입니다. 이 동일한 프레임워크를 통해 DONs 자체도 가능해집니다. 참여 노드에 다양한 보안 요구 사항을 적용하고 운영을 보장합니다. 강력한 신뢰 모델 내에서. DONs에 대해 이 문서에 설명된 도구를 사용하여 규제 요구 사항 준수와 같은 특별한 신뢰 모델 요구 사항을 적용하는 것도 가능합니다. 에 대한 예를 들어, 섹션 4.3에서 논의된 기술을 사용하여 노드는 다음의 증거를 제시할 수 있습니다. 노드-운영자 특성(예: 작업 영역)을 돕는 데 사용할 수 있습니다. 예를 들어 일반 데이터 보호 규정(GDPR) 제3조(“지역 범위”) [105] 준수를 시행합니다. 그렇지 않으면 그러한 준수가 어려울 수 있습니다. 분산형 시스템에서 만나세요 [45]. 또한 섹션 7에서는 DON의 견고성을 강화하기 위한 계획에 대해 논의합니다. 그들이 지원하는 메인 체인의 신뢰 최소화 메커니즘을 통해.
分散型 Oracle ネットワーク インターフェイスと Ca-
能力 ここでは、シンプルかつ強力な観点から DONs の機能を簡単に説明します。 インターフェイスを実現するように設計されています。 DON 上のアプリケーションは、実行可能ファイルとアダプターで構成されます。実行可能ファイルは、 smart contract に類似した、コア ロジックが決定論的プログラムであるプログラム。 実行可能ファイルには、エントリを呼び出すプログラムであるイニシエーターも多数付属しています。 事前に決定されたイベントが発生したとき (特定の時間など)、実行可能ファイルのロジック内のポイント (cron ジョブのように)、価格がしきい値を超えたときなど、Keepers (セクション 3.6.3 を参照) とよく似ています。アダプターはオフチェーン リソースへのインターフェイスを提供し、アダプターによって呼び出されます。 イニシエーターまたは実行可能ファイルのコア ロジックのいずれか。彼らの行動はそれに依存する可能性があるため、 外部リソース、イニシエーター、アダプターは非決定的に動作する可能性があります。 DON 開発者インターフェイスと実行可能ファイルの機能について説明します。 コンピューティング システムを特徴付けるために通常使用される 3 つのリソース (ネットワーキング、コンピューティング、ストレージ) の観点からアダプターを説明します。これらのそれぞれについて簡単に概要を説明します 以下のリソースを参照し、付録 B で詳細を説明します。
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 によって提供される経済的安全性の広範なビュー。
분산형 Oracle 네트워크 인터페이스 및 Ca-
능력 여기에서는 간단하지만 강력한 측면에서 DON의 기능을 간략하게 설명합니다. 인터페이스를 실현하도록 설계되었습니다. DON의 애플리케이션은 실행 파일과 어댑터로 구성됩니다. 실행 파일은 핵심 논리가 smart contract과 유사한 결정론적 프로그램인 프로그램입니다. 실행 파일에는 항목을 호출하는 프로그램과 함께 제공되는 여러 시작 프로그램도 있습니다. 미리 결정된 이벤트가 발생할 때 실행 파일 논리의 지점(예: 특정 시간) (크론 작업과 같은), 가격이 임계값을 초과하는 경우 등 - 키퍼와 매우 유사합니다(섹션 3.6.3 참조). 어댑터는 오프체인 리소스에 대한 인터페이스를 제공하며 다음에 의해 호출될 수 있습니다. 실행 파일의 개시자 또는 핵심 논리입니다. 그들의 행동은 그것에 달려 있을 수 있기 때문에 외부 리소스의 경우 개시자 및 어댑터가 비결정적으로 동작할 수 있습니다. 우리는 DON 개발자 인터페이스와 실행 파일의 기능을 설명하고 컴퓨팅 시스템을 특성화하는 데 일반적으로 사용되는 세 가지 리소스인 네트워킹, 컴퓨팅, 스토리지 측면에서 어댑터를 설명합니다. 우리는 이들 각각에 대한 간략한 개요를 제공합니다 아래 리소스를 참조하고 부록 B에 자세한 내용을 제공하세요.
3.1 네트워킹 어댑터는 DON에서 실행되는 실행 파일을 보내고 전송할 수 있는 인터페이스입니다. off-DON 시스템에서 데이터를 수신합니다. 어댑터는 다음의 일반화로 볼 수 있습니다. 현재 Chainlink에서 사용되는 어댑터 [20]. 어댑터는 양방향일 수 있습니다. 그냥 끌어올 수는 없지만 DON에서 웹 서버로 데이터를 푸시할 수 있습니다. 그들은 또한 활용할 수도 있습니다 분산 프로토콜 및 보안 다자간 보안과 같은 암호화 기능 계산. 그림 9: DON1로 표시되는 DON을 DON2로 표시되는 또 다른 DON, blockchain(메인 체인) 및 해당 리소스를 포함한 다양한 리소스와 연결하는 어댑터 멤풀, 외부 저장소, 웹 서버 및 IoT 장치(웹 서버를 통해). 어댑터가 생성될 수 있는 외부 리소스의 예가 표시됩니다. 그림 9에서. 여기에는 다음이 포함됩니다. • 블록체인: 어댑터는 blockchain에 트랜잭션을 보내는 방법을 정의할 수 있으며 블록, 개별 트랜잭션 또는 기타 상태를 읽는 방법. 어댑터 blockchain의 mempool에 대해서도 정의할 수 있습니다. (섹션 3.5 참조) • 웹 서버: 어댑터는 데이터를 검색할 수 있는 API를 정의할 수 있습니다. 특별히 적합하지 않은 레거시 시스템을 포함한 웹 서버에서 DONs와 인터페이스합니다. 이러한 어댑터에는 데이터를 전송하는 API도 포함될 수 있습니다. 그런 서버. DON이 연결되는 웹 서버는 게이트웨이 역할을 할 수 있습니다. IoT(사물 인터넷) 장치와 같은 추가 리소스에 연결됩니다.• 외부 저장소: 어댑터는 저장소를 읽고 쓰는 방법을 정의할 수 있습니다. 분산 파일 시스템[40, 188] 또는 클라우드와 같은 DON 외부 서비스 저장. • 기타 DONs: 어댑터는 DONs 간에 데이터를 검색하고 전송할 수 있습니다. DONs의 초기 배포에는 일련의 빌딩 블록이 포함될 것으로 예상됩니다. 일반적으로 사용되는 외부 리소스에 대한 어댑터를 추가로 허용하고 DON 특정 DON 노드에서 게시할 어댑터입니다. smart contract 개발자가 어댑터를 작성함에 따라 오늘 우리는 그들이 이 고급 기술을 사용하여 훨씬 더 강력한 어댑터를 구축할 것으로 기대합니다. 기능. 우리는 궁극적으로 사용자가 새로운 어댑터를 생성하는 것이 가능할 것으로 기대합니다. 무허가 방식. 일부 어댑터는 DON에 의해 제어되는 외부 리소스의 지속성과 가용성을 보장하는 방식으로 구성되어야 합니다. 예를 들어 클라우드 스토리지는 다음과 같습니다. 클라우드 서비스 계정의 유지 관리가 필요합니다. 또한 DON는 다음을 수행할 수 있습니다. 사용자를 대신하여 개인 키의 분산 관리(예: [160]) 및/또는 실행 파일. 결과적으로 DON은(예: blockchain 대상에서 트랜잭션을 보내는 데 사용될 수 있는) 암호화폐와 같은 리소스를 제어할 수 있습니다. DON 어댑터에 대한 자세한 내용은 부록 B.1을 참조하세요. 예시 어댑터. 3.2 계산 실행 파일은 DON의 기본 코드 단위입니다. 실행 파일은 exec = 쌍입니다. (논리, 초기화). 여기서 로직은 다수의 지정된 항목이 있는 결정론적 프로그램입니다. points (logic1, logic2, ..., logicℓ) 및 init는 해당 개시자의 집합입니다. (init1, init2, ..., inite). 실행 파일의 논리인 DON의 전체 감사 가능성을 보장하려면 모든 입력과 출력에 기본 원장 L을 사용합니다. 따라서 예를 들어 모든 어댑터는 실행 파일에 대한 입력으로 사용되는 데이터는 먼저 L에 저장되어야 합니다. 개시자: 현재 Chainlink의 개시자는 이벤트에 따른 작업 실행을 유발합니다. Chainlink 노드 [21]. DONs의 개시자는 거의 동일한 방식으로 작동합니다. 그러나 DON 개시자는 실행 파일과 구체적으로 연결됩니다. 개시자는 의존할 수 있습니다 외부 사건이나 상태, 현재 시간, 또는 DON 상태에 대한 술어. 이벤트에 대한 의존성으로 인해 개시자는 물론 비결정적으로 동작할 수도 있습니다. (물론 어댑터도 마찬가지입니다). 개시자는 개별 DON 노드 내에서 실행할 수 있습니다. 따라서 어댑터에 의존할 필요가 없습니다. (아래 예 1을 참조하세요.) 개시자는 실행 파일을 smart contract과 구별하는 중요한 기능입니다. 실행 파일은 개시자에 대한 응답으로 실행될 수 있으므로 효과적으로 작동할 수 있습니다. 물론 확장을 통해 실행 파일을 통합하는 하이브리드 계약이 자율적으로 가능합니다. 오늘날 개시자의 한 형태는 거래를 제공하는 Chainlink Keeper입니다.oracle 보고서를 기반으로 과소담보 대출 청산 및 지정가 주문 거래 실행과 같은 smart contract 실행을 실행하는 자동화 서비스입니다. 편리하게도 DONs의 개시자를 지정하는 방법으로 볼 수도 있습니다. 실행 파일에 적용되는 서비스 계약(아래 상황을 정의함) DON에서 호출해야 합니다. 다음 예에서는 실행 파일 내에서 개시자가 작동하는 방식을 보여줍니다. 예시 1(편차로 인한 가격 피드) smart contract SC에는 새로운 것이 필요할 수 있습니다. 예를 들어 1%와 같이 상당한 변화가 있을 때마다 가격 피드 데이터(섹션 3.6.3 참조) 한 쌍의 자산(예: ETH-USD) 간의 환율. 변동성에 민감한 가격 피드는 현재 Chainlink에서 지원되지만 어떻게 지원되는지 살펴보는 것이 좋습니다. 실행 가능한 execfeed를 통해 DON에서 실현되었습니다. 실행 가능한 execfeed는 L의 가장 최근 ETH-USD 가격 r을 유지합니다. ⟨NewPrice : j, r⟩항목의 시퀀스 형태. 여기서 j는 다음과 같이 증가하는 인덱스입니다. 각 가격 업데이트. 개시자 init1은 각 노드 Oi가 현재 ETH-USD 가격을 모니터링하도록 합니다. 인덱스 j를 사용하여 가장 최근에 저장한 가격 r에서 최소 1%의 편차. 시 이러한 편차를 감지한 Oi는 다음을 사용하여 새 가격의 현재 보기 ri를 L에 기록합니다. ⟨PriceView : i, j + 1, ri⟩ 형식의 항목. 두 번째 개시자 init2는 새 가격이 포함된 PriceView 항목이 k개 이상 있을 때 발생합니다. 개별 노드에서 생성된 인덱스 j + 1의 값이 L에 누적됩니다. 그러면 init2 첫 번째 k개의 유효한 유효한 가격 보기 값 k개의 중앙값 ρ를 계산하기 위해 진입점 logic2를 호출하고 새로운 값 ⟨NewPrice : j + 1, ρ⟩을 L에 씁니다. (운영상 노드 교대로 지정작가가 될 수 있다.) 세 번째 개시자 init3은 L의 NewPrice 항목을 감시합니다. 새 보고서가 나올 때마다 ⟨NewPrice : j, r⟩가 거기에 나타나며 (j, r)을 SC에 푸시하는 진입점 logic3을 호출합니다. 어댑터를 사용하여. 앞서 언급했듯이 실행 파일은 기능 면에서 smart contract과 유사합니다. 그러나 더 높은 성능 외에도 일반적인 메인 체인 계약과 다릅니다. 두 가지 중요한 방법으로: 1. 기밀성: 실행 파일은 기밀 계산을 수행할 수 있습니다. 즉, 비밀 프로그램이 일반 텍스트 입력을 처리하거나 게시된 프로그램이 처리할 수 있습니다. 비밀 입력 데이터 또는 둘의 조합. 간단한 모델에서는 비밀 데이터가 중간 결과를 숨기고만 공개하는 DON 노드에서 액세스할 수 있습니다. MAINCHAIN에 처리 및 삭제된 값. DONs 자체에서 민감한 데이터를 숨기는 것도 가능합니다. DONs는 다음과 같은 접근 방식을 지원하기 위한 것입니다. 다자간 계산(예: [42, 157]) 및 신뢰할 수 있는 실행 환경 (TEE) [84, 133, 152, 229] 이 목적을 위해.6 6더 나아가 DON 노드와 관련하여 실행 파일 자체를 비밀로 유지하는 것도 가능합니다. 이는 오늘날 TEE를 사용하는 중요하지 않은 실행 파일에만 실용적입니다.2. 지원 역할: 실행 파일은 기본에서 smart contract을 지원하기 위한 것입니다. 체인을 교체하는 대신 실행 파일에는 다음과 같은 몇 가지 제한 사항이 있습니다. smart contract은(는) 다음을 수행하지 않습니다. (a) 신뢰 모델: 실행 파일은 다음에 의해 정의된 신뢰 모델 내에서 작동합니다. DON: 올바른 실행은 O의 정직한 행동에 달려 있습니다. (메인 그러나 체인은 DON 불법 행위에 대한 일부 가드 레일을 제공할 수 있습니다. 섹션 7.3에서 논의됨) (b) 자산 액세스: DON은 blockchain의 계정을 제어할 수 있으므로 어댑터를 통해 자산을 제어합니다. 하지만 DON은 정식으로 사용할 수 없습니다. Ether 또는 ERC20 tokens와 같은 메인 체인에서 생성된 자산을 나타냅니다. 그들의 네이티브 체인은 소유권에 대한 권위 있는 기록을 유지합니다. (c) 수명 주기: DONs는 다음과 같이 제한된 수명으로 의도적으로 유지될 수 있습니다. DONs와 소유자 간의 온체인 서비스 수준 계약에 의해 정의됩니다. 의존 계약의. 대조적으로, 블록체인은 다음과 같이 기능하도록 되어 있습니다. 영구 보관 시스템. DON 계산에 대한 자세한 내용은 부록 B.2를 참조하세요. 3.3 저장 위원회 기반 시스템인 DON은 적당한 양의 데이터를 지속적으로 저장할 수 있습니다. L에서는 무허가 blockchain보다 훨씬 저렴한 비용으로 사용할 수 있습니다. 또한 어댑터를 통해 DONs는 데이터 저장을 위해 외부 분산 시스템을 참조할 수 있습니다(예: Filecoin [85], 이를 통해 해당 시스템을 smart contract에 연결할 수 있습니다. 이 옵션은 특히 "부풀음"이라는 만연한 문제를 해결하는 수단으로 대량 데이터에 적합합니다. blockchain 시스템. 따라서 DONs는 특별히 지원되는 서비스에 사용하기 위해 데이터를 로컬 또는 외부에 저장할 수 있습니다. DON은(는) 이러한 데이터를 기밀 방식으로 추가로 사용할 수 있습니다. (1) DON 노드 전체에서 비밀 공유되거나 암호화된 데이터에 대한 컴퓨팅 안전한 다자간 계산에 적합한 방식으로 DON 노드에서 관리하는 키 또는 부분적 또는 완전 동형 암호화; 또는 (2) 신뢰할 수 있는 실행을 사용하여 보호됨 환경. 우리는 DONs가 일반적인 간단한 메모리 관리 모델을 채택할 것으로 기대합니다. 스마트 계약 시스템: 실행 파일은 자체 메모리에만 쓸 수 있습니다. 실행 파일 그러나 다른 실행 파일의 메모리에서는 읽을 수 있습니다. DON 저장소에 대한 자세한 내용은 부록 B.3을 참조하세요. 3.4 트랜잭션 실행 프레임워크(TEF) DONs는 메인 체인 MAINCHAIN(또는 여러 메인 체인)의 계약을 지원하기 위한 것입니다. TEF(Transaction-Execution Framework)에 대해 자세히 설명합니다.섹션 6에서는 효율적인 계약 실행에 대한 일반적인 목적의 접근 방식을 설명합니다. MAINCHAIN 및 DON 전반의 SC. TEF는 FSS 및 레이어-2를 지원하도록 고안되었습니다. 원하는 경우 기술을 동시에 사용할 수 있습니다. 사실상 주력 차량이 될 가능성이 크다. FSS 사용에 대한 것입니다(그러한 이유로 이 섹션에서는 FSS에 대해 더 이상 논의하지 않습니다). 간단히 말해서, TEF에서는 MAINCHAIN을 위해 설계되거나 개발된 원래 대상 계약 SC입니다. 하이브리드 계약으로 리팩토링됩니다. 이 리팩토링은 두 가지 상호 운용성을 생성합니다. 하이브리드 계약의 일부: 명확성을 위해 우리가 언급하는 MAINCHAIN 계약 SCa TEF의 맥락에서 앵커 계약 및 DON의 실행 파일 실행 파일입니다. 는 계약 SCa는 사용자의 자산을 관리하고 권위 있는 상태 전환을 실행하며 DON의 오류에 대비한 보호 레일(섹션 7.3 참조)을 제공합니다. 실행 파일 exec 트랜잭션을 순서대로 나열하고 관련 oracle 데이터를 제공합니다. 묶을 수 있다 다양한 방법(예: 유효성 증명 기반 또는 낙관적인 rollups, DON에 의한 기밀 실행 등 우리는 개발자가 계약을 쉽게 분할할 수 있는 도구를 개발할 것으로 기대합니다. 고급 언어로 작성된 SC는 MAINCHAIN 및 DON 로직, SCa 및 안전하고 효율적으로 구성되는 각각의 임원입니다. TEF를 사용하여 고성능 트랜잭션 체계를 고성능과 통합 oracles는 oracle 확장 접근 방식의 핵심입니다. 3.5 멤풀 서비스 지원을 위해 DON에 배포하려는 중요한 애플리케이션 계층 기능 FSS와 TEF는 Mempool Services(MS)입니다. MS는 어댑터로 볼 수도 있지만, 그러나 최고 수준의 지원을 제공합니다. MS는 레거시 호환 트랜잭션 처리를 지원합니다. 이 용도에서는 MS 대상 계약을 위해 의도된 트랜잭션을 메인 체인의 멤풀에서 수집합니다. 메인체인의 SC. 그런 다음 MS는 이러한 트랜잭션을 DON의 실행 파일에 전달합니다. 원하는 방식으로 처리되는 곳입니다. MS 데이터는 DON에서 사용할 수 있습니다. DON에서 SC로 직접 전달될 수 있는 트랜잭션을 작성하거나 SC를 호출하는 다른 계약으로. 예를 들어 DON은 트랜잭션을 전달할 수 있습니다. MS를 통해 수집하거나 MS 데이터를 사용하여 보내는 거래에 대한 가스 가격을 설정할 수 있습니다. 메인체인. MS는 mempool을 모니터링하기 때문에 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에 대해 출력하는 보고서(증명된 보고서라고 함): 증명된 보고서의 중앙값 보고서는 두 정직한 노드가 보고한 값과 같거나 그 사이에 있습니다. 이 속성은 OCR의 주요 안전 조건입니다. 리더는 중앙값에 어느 정도 영향을 미칠 수 있습니다. 입증된 보고서의 가치는 이 정확성 조건에만 적용됩니다. OCR은 다양한 방식으로 값을 집계하는 메시지 유형으로 확장됩니다. Chainlink 네트워크의 활성 및 정확성 목표는 오늘날 필요하지 않지만 OCR이 완전한 합의 프로토콜이 되려면 기존 BFT 프로토콜에는 없는 몇 가지 추가 기능 형태를 제공하기 위해 OCR이 필요합니다. 특히 다음과 같습니다. 1. 전부 아니면 전무의 오프체인 보고서 방송: OCR은 증명된 보고서를 보장합니다. 모든 정직한 노드가 신속하게 사용할 수 있게 되거나 그 중 누구도 사용할 수 없게 됩니다. 이것이 공정성이다 정직한 노드가 참여할 기회를 갖도록 보장하는 재산 증명된 보고서 전송 시. 2. 안정적인 전송: OCR은 결함이 있거나 악의적인 경우에도 보장합니다. 모든 OCR 보고서와 메시지가 특정 내에서 SC로 전송되는 노드, 미리 정의된 시간 간격. 이는 활성 속성입니다. 3. 계약 기반 신뢰 최소화: SC는 잠재적으로 잘못된 OCR 생성 보고서를 필터링합니다(예: 보고된 값이 다른 값과 크게 벗어나는 경우). 최근에 받은 것. 이는 추가 프로토콜 정확성 적용의 한 형태입니다. 이 세 가지 속성은 모두 DONs에서 자연스러운 역할을 합니다. 전부 아니면 전무 오프체인(DON) 방송은 암호화폐 경제 보장을 위한 중요한 구성 요소입니다. 안정적인 전송을 중심으로 이는 결국 필수적인 어댑터 속성입니다. 신뢰 SC의 최소화는 섹션 7.3에서 논의된 바와 같이 일종의 가드레일입니다. OCR은 또한 Chainlink의 oracle 네트워크에서 BFT 프로토콜의 운영 배포 및 개선을 위한 기반을 제공합니다. DONs의 기능.3.6.2 DECO와 타운 크라이어 DECO [234] 및 Town Crier [233]은 현재 진행 중인 관련 기술 쌍입니다. Chainlink 네트워크에서 개발되었습니다. 오늘날 대부분의 웹 서버에서는 사용자가 프로토콜을 사용하여 보안 채널을 통해 연결할 수 있습니다. TLS(전송 계층 보안) [94]이라고 합니다. (HTTPS는 HTTP의 변형을 나타냅니다. TLS를 사용하여 활성화됩니다. 즉, "https" 접두사가 붙은 URL은 보안을 위해 TLS를 사용함을 나타냅니다.) 하지만 대부분의 TLS 지원 서버에는 눈에 띄는 제한 사항이 있습니다. 즉, 디지털 서명을 하지 않습니다. 데이터. 결과적으로, 사용자나 증명자는 서버로부터 받은 데이터를 제시할 수 없습니다. 다음을 보장하는 방식으로 oracle 또는 smart contract와 같은 제3자 또는 검증자에게 데이터의 신뢰성. 서버가 데이터에 디지털 서명을 하더라도 기밀성 문제가 남아 있습니다. 증명자는 중요한 데이터를 제출하기 전에 수정하거나 수정하기를 원할 수 있습니다. 검증자. 그러나 디지털 서명은 수정된 데이터를 무효화하기 위해 특별히 설계되었습니다. 따라서 증명자가 기밀성을 유지하면서 변경하는 것을 방지합니다. 데이터에. (자세한 내용은 섹션 7.1을 참조하세요.) DECO와 Town Crier는 증명자가 웹에서 데이터를 얻을 수 있도록 설계되었습니다. 무결성과 기밀성을 보장하는 방식으로 검증자에게 제공합니다. 두 시스템은 다음에 의해 제공되는 데이터를 보장한다는 의미에서 무결성을 유지합니다. 검증자에 대한 증명자는 대상 서버에서 인증됩니다. 그들은 지원한다 증명자가 데이터를 수정하거나 수정할 수 있도록 허용한다는 의미의 기밀성(여전히 무결성 유지). 두 시스템의 주요 특징은 어떤 수정도 필요하지 않다는 것입니다. 대상 웹 서버. 기존 TLS 지원 서버와 함께 작동할 수 있습니다. 사실, 서버에 투명합니다. 서버의 관점에서 증명자는 일반적인 연결을 설정합니다. 두 시스템은 비슷한 목표를 가지고 있지만 지금 간략하게 설명하는 것처럼 신뢰 모델과 구현이 다릅니다. DECO는 무결성을 달성하기 위해 암호화 프로토콜을 기본적으로 사용합니다. 및 기밀성 속성. DECO를 사용하여 대상 서버와 세션을 설정하는 동안 Prover는 동시에 대화형 프로토콜에 참여합니다. 검증자. 이 프로토콜을 통해 증명자는 검증자에게 수신했음을 증명할 수 있습니다. 현재 세션 동안 서버에서 주어진 데이터 D 조각. 증명자는 할 수 있다 대안으로 검증자에게 D의 일부 속성에 대한 영지식 증명을 제시합니다. 따라서 D를 직접적으로 공개하지 않습니다. DECO의 일반적인 사용에서 사용자 또는 단일 노드는 개인 데이터베이스에서 데이터 D를 내보낼 수 있습니다. DON의 모든 노드에 대한 웹 서버와의 세션. 결과적으로 전체 DON은(는) D의 진위(또는 영지식 증명을 통해 D에서 파생된 사실)를 증명합니다. 이 문서의 뒷부분에 나오는 예제 애플리케이션 외에도 이 기능을 사용할 수 있습니다. DON을 통해 데이터 소스에 대한 높은 무결성 액세스를 증폭하는 데 사용됩니다. 노드가 1개만 있어도 예를 들어 다음과의 독점 계약으로 인해 데이터 소스에 직접 액세스할 수 있습니다. 데이터 제공자—전체 DON가해당 노드에서 내보내는 보고서입니다. Town Crier는 Intel과 같은 TEE(신뢰할 수 있는 실행 환경)를 사용합니다. SGX. 간단히 말해서, TEE는 애플리케이션을 실행하는 일종의 블랙박스 역할을 합니다. 변조 방지 및 기밀 방식. 원칙적으로 해당 호스트의 소유자라도 실행 중인 TEE는 TEE로 보호되는 애플리케이션을 (감지 불가능하게) 변경할 수 없으며, 비밀 데이터가 포함될 수 있는 애플리케이션 상태를 봅니다. Town Crier는 DECO 등의 모든 기능을 구현할 수 있습니다. DECO는 증명자가 단일 검증자와 상호 작용하도록 제한합니다. 대조적으로, Town Crier는 다음을 가능하게 합니다. 대상 서버에서 가져온 데이터 D에 대해 공개적으로 검증 가능한 증거를 생성하는 증명자, 즉, smart contract이라도 누구나 직접 확인할 수 있는 증거입니다. 마을 외치는 사람은 할 수 있습니다 또한 보안 비밀(예: 사용자 자격 증명)을 안전하게 수집하고 활용합니다. Town Crier의 주요 제한 사항은 TEE에 대한 의존성입니다. 생산 TEE에는 기술은 초기 단계에 있으며 의심할 여지 없이 성숙해질 것이지만 최근에 여러 가지 심각한 취약점이 있는 것으로 나타났습니다. 자세한 내용은 부록 B.2.1 및 B.2.2를 참조하세요. TEE에 대한 추가 논의. DECO 및 Town Crier의 몇 가지 적용 예는 섹션 4.3, 4.5를 참조하세요. 9.4.3 및 부록 C.1. 3.6.3 기존 온체인 Chainlink 서비스 Chainlink oracle 네트워크는 다양한 분야에서 다양한 주요 서비스를 제공합니다. blockchains 및 오늘날의 기타 분산형 시스템. 설명 된대로 추가 진화 이 백서에서는 이러한 기존 서비스에 추가 기능을 부여하고 도달하다. 세 가지 예는 다음과 같습니다. 데이터 피드: 오늘날 smart contract에 의존하는 대부분의 Chainlink 사용자는 데이터 피드 사용. 이는 주요 데이터의 현재 가치에 대한 보고서입니다. 신뢰할 수 있는 오프체인 소스에. 예를 들어 가격 피드는 가격을 보고하는 피드입니다. 자산(암호화폐, 원자재, 외환, 지수, 주식 등)에 따라 교환 또는 데이터 수집 서비스. 오늘날 이러한 피드는 이미 수십억 달러의 보안을 확보하는 데 도움이 됩니다. Aave [147]와 같은 DeFi 시스템에서의 사용을 통한 온체인 가치의 달러 신세틱스 [208]. Chainlink 데이터 피드의 다른 예로는 다음의 날씨 데이터가 있습니다. 매개변수적 작물 보험 [75] 및 선거 데이터 [93] 등이 있습니다. 이 백서에 설명된 DON 및 기타 기술의 배포는 다음을 포함하여 여러 가지 방법으로 Chainlink 네트워크의 데이터 피드 제공을 향상시킵니다. • 확장: OCR 이후 DON은 Chainlink 서비스 확장을 목표로 합니다. 그들이 지원하는 많은 blockchain에 걸쳐 극적으로. 예를 들어, 우리는 DONs는 다음을 사용하여 노드에서 제공하는 데이터 피드 수를 늘리는 데 도움이 됩니다. Chainlink 100년대부터 1000년대 그리고 그 이상까지. 이러한 확장은 Chainlink에 도움이 될 것입니다. 생태계는 smart contracts와 관련된 데이터를 포괄적으로 제공하고 기존 및 미래의 요구 사항을 충족하고 예상한다는 목표를 달성합니다.• 보안 강화: 중간 보고서를 저장하면 DONs에서 기록을 유지합니다. 충실도가 높은 모니터링과 성능 및 정확성 측정을 위한 노드 동작을 통해 평판 시스템에 대한 강력한 경험적 기반을 제공합니다. Chainlink 노드의 경우. FSS와 TEF를 통해 가격 피드를 통합할 수 있습니다. 프론트 런(front-running)과 같은 공격을 방지하는 유연한 방식으로 거래 데이터를 사용합니다. (명시적) staking은 보안의 기존 암호경제적 보호를 강화합니다. 데이터 피드의 • 피드 민첩성: blockchain-agnostic 시스템(실제로 더 광범위하게는 소비자 독립적 시스템)으로서 DONs는 다양한 사용자에게 데이터 피드 제공을 용이하게 할 수 있습니다. 의존 시스템의. 단일 DON는 주어진 피드를 동시에 세트로 푸시할 수 있습니다. 다양한 blockchain을 사용하여 체인별 oracle 네트워크가 필요하지 않으며 새로운 blockchain에 대한 기존 피드와 추가 피드를 빠르게 배포할 수 있습니다. 현재 서비스되는 blockchain에 대한 피드입니다. • 기밀성: DON에서 일반화된 계산을 수행하는 기능을 통해 민감한 데이터에 대한 계산이 온체인을 피하고 오프체인에서 수행될 수 있습니다. 노출. 추가적으로 DECO나 Town Crier를 사용하면 기밀성이 더욱 강화되어 공개되지 않은 데이터를 기반으로 보고서를 생성할 수 있습니다. DON 노드에도 노출됩니다. 예시는 섹션 4.3 및 섹션 4.5를 참조하세요. 검증 가능한 무작위 함수(VRF): 여러 유형의 DApp에는 자체 공정한 운영을 검증할 수 있도록 검증 가능한 올바른 무작위성 소스가 필요합니다. 대체 불가능한 토큰(NFTs)이 그 예입니다. Aavegotchi [23] 및 Axie Infinity [35]의 NFT 기능의 희귀성은 Chainlink VRF에 의해 결정되며 분포도 마찬가지입니다. Ether 카드 [102]의 티켓 기반 추첨을 통해 NFTs; 다양한 결과가 무작위로 결정되는 게임 DApp 비전통적인 금융 수단(예: PoolTogether [89]과 같은 무손실 저축 게임) 무작위 우승자. 기타 blockchain 및 blockchain이 아닌 애플리케이션에도 보안이 필요합니다. 분산 시스템 위원회의 선택과 복권 실행. hashes 블록은 예측할 수 없는 무작위성의 소스 역할을 할 수 있지만, 적대적인 채굴자(및 어느 정도 제출한 사용자)의 조작에 취약합니다. 거래). Chainlink VRF [78]은 훨씬 더 안전한 대안을 제공합니다. 안 oracle에는 개인 키가 오프체인으로 유지되고 공개 키 pk가 게시되는 연결된 개인/공개 키 쌍(sk, pk)이 있습니다. 임의의 값을 출력하려면 의존 계약에 의해 제공되는 예측할 수 없는 시드 x에 sk를 적용합니다(예: hash 블록) 및 DApp별 매개변수) 함수 F를 사용하여 y = Fsk(x)를 산출합니다. 정확성의 증거. (Chainlink에서 사용할 수 있는 VRF는 [180]을 참조하세요.) VRF 검증 가능은 pk에 대한 지식을 바탕으로 증명의 정확성, 즉 y의 정확성을 확인할 수 있다는 사실입니다. 결과적으로 y 값은 예측할 수 없습니다. x를 예측하거나 sk를 학습할 수 없고 서비스가 조작할 수 없는 적입니다.Chainlink VRF는 오프체인 개인 키의 관리와 관련된 애플리케이션 제품군 중 하나로 볼 수 있습니다. 보다 일반적으로 DONs는 보안을 제공할 수 있습니다. 애플리케이션 및/또는 사용자를 위한 개별 키의 분산형 저장 및 결합 일반화된 계산을 통해 이 기능을 사용할 수 있습니다. 그 결과 수많은 응용 프로그램이 탄생했습니다. 이 문서에서는 Proof of Key 관리를 포함하여 몇 가지 예를 제공합니다. 예비금(섹션 4.1 참조) 및 사용자의 분산 자격 증명(및 기타 디지털 자산)(섹션 4.3 참조). 키퍼: Chainlink 키퍼 [87]는 개발자가 분산형 코드를 작성할 수 있도록 해줍니다. 일반적으로 의존하는 smart contract의 실행을 트리거하기 위한 오프체인 작업 실행. Keeper가 등장하기 전에는 개발자가 이러한 오프체인을 운영하는 것이 일반적이었습니다. 논리 자체가 중앙 집중화된 실패 지점을 생성합니다(상당한 중복 개발 노력도 포함). 대신 Keeper는 사용하기 쉬운 프레임워크를 제공합니다. 이러한 작업을 분산 아웃소싱하여 개발 주기를 단축하고 활성 및 기타 보안 속성에 대한 강력한 보증. 키퍼는 무엇이든 지원할 수 있습니다 가격에 따른 대출 청산 또는 금융 거래 실행, 시간에 따른 에어드롭 또는 결제 시작 수확량 수확 등을 갖춘 시스템에서. DON 프레임워크에서 개시자는 여러 의미에서 Keeper의 일반화로 볼 수 있습니다. 개시자는 어댑터를 사용할 수 있으므로 온체인 및 오프체인 시스템에 대한 모듈화된 인터페이스 라이브러리를 통해 신속한 안전하고 정교한 기능 개발. 개시자는 다음에서 계산을 시작합니다. DONs의 완전한 다양성을 제공하는 실행 파일입니다. 온체인 및 오프체인 애플리케이션을 위해 이 백서에서 제시하는 다양한 분산형 서비스입니다. 3.6.4 노드 평판 / 성능 내역 기존 Chainlink 생태계는 기본적으로 다음의 성능 기록을 문서화합니다. 체인에 노드를 기여합니다. 이 기능을 통해 개인에 대한 성과 데이터를 수집, 필터링 및 시각화하는 평판 지향 리소스 모음이 탄생했습니다. 노드 운영자 및 데이터 피드. 사용자는 이러한 리소스를 참조하여 정보를 얻을 수 있습니다. 노드 선택에 대한 결정을 내리고 기존 네트워크의 작동을 모니터링합니다. 유사한 기능은 사용자가 DON을 선택하는 데 도움이 됩니다. 예를 들어 오늘날 market.link와 같은 무허가 마켓플레이스는 노드를 허용합니다. 운영자는 자신의 oracle 서비스를 나열하고 다음을 통해 오프체인 신원을 증명합니다. Chainlink에 있는 노드의 프로필을 해당 노드에 바인딩하는 Keybase [4]와 같은 서비스 소유자의 기존 도메인 이름 및 소셜 미디어 계정. 추가적으로 성능 market.link 및 Reputation.link에서 제공되는 것과 같은 분석 도구를 사용하면 사용자는 다음을 포함하여 개별 노드의 과거 성능에 대한 통계를 볼 수 있습니다. 평균 응답 대기 시간, 보고서 값과 합의 값의 편차 체인을 통해 중계되고, 수익이 창출되고, 작업이 완료되는 등의 일이 발생합니다. 이러한 분석 도구는 또한 사용자는 다른 사용자의 다양한 oracle 네트워크 채택을 추적할 수 있습니다.그러한 네트워크를 보호하는 노드에 대한 암묵적인 보증. 그 결과는 평평한 "웹"입니다. 특정 노드를 사용하여 고부가가치 분산 애플리케이션을 생성하는 신뢰” 다른 사용자가 관찰하고 고려할 수 있는 노드에 대한 신뢰의 신호입니다. 자신의 노드 선택 결정. DONs(및 처음에는 OCR 사용)를 사용하면 트랜잭션 처리 및 계약 활동은 더 일반적으로 오프체인입니다. 기록 노드를 위한 분산형 모델 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 を使用して簡単に構築できる便利な新しいサービスです。彼らの
目標は、厳選された優先度の高いトランザクションをメインチェーン上でタイムリーに配信することです ネットワークが混雑しているとき。優先チャネルは、次のような形式と見なすことができます。 ブロック空間上の先物契約、したがって暗号商品としての一部として造られた用語 プロジェクト・シカゴ [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] を参照してください。
Decentralized가 구현하는 분산형 서비스
오라클 네트웍스 DON의 다양성과 이를 통해 다양한 새로운 서비스를 활성화하는 방법을 설명하기 위해, 이 섹션에서는 DON 기반 애플리케이션의 다섯 가지 예를 제시하고 이를 실현하는 하이브리드 계약: (1) 크로스체인 서비스의 한 형태인 보유량 증명; (2) 기업/레거시 시스템과의 인터페이스, 즉 미들웨어 기반의 구축 최소한의 비용으로 blockchain 애플리케이션 개발을 용이하게 하는 추상화 계층 blockchain-특정 코드 또는 전문 지식; (3) 분산형 ID, 사용자가 다음을 수행할 수 있는 도구 자신의 신분 증명서와 자격 증명을 획득하고 관리합니다. (4) 우선순위 채널, 중요한 인프라 트랜잭션을 적시에 포함하도록 보장하는 서비스(예: oracle 보고서) blockchain; (5) 기밀 유지 DeFi, 즉 금융 참여 당사자의 민감한 데이터를 숨기는 smart contracts. 여기서 우리는
SC를 사용하여 하이브리드 계약의 MAINCHAIN 부분을 나타내고 DON을 설명합니다. 구성 요소를 별도로 또는 실행 가능한 exec 측면에서 사용합니다. 4.1 예비금 증명 많은 애플리케이션의 경우 blockchain 사이에서 상태를 중계하는 것이 유용합니다. 에이 이러한 서비스의 인기 있는 응용 프로그램은 암호화폐 래핑입니다. 포장된 동전 등 WBTC [15]은 분산 금융(DeFi)에서 인기 있는 자산이 되고 있습니다. 그들은 소스 blockchain MAINCHAIN(1)에 "래핑된" 지원 자산을 예치하는 것이 포함됩니다. 다른 대상 blockchain MAINCHAIN(2)에 해당 token을 생성합니다. 예를 들어, WBTC는 해당하는 Ethereum blockchain의 ERC20 token입니다. Bitcoin blockchain에서 BTC로. MAINCHAIN(2)에 대한 계약은 MAINCHAIN(1)에 대한 직접적인 가시성을 가지지 않기 때문에, 그들은 포장된 예금에 대해 보고하기 위해 명시적으로 또는 암시적으로 oracle에 의존해야 합니다. smart contract의 자산으로 적립금 증명이라고도 불리는 것을 생성합니다. 에서 WBTC [15], 예를 들어 관리인 BitGo는 BTC를 보유하고 WBTC를 발행합니다. Chainlink 예약금 증명을 제공하는 네트워크 [76]. DON 자체가 보유량 증명을 제공할 수 있습니다. 그러나 DON을 사용하면 가능합니다. 더 나아가려고. DON은 적절한 어댑터를 사용하여 비밀을 관리할 수 있습니다. 원하는 blockchain에서 거래할 수 있습니다. 결과적으로 DON가 작동하는 것이 가능합니다. 여러 관리인 중 한 명으로서, 심지어는 유일한 분산형 관리인으로서 래핑된 자산. DONs는 보안을 강화하는 플랫폼 역할을 할 수 있습니다. 보유금 증명을 사용하는 기존 서비스. 예를 들어 MAINCHAIN(1)이 Bitcoin이고 MAINCHAIN(2)이 Ethereum이라고 가정합니다. MAINCHAIN(2)에서 계약 SC는 래핑된 BTC를 나타내는 token을 발행합니다. DON BTC 주소 주소를 제어합니다(1) DON. BTC를 래핑하기 위해 사용자 U는 다음에서 X BTC를 보냅니다. 주소(1) 유 추가하기(1) DON MAINCHAIN(2)-주소 주소(2)와 함께 유. DON 모니터 주소(1) DON MAINCHAIN(1)에 대한 어댑터를 통해. U의 예금을 관찰하면 충분히 높은 확률로 확인된 후 어댑터를 통해 SC로 메시지를 보냅니다. 메인체인(2). 이 메시지는 SC에게 addr(2)에 대해 X tokens를 생성하도록 지시합니다. 유. U가 X tokens를 해제하려면 그 반대가 발생합니다. 그러나 MAINCHAIN(1)에서는 주소(1) DON는 X BTC를 addr(1)로 보냅니다. U(또는 사용자가 요청한 경우 다른 주소로). 물론 이러한 프로토콜은 직접적으로 작동하기보다는 교환과 함께 작동하도록 조정될 수 있습니다. 사용자와 함께. 4.2 엔터프라이즈/레거시 시스템과의 인터페이스 DON은 증명의 예에서와 같이 blockchain 사이에서 브리지 역할을 할 수 있습니다. 하지만 또 다른 목표는 예비군 사이의 양방향 다리 역할을 하는 것입니다. blockchains 및 레거시 시스템 [176] 또는 중앙 은행과 같은 blockchain 유사 시스템 디지털 통화 [30]. 기업은 기존 시스템과 시스템을 연결하는 데 있어 여러 가지 과제에 직면해 있습니다. 다음을 포함하는 분산형 시스템에 대한 프로세스:• 블록체인 민첩성: 블록체인 시스템은 빠르게 변화합니다. 기업은 blockchain의 급속한 새로운 등장이나 인기 상승에 직면할 수 있습니다. 상대방이 거래를 원하지만 기업이 이를 수행할 수 없는 경우 기존 인프라를 지원합니다. 일반적으로 blockchains의 역동성은 개별 기업이 전체 생태계를 따라가는 것은 어렵습니다. • 블록체인 관련 개발 리소스: 많은 조직의 경우, 특히 다음과 같은 관점에서 최첨단 blockchain 전문 지식을 고용하거나 육성하는 것이 어렵습니다. 민첩성에 도전합니다. • 개인 키 관리: blockchains 또는 암호화폐에 대한 개인 키를 관리하려면 기존 사이버 보안과 다른 운영 전문 지식이 필요합니다. 많은 기업에서는 사용할 수 없습니다. • 기밀성: 기업은 자신의 민감하고 독점적인 정보를 노출하는 것을 꺼립니다. 체인의 데이터. 이러한 어려움 중 처음 세 가지를 해결하기 위해 개발자는 DON를 사용하면 됩니다. 엔터프라이즈 시스템에서 읽거나 쓸 수 있도록 하는 보안 미들웨어 계층 blockchains. DON는 다음과 같은 자세한 기술적 고려 사항을 추상화할 수 있습니다. 개발자와 사용자 모두를 위한 가스 역학, 체인 재구성 등. 작성자: 엔터프라이즈 시스템에 간소화된 blockchain 인터페이스를 제공함으로써 DON은(는) 다음을 수행할 수 있습니다. blockchain 인식 엔터프라이즈 애플리케이션의 개발을 상당히 단순화하여 기업이 blockchain 특정 개발 리소스를 획득하거나 육성해야 하는 부담을 제거합니다. DONs의 이러한 사용은 엔터프라이즈 개발자가 다음을 수행할 수 있다는 점에서 특히 매력적입니다. 대체로 blockchain 불가지론적인 스마트 계약 애플리케이션을 만듭니다. 그 결과, DON이 미들웨어 역할을 하도록 계측된 blockchain 세트가 더 크면 기업 사용자가 쉽게 액세스할 수 있는 blockchain 세트가 더 커졌습니다. 개발자 최소한의 수정만으로 기존 blockchain의 애플리케이션을 새로운 애플리케이션으로 포팅할 수 있습니다. 내부적으로 개발된 애플리케이션에 적용됩니다. 추가적인 기밀성 문제를 해결하기 위해 개발자는 이 문서에서 소개하고 DON 애플리케이션을 지원하기 위해 배포할 예정인 도구입니다. 여기에는 DECO 및 Town Crier 섹션 3.6.2와 기밀 유지가 포함됩니다. 섹션 7.1.2에서 논의된 API 수정과 이 섹션의 나머지 부분에서 다루는 다양한 애플리케이션별 접근 방식. 이 DON 시스템은 다음을 제공할 수 있습니다. 공개하지 않고 엔터프라이즈 시스템 상태에 대한 높은 무결성, 온체인 증명 체인에 있는 민감한 기업 소스 데이터. 4.3 분산형 신원 분산형 ID는 사용자가 다음을 수행할 수 있어야 한다는 개념에 대한 일반적인 용어입니다. 제3자에게 의존하기보다는 자신의 자격 증명을 획득하고 관리합니다. 그래서. 분산형 자격 증명은 보유자의 속성이나 주장에 대한 증명입니다.흔히 클레임이라고 불리는 것입니다. 자격 증명은 엔터티에 의해 디지털 서명됩니다. 클레임을 사용자와 정식으로 연결할 수 있는 발급자입니다. 대부분의 제안된 계획에서는 클레임은 범용 식별자인 분산 식별자(DID)와 연결됩니다. 특정 사용자. 자격 증명은 사용자가 보유한 개인 키의 공개 키에 바인딩됩니다. 따라서 사용자는 개인 키를 사용하여 소유권 주장을 증명할 수 있습니다. 분산형 신원으로서의 비전은 기존 및 제안된 계획입니다(예: [14, 92, 129, 216]에는 세 가지 심각한 제한이 있습니다. • 레거시 호환성 부족: 기존 분산형 ID 시스템은 발급자라고 불리는 당국 커뮤니티가 DID 자격 증명을 생성합니다. 왜냐하면 기존 웹 서비스는 일반적으로 데이터에 디지털 서명을 하지 않으므로 발급자가 시작되어야 합니다. 특수 목적 시스템으로. 왜냐하면 아무런 인센티브도 없이는 이 일을 할 동기가 없기 때문입니다. 탈중앙화된 신원 생태계에서는 닭과 달걀의 문제가 발생합니다. 다른 곳에서는 즉, 발급자 생태계를 부트스트랩하는 방법이 불분명합니다. • 작동하지 않는 키 관리: 분산형 ID 시스템에서는 사용자가 다음을 수행해야 합니다. 개인 키 관리, 암호화폐 경험을 통해 알 수 있는 사실 실행 불가능한 부담이 되는 것입니다. 약 4,000,000 Bitcoin이(가) 발생한 것으로 추산됩니다. 키 관리 실패로 인해 영구적으로 손실되었으며 [194] 많은 사용자가 [193] 거래소의 암호화폐 자산으로 인해 분산화가 약화됩니다. • 개인 정보 보호 Sybil 저항 부족: 투표, token 판매 중 token의 공정한 할당 등과 같은 애플리케이션의 기본 보안 요구 사항은 다음과 같습니다. 사용자는 여러 ID를 주장할 수 없습니다. 기존의 분산형 신원 제안에서는 사용자가 이를 달성하기 위해 실제 신원을 공개해야 합니다. Sybil 저항으로 인해 중요한 개인 정보 보호 보장이 약화됩니다. 노드 위원회의 조합을 사용하여 이러한 문제를 해결하는 것이 가능합니다. DON 내에서 분산 계산을 수행하고 DECO와 같은 도구를 사용합니다. 또는 CanDID [160]이라는 시스템에 표시된 것처럼 Town Crier입니다. DECO 또는 Town Crier는 설계에 따라 수정 없이 기존 웹 서비스를 전환할 수 있습니다. 기밀 유지 자격 증명 발급자로 변경됩니다. DON을 사용하여 관련 항목을 내보낼 수 있습니다. 이러한 목적으로 데이터를 자격 증명으로 변환하고, 민감한 데이터를 숨겨서는 안 됩니다. 자격 증명에 나타납니다. 또한 사용자의 키 복구를 용이하게 하여 키 관리 문제를 해결합니다. 문제가 발생하면 DON을 사용하면 사용자가 개인 키를 비밀 공유 형식으로 저장할 수 있습니다. 사용자는 다음을 수행할 수 있습니다. DON의 노드에 증명하여 키를 복구합니다. 마찬가지로 Town Crier를 사용하거나 DECO—미리 결정된 웹 제공업체 집합의 계정에 로그인하는 기능(예: 트위터, 구글, 페이스북). Town Crier 또는 DECO를 사용하는 것의 이점은 다음과 같습니다. OAUTH는 사용자 개인정보 보호입니다. 이 두 도구를 사용하면 사용자가 DON에 공개되는 것을 피할 수 있습니다. 실제 신원을 파생할 수 있는 웹 제공자 식별자. 마지막으로 [160]에 표시된 것처럼 Sybil 저항을 제공하려면 DON이 다음을 수행할 수 있습니다. 사용자를 위한 고유한 실제 식별자의 개인 정보 보호 변환을 수행합니다. (예: 사회보장번호(SSN))를 사용자 등록 시 온체인 식별자로 변환합니다.이를 통해 시스템은 다음과 같은 민감한 데이터 없이 중복 등록을 감지할 수 있습니다. SSN은 개별 DON 노드에 공개됩니다.7 DON은 외부 분산 ID를 대신하여 이러한 서비스를 제공할 수 있습니다. 허가가 없거나 허가된 blockchain의 시스템(예: Hyperledger 인스턴스) 인디 [129]. 적용 예: KYC: 분산형 신원은 다음을 위한 수단으로 유망합니다. 사용자를 개선하는 동시에 blockchains의 금융 애플리케이션에 대한 요구 사항을 간소화합니다. 프라이버시. 해결하는 데 도움이 될 수 있는 두 가지 과제는 자금 세탁 방지/고객 파악(AML/KYC) 규정에 따른 인증 및 규정 준수 의무입니다. 많은 국가의 AML 규정에 따라 금융 기관(및 기타 기업)은 거래하는 개인 및 기업의 신원을 확인하고 확인해야 합니다. 그들은 거래를 수행합니다. KYC는 금융 기관의 한 구성 요소를 형성합니다. 일반적으로 사용자 행동을 모니터링하고 자금 흐름을 관찰하는 등 광범위한 AML 정책이 포함됩니다. KYC에는 일반적으로 사용자에게 어떤 형태로든 신원 자격 증명을 제시하는 과정이 포함됩니다(예: 사용자의 얼굴 앞에 신분증을 들고 온라인 웹 양식에 입력 비디오 세션 등). 분산형 자격 증명의 안전한 생성 및 제시 원칙적으로 다음과 같은 여러 측면에서 유익한 대안이 될 수 있습니다. (1) KYC 프로세스는 사용자와 금융 기관 모두에게 더 효율적입니다. 자격 증명을 취득하면 모든 금융 기관에 원활하게 제시될 수 있습니다. (2) 타협을 통한 신원 도용 기회를 줄여 사기를 줄입니다. 개인 식별 정보(PII) 및 영상 확인 중 스푸핑 그리고 (3) 사용자가 통제권을 유지함에 따라 금융 기관의 PII 손상 위험을 줄입니다. 자신의 데이터. AML 규정 준수 실패로 인해 금융 기관이 수십억 달러의 벌금을 지불하고 많은 금융 기관이 KYC에 매년 수백만 달러를 지출한다는 점을 고려하면 개선을 통해 금융 기관에 상당한 비용 절감 효과를 가져올 수 있습니다. 그리고 더 나아가 소비자를 위한 [196]. 전통적인 금융 부문은 부진하지만 새로운 규정 준수 도구를 채택하기 위해 DeFi 시스템에서는 이를 점점 더 많이 수용하고 있습니다 [43]. 적용 예: 과소담보 대출: 대부분의 DeFi 애플리케이션은 오늘날 지원 대출은 완전 담보 대출로만 이루어집니다. 대출을 받은 것들이에요 대출금을 초과하는 가치의 암호화폐 자산을 예치하는 차용자. 최근 DeFi 커뮤니티에서 일반적으로 과소담보 대출이라고 부르는 것에 대한 관심이 높아졌습니다. 이와 대조적으로 이는 해당 담보가 제공되는 대출입니다. 대출 원금보다 가치가 낮은 경우. 과소담보 대출 전통적인 금융 기관에서 흔히 제공하는 대출과 유사합니다. 의지하기보다는 대출 상환을 보장하기 위해 예치된 담보를 기반으로 대출을 제공합니다. 차용인의 신용 기록에 대한 결정. 7이 변환은 분산 의사 난수 함수(PRF)를 사용합니다.담보가 부족한 대출은 DeFi 대출 시장의 초기 단계이지만 성장하고 있는 부분을 구성합니다. 그들은 전통적인 금융 기관에서 사용하는 것과 같은 메커니즘에 의존합니다. 법적 계약과 같은 기관 [91]. 성장을 위한 필수 요구 사항 기존 대출 결정의 핵심 요소인 사용자 신용도에 대한 데이터를 강력한 무결성을 제공하는 방식으로 시스템에 제공할 수 있는 능력이 될 것입니다. 올바른 데이터 보장. DON 지원 분산형 신원 시스템을 통해 차용자가 될 수 있습니다. 보존하면서 신용도를 증명하는 높은 보증 자격 증명을 생성합니다. 민감한 정보의 기밀성. 특히 차용인은 다음을 생성할 수 있습니다. 신뢰할 수 있는 온라인 소스의 기록을 기반으로 한 자격 증명만 노출합니다. 잠재적으로 민감한 다른 데이터를 노출하지 않고 DON에 의해 증명된 데이터입니다. 에 대한 예를 들어, 차용인은 자신의 신용 점수를 나타내는 자격 증명을 생성할 수 있습니다. 일련의 신용 조사 기관이 자신을 공개하지 않고 특정 기준점(예: 750)을 초과합니다. 정확한 점수 또는 그녀의 기록에 있는 기타 데이터. 또한 원하는 경우 해당 자격 증명 익명으로 생성될 수 있습니다. 즉, 사용자 이름이 민감한 데이터로 취급될 수 있습니다. oracle 노드나 분산 자격 증명에 노출되지 않습니다. 자격 증명 애플리케이션에 따라 온체인 또는 오프체인으로 사용될 수 있습니다. 요약하자면, 차용인은 자신의 신용에 대해 대출 기관에 필수 정보를 제공할 수 있습니다. 강력하고 진실성이 있고 불필요하고 민감한 정보가 노출될 위험이 없는 역사 데이터. 차용인은 기타 다양한 기밀 유지 자격 증명을 제공할 수도 있습니다. 대출 결정에 도움이 됩니다. 예를 들어 자격 증명은 차용인의 다음 예에서 볼 수 있듯이 (오프체인) 자산을 소유합니다. 적용 예: 인증: 많은 관할권에서는 미등록 증권을 판매할 수 있는 투자자 등급을 제한합니다. 예를 들어 미국의 경우 SEC 규정 D는 그러한 투자 기회에 대해 인증을 받도록 규정하고 있습니다. 개인은 100만 달러의 순자산을 보유해야 하고, 특정 최소 소득 요건을 충족하거나 특정 전문 자격을 갖추어야 합니다[209, 210]. 현재 인증 프로세스가 번거롭고 비효율적이며 종종 증명서가 필요합니다. 회계사 또는 이와 유사한 증거. 분산형 신원 시스템을 통해 사용자는 다음에서 자격 증명을 생성할 수 있습니다. 인증 준수를 입증하는 기존 온라인 금융 서비스 계정 규정을 준수하여 보다 효율적이고 개인 정보를 보호하는 KYC 프로세스를 촉진합니다. 는 또한 DECO와 Town Crier의 개인 정보 보호 속성을 통해 다음이 가능해집니다. 사용자의 재정 상태에 대한 세부 정보를 직접 공개하지 않고 무결성을 강력하게 보장하여 자격 증명을 생성합니다. 예를 들어, 사용자는 자격 증명을 생성할 수 있습니다. 추가 정보를 공개하지 않고 그녀의 순자산이 최소 100만 달러임을 증명합니다. 그녀의 재정 상태에 대한 정보. 4.4 우선순위 채널 우선순위 채널은 DON을 사용하여 쉽게 구축할 수 있는 유용한 새 서비스입니다. 그들의
목표는 MAINCHAIN에서 적시에 선택되고 우선순위가 높은 거래를 제공하는 것입니다. 네트워크 정체 기간 동안. 우선순위 채널은 다음과 같은 형태로 볼 수 있습니다. 블록 공간에 대한 선물 계약 및 암호화폐 상품으로서 일부로 만들어진 용어입니다. 프로젝트 시카고 [61, 136]. 우선순위 채널은 특히 금융 거래와 같은 일반적인 사용자 수준 활동이 아닌 채굴자가 oracles, 계약에 대한 거버넌스 기능 등과 같은 인프라 서비스를 활성화할 수 있도록 고안되었습니다. 실제로 여기에서 설계된 대로 우선순위는 네트워크 내 채굴력의 100% 미만으로 구현된 채널은 오직 배송 시간에 대한 느슨한 경계를 제공하여 속도 의존도가 높은 용도로 사용하는 것을 방지합니다. 선두 달리기와 같은 목표. 그림 10: 우선순위 채널은 채굴자 M, 또는 더 일반적으로는 채굴자 M 세트 - 사용자 U에게 그녀의 거래 τ가 D 블록 내에서 채굴될 것임을 알립니다. mempool에 포함됩니다. 계약 SC는 DON 모니터링을 사용하여 채널의 서비스 약관. 우선순위 채널은 광부 또는 광부 그룹 간의 합의 형태를 취합니다. (또는 마이닝 풀) 채널을 제공하는 M과 접속에 대한 수수료를 지불하는 사용자 U입니다. M은 U가 트랜잭션 τ를 멤풀에 제출할 때(가스 가격에 상관없이,그러나 사전 합의된 가스 한도), M은 이를 다음 D 블록 내의 체인에 배치합니다.8 이 아이디어는 그림 10에 개략적으로 설명되어 있습니다. 우선 채널 계약 설명: 우선순위 채널은 다음과 같이 구현될 수 있습니다. 하이브리드 smart contract 대략 다음과 같습니다. SC는 MAINCHAIN의 로직을 나타냅니다. 그리고 그것은 exec의 DON에 있습니다. SC는 U.A로부터 예금/스테이크 \(d from M and an advance payment \)p를 수락합니다. DON 실행 가능한 exec는 mempool을 모니터링하여 트랜잭션 배치 시 트리거됩니다. M이 채굴한 거래를 U가 제출하면 SC에 성공 메시지를 보냅니다. 시기적절한 방법과 서비스 장애 발생 시 장애 메시지를 제공합니다. SC는 성공 메시지를 받고 M에게 $p 지불금을 보내고 남은 자금을 모두 보냅니다. 실패 메시지를 받으면 $d를 포함하여 U로 보냅니다. 성공적으로 종료되면 M에게 예금 $d를 해제합니다. 채굴자 M은 물론 여러 사용자에게 우선순위 채널을 동시에 제공할 수 있습니다. 사용자는 미리 합의된 수의 메시지에 대해 U를 사용하여 우선순위 채널을 열 수 있습니다. 4.5 기밀 유지 DeFi / Mixicles 오늘날 DeFi 애플리케이션 [1]은 사용자에게 기밀성을 거의 또는 전혀 제공하지 않습니다. 모든 거래는 체인에서 볼 수 있습니다. 다양한 영지식 기반 접근 방식(예: [149, 217]), 거래 프라이버시를 제공할 수 있으며 TEF는 이를 지원할 만큼 충분히 일반적입니다. 하지만 이러한 접근 방식은 포괄적이지 않으며, 예를 들어 일반적으로 다음 사항을 숨기지 않습니다. 거래의 기반이 되는 자산. DONs에서 궁극적으로 지원하려는 광범위한 계산 도구 세트는 이러한 격차를 메울 수 있는 다양한 방법으로 개인 정보 보호를 활성화하여 다른 시스템의 개인 정보 보호 보장을 보완합니다. 예를 들어, Chainlink 연구소 연구원 [135]이 제안한 기밀 유지 DeFi 도구인 Mixicles는 금융 상품을 뒷받침하는 자산 유형이며 DON에 매우 자연스럽게 들어맞습니다. 프레임워크. Mixicle은 간단한 바이너리를 구현하는 용도로 가장 쉽게 설명됩니다. 옵션. 바이너리 옵션은 두 명의 사용자가 참여하는 금융 상품입니다. 플레이어로서 [135]과의 일관성을 위해 여기를 참조하십시오. 가능한 두 가지 이벤트에 베팅하세요. 결과(예: 자산이 미리 지정된 시간에 목표 가격을 초과하는지 여부) 다음 예에서는 아이디어를 보여줍니다. 예시 2. Alice와 Bob은 자산 가치를 기반으로 한 바이너리 옵션의 당사자입니다. 캐롤의 버블 토큰(CBT)이라고 합니다. Alice는 CBT의 시장 가격이 다음과 같을 것이라고 베팅했습니다. 2025년 6월 21일 정오 T 시간에 최소 250 USD; Bob은 그 반대로 베팅했습니다. 각 플레이어 미리 지정된 기한까지 100 ETH를 입금합니다. 승리하는 위치에 있는 플레이어 200 ETH를 받습니다(즉, 100 ETH를 얻습니다). 물론 8D는 M이 높은 확률을 준수할 수 있을 만큼 충분히 커야 합니다. 에 대한 예를 들어 M이 네트워크 마이닝 파워의 20%를 제어하는 경우 D = 100을 선택할 수 있습니다. 실패 확률은 2 × 10−10, 즉 10억분의 1 미만입니다.기존 Chainlink oracle 네트워크 O를 고려하면 스마트한 구현이 쉽습니다. 예시 2의 합의를 실현한 SC 계약. 두 플레이어가 각각 예치 SC에서는 100 ETH. T 이후에, 가격 r을 요청하는 쿼리 q가 O로 전송됩니다. T.O 시점의 CBT는 이 가격에 대한 보고서 r을 SC에 보냅니다. SC는 Alice에게 돈을 보냅니다. r ≥250이면 Bob이고, 그렇지 않으면 Bob입니다. 그러나 이 접근법은 체인상의 r을 드러냅니다. 관찰자가 바이너리 옵션의 기본 자산을 추론할 수 있도록 합니다. Mixicles라는 용어에서는 결과를 개념적으로 생각하는 것이 도움이 됩니다. 조건자로 계산된 이진 값을 전송하는 스위치 측면에서 SC의 스위치(r). 이 예에서는 r ≥250이면 switch(r) = 0입니다. 이 결과가 주어지면 Alice가 승리합니다. 그렇지 않으면 switch(r) = 1이고 Bob이 승리합니다. DON은 실행 파일을 실행하여 기본 Mixicle을 하이브리드 계약으로 실현할 수 있습니다. 스위치(r)를 계산하고 이를 SC에 체인으로 보고하는 exec입니다. 이 구조를 보여드리겠습니다 그림 11에서. 그림 11: 예제 2의 기본 Mixicle 다이어그램. r을 보고하고 바이너리 옵션의 기본 자산인 oracle은 이진 값 스위치(r)만 전환하여 SC를 계약합니다. 이를 쉽게 달성할 수 있도록 부록 C.3에 어댑터 ConfSwitch를 지정합니다. DON의 목표입니다. ConfSwitch의 기본 아이디어는 매우 간단합니다. 신고하는 대신 r 값, ConfSwitch는 바이너리 스위치 값 switch(r)만 보고합니다. SC는 가능하다 스위치(r)만 기반으로 정확한 결제를 하고 스위치(r) 자체는 올바르게 결제하도록 설계되었습니다. 기본 자산(이 예에서는 CBT)에 대한 정보를 공개하지 않습니다. 추가적으로, 공개 키인 pkaud로 암호화된 원장의 (q, r)에 암호문을 배치하여 감사자인 어댑터 ConfSwitch는 기밀성을 유지하는 감사 추적을 생성합니다. 여기서 설명하기 위해 단순화를 위해 선택한 기본 Mixicle은 우리 예에서는 바이너리 옵션 뒤에 자산과 베팅이 있습니다. 본격적인 Mixicle [135]은(는) 두 가지 형태의 기밀성을 제공합니다. (1) 어떤 사건이 관찰자에게 숨겨지나요? 플레이어는 (즉, q와 r)에 베팅할 뿐만 아니라 (2) 어느 플레이어가 베팅에서 승리했는지에도 베팅합니다. Mixicles는 MAINCHAIN에서 실행되므로 한 플레이어 중 한 명이 릴레이해야 합니다. DON에서 MAINCHAIN으로 전환(r)하거나 실행 가능한 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 ネットワーク以来
が分散されている場合、そのような順序は捕捉できません。したがって、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(Fair Sequencing Services)입니다. FSS는 단순히 DON 프레임워크 내에서 구현된 애플리케이션으로 볼 수 있지만, 우리는 이를 전 세계적으로 높은 수요가 있을 것으로 믿는 서비스로 강조합니다. blockchains이며 Chainlink 네트워크가 이를 적극적으로 지원할 것으로 기대합니다. 공용 blockchain 네트워크에서 실행되면 오늘날의 많은 DeFi 애플리케이션이 사용자가 자신의 이익을 위해 활용할 수 있는 정보를 공개합니다. 기존 시스템에 만연해 있는 일종의 내부 정보 유출 및 조작 기회 시장 [64, 155]. 대신 FSS는 공정한 DeFi 생태계를 향한 길을 열어줍니다. FSS 개발자가 시장 조작으로부터 보호되는 DeFi 계약을 구축하는 데 도움이 됩니다. 정보 유출로 인해 발생합니다. 아래에서 강조하는 문제를 고려하면 FSS는 레이어 2 서비스에 특히 매력적이며 그러한 서비스의 프레임워크 내에 적합합니다. 이에 대해서는 섹션 6에서 논의합니다. 과제: 기존 무허가 시스템에서는 트랜잭션이 전적으로 주문됩니다. 광부의 재량에 따라. 허가된 네트워크에서는 validator 노드가 같은 힘. 이는 대체로 인식되지 않는 임시 중앙 집중화의 한 형태입니다. 그렇지 않으면 분산 시스템. 채굴자는 거래를 (일시적으로) 검열할 수 있습니다. 자신의 이익을 [171]하거나 자신의 이익을 극대화하기 위해 순서를 변경합니다. 이를 광산 추출 가능 가치(MEV) [90]이라고 합니다. MEV라는 용어는 약간 기만적입니다. 채굴자가 포착할 수 있는 가치에만 적용: 일부 MEV는 일반 사용자가 포착할 수 있습니다. 그러나 채굴자는 일반 사용자보다 더 많은 권한을 갖기 때문에 MEV는 모든 개체가 적대적 재정렬을 통해 얻을 수 있는 가치의 상한선을 나타냅니다. 그리고 보완적인 거래 삽입. 채굴자가 단순히 거래를 주문하는 경우에도 수수료(가스)를 기준으로 조작 없이 사용자가 직접 가스 가격을 조작할 수 있습니다. 덜 정교한 거래에 비해 거래를 유리하게 만듭니다. Daianet al. [90] 봇(채굴자가 아님)이 가져오는 방식을 문서화하고 수량화합니다. 오늘날 DeFi 시스템 사용자에게 해를 끼치는 방식으로 가스 역학의 이점과 방법 MEV는 심지어 blockchain의 기본 합의 계층의 안정성을 위협합니다. 거래 주문 조작의 다른 예는 [50, 154]와 같이 정기적으로 나타납니다.rollups와 같은 새로운 트랜잭션 처리 방법은 매우 유망한 접근 방식입니다. 처리량이 많은 blockchains의 확장 문제. 그러나 그들은 다루지 않습니다 MEV의 문제. 대신 rollup을 생성하는 엔터티로 이동합니다. 그 smart contract의 운영자이든 (zk-)rollup을 제공하는 사용자이든 상관없이 엔터티 유효성 증명은 거래를 주문하고 삽입할 수 있는 권한을 갖습니다. 즉, rollups MEV를 REV: 롤업 추출 가능 값으로 교체합니다. MEV는 멤풀에 제출된 향후 거래에 영향을 미칩니다. 하지만 아직 체인에 커밋되지는 않았습니다. 그러한 거래에 관한 정보는 광범위하게 네트워크에서 사용 가능합니다. 채굴자, validators 및 일반 네트워크 참가자는 따라서 이 지식을 활용하고 종속 트랜잭션을 생성합니다. 또한, 채굴자와 validator은 자신이 수행하는 거래의 순서에 영향을 미칠 수 있습니다. 스스로를 이용하고 이를 자신들에게 유리하게 활용합니다. 합의에 따른 거래 주문에 대한 리더의 과도한 영향력 문제 프로토콜은 1990년대 이후 문헌에 알려져 있지만[71, 190] 만족스럽지 않습니다. 솔루션은 지금까지 실제로 실현되었습니다 [97]. 주된 이유는 제안된 솔루션이 적어도 아주 최근까지는 대중과 쉽게 통합될 수 없다는 것입니다. blockchains, 이후까지 비밀로 유지되는 거래 내용에 의존하기 때문입니다. 그들의 순서가 결정되었습니다. 공정한 시퀀싱 서비스(FSS) 개요: DONs는 트랜잭션 주문을 분산화하고 의존자가 지정한 정책에 따라 이를 구현하는 도구를 제공합니다. 계약 작성자, 이상적으로는 공정하고 유리한 행위자를 원하는 사람이 아닌 사람 거래 순서를 조작합니다. 이러한 도구는 집합적으로 FSS를 구성합니다. FSS에는 세 가지 구성 요소가 포함됩니다. 첫 번째는 거래 모니터링이다. FSS에서는 O의 oracle 노드는 MAINCHAIN의 mempool을 모니터링하고 (원하는 경우) 허용합니다. 전문 채널을 통한 오프체인 거래 제출. 두 번째는 거래 순서입니다. 의존 계약에 대한 O 주문 거래의 노드 해당 계약에 대해 정의된 정책에 따라. 세 번째는 거래 게시입니다. 트랜잭션이 주문된 후 O의 노드는 트랜잭션을 공동으로 보냅니다. 메인 체인. FSS의 잠재적 이점은 다음과 같습니다. • 주문 공정성: FSS에는 개발자가 거래를 보장하는 데 도움이 되는 도구가 포함되어 있습니다. 특정 계약에 대한 입력은 불공정하지 않은 방식으로 주문됩니다. 자원이 풍부하고 기술적으로 정통한 사용자에게 유리합니다. 주문 정책 이 목적으로 지정될 수 있습니다. • 정보 유출의 감소 또는 제거: 네트워크 참가자가 향후 거래에 대한 지식을 이용할 수 없도록 보장함으로써 FSS는 이를 완화하거나 제거할 수 있습니다. 이용 가능한 정보를 기반으로 하는 선행 실행과 같은 공격을 제거합니다. 트랜잭션이 커밋되기 전의 네트워크. 그러한 악용 방지 누출은 원래 보류에 의존하는 적대적 거래를 보장합니다. 원래 거래가 커밋되기 전에는 거래가 원장에 들어갈 수 없습니다.• 거래 비용 절감: 제출 속도에 대한 플레이어의 요구 사항 제거 smart contract에 대한 거래를 통해 FSS는 거래 처리 비용을 크게 줄일 수 있습니다. • 우선순위 지정: FSS는 중요한 거래에 자동으로 특별한 우선순위를 부여할 수 있습니다. 주문. 예를 들어 oracle에 대한 선행 공격을 방지하기 위해 보고서(예: [79]), FSS는 oracle 보고서를 거래 흐름에 삽입할 수 있습니다. 소급하여. DONs에서 FSS의 가장 중요한 목표는 DeFi 제작자가 공정한 실현을 실현할 수 있도록 권한을 부여하는 것입니다. 금융 시스템, 즉 특정 사용자(또는 채굴자)에게 이익을 주지 않는 시스템 속도, 내부 지식 또는 기술 수행 능력을 기준으로 다른 사람보다 우수합니다. 조작. 명확하고 일반적인 공정성 개념은 파악하기 어렵고 완벽한 공정성은 합리적인 감각은 달성할 수 없습니다. FSS는 개발자에게 강력한 기능을 제공하는 것을 목표로 합니다. DeFi에 대한 설계 목표를 달성하는 데 도움이 되는 정책을 시행할 수 있는 도구 세트입니다. FSS의 주요 목표는 공정한 시퀀싱 서비스 역할을 하는 것이지만 DON의 목표인 MAINCHAIN은 FSS가 원하는 것과 동일한 공정성 중 일부입니다. 보장은 또한 실행되는 (분산형) 프로토콜에도 적합할 수 있습니다. DON 파티. 따라서 FSS는 하위 집합이 제공하는 서비스로 더 광범위하게 볼 수 있습니다. DON 노드는 MAINCHAIN 사용자가 보낸 트랜잭션뿐만 아니라 공정한 순서를 지정합니다. 또한 다른 DON 노드 간에 공유되는 트랜잭션(즉, 메시지)도 있습니다. 이 섹션에서는 우리는 주로 MAINCHAIN 거래 순서를 정하는 목표에 중점을 둘 것입니다. 섹션 구성: 섹션 5.1에서는 FSS 설계에 동기를 부여하는 두 가지 상위 수준 애플리케이션, 즉 oracle 보고서의 전면 실행 방지 및 방지를 설명합니다. 사용자 트랜잭션의 선행 실행. 그런 다음 FSS 설계에 대한 자세한 내용을 제공합니다. 섹션 5.2에서. 섹션 5.3에서는 공정한 주문 보장 및 수단의 예를 설명합니다. 그것을 달성하기 위해. 마지막으로 섹션 5.4와 섹션 5.5에서는 네트워크 수준의 위협에 대해 논의합니다. 네트워크 플러딩과 Sybil에 대해 각각 이러한 정책과 이를 해결하는 수단 공격. 5.1 전면 실행 문제 FSS의 목표와 설계를 설명하기 위해 우리는 프론트러닝의 두 가지 일반적인 형태를 설명합니다. 공격과 기존 솔루션의 한계. 프론트 런닝은 클래스를 예시합니다. 트랜잭션 주문 공격: 우리가 다루지 않는 백런 및 샌드위치(프론트 러닝 및 백 런) [237]과 같은 관련 공격이 많이 있습니다. 여기에 있지만 FSS도 해결하는 데 도움이 됩니다. 5.1.1 Oracle 선두 실행 blockchain 애플리케이션에 오프체인 데이터를 제공하는 전통적인 역할에서 oracles 전방 공격의 자연스러운 표적이 됩니다.다양한 가격 피드를 제공하기 위해 oracle을 사용하는 일반적인 디자인 패턴을 고려하십시오. 온체인 거래소로: 주기적으로(매시간) oracle은 가격 데이터를 수집합니다. 다른 자산을 교환 계약으로 보냅니다. 이러한 가격 데이터 거래 명백한 차익 거래 기회 제공: 예를 들어 최신 oracle 보고서에 일부 자산의 가격이 훨씬 높을 경우, 적이 oracle 보고서를 미리 실행할 수 있습니다. 자산을 매입하고 oracle의 신고가 처리되면 즉시 재판매하세요. 과속방지턱 및 소급 가격: oracle 선점 문제에 대한 자연스러운 해결책은 oracle 보고서에 다른 거래보다 특별한 우선순위를 부여하는 것입니다. 에 대한 예를 들어, oracle 보고서는 채굴자가 처리하도록 장려하기 위해 높은 수수료로 전송될 수 있습니다. 먼저 그들. 그러나 차익거래 기회가 높다면 선행매매를 막을 수는 없습니다. 또한 채굴자 자신의 차익 거래를 막을 수도 없습니다. 따라서 일부 거래소는 처리하기 전에 여러 블록에 대해 사용자 트랜잭션을 대기열에 넣는 등 보다 무거운 "속도 향상"을 구현하는 데 의존했습니다. 또는 새로운 oracle 보고서가 도착하면 가격을 소급하여 조정합니다. 이러한 솔루션의 단점은 교환 구현에 복잡성을 추가한다는 것입니다. 저장 요구 사항이 증가하여 거래 비용이 증가하고 자산 교환이 상당한 기간이 지난 후에만 확인되므로 사용자 경험이 중단됩니다. 편승: FSS로 넘어가기 전에 우리는 매우 간단하고 간단한 피기백(piggybacking)에 대해 논의합니다. oracle 전면 실행 문제에 대한 우아한 솔루션입니다. 주소에는 해당되지 않습니다. 그러나 다른 시나리오에서는 선행 실행됩니다. 즉, 온체인 컨트랙트에 정기적으로 보고서를 보내는 대신 oracles 사용자가 구매 또는 판매 시 거래에 추가하는 서명된 보고서를 게시합니다. 온체인 자산. 그런 다음 거래소는 보고서가 유효하고 최신인지 확인합니다. (예: oracle은 보고서가 유효한 블록 범위에 서명할 수 있음) 그것으로부터 관련 가격 피드. 이 간단한 접근 방식은 위의 "과속 방지턱"에 비해 여러 가지 장점이 있습니다. 접근 방식: (1) 교환 계약은 가격 피드 상태를 유지할 필요가 없습니다. 거래 비용이 낮아집니다. (2) oracle 보고서는 필요에 따라 체인에 게시되므로 oracle은 더 자주(예: 매분) 업데이트를 생성할 수 있습니다. 보고서 선행 실행으로 인한 차익거래 기회 최소화9; (3) 거래는 다음과 같습니다. 항상 새로운 가격 피드가 포함되어 있으므로 즉시 검증됩니다. 그러나 접근 방식이 완벽하지는 않습니다. 첫째, 이 피기백 솔루션은 거래소 사용자는 최신 oracle 보고서를 가져와서 첨부할 책임이 있습니다. 거래. 둘째, 편승은 차익거래 기회를 최소화하지만, 온체인 계약의 활성 상태에 영향을 주지 않고 이를 완전히 방지합니다. 실제로 만약에 oracle 보고서는 일부 블록 번호 n까지 유효하며 이후 거래가 블록에 제출됩니다. n + 1에는 새로운 유효한 보고서가 필요합니다. 본질적인 전파 지연으로 인해 oracles에서 사용자에게 보고하는 경우 블록 n + 1에 유효한 새 보고서는 9차익거래는 자산 가격의 활용 가능한 차이가 외부 차익을 초과하는 경우에만 가치가 있습니다. 자산을 사고 파는 데 필요한 수수료(예: 채굴자와 거래소가 수집한 자산)블록 n + 1이 채굴되기 전 일정 기간(예: 블록 n −k)에 공개됩니다. 단기 차익거래 기회가 존재하는 일련의 k개 블록을 생성합니다. 우리 이제 FSS가 이러한 제한 사항을 어떻게 해결하는지 설명합니다. FSS를 통해 oracle 보고서의 우선순위 지정: FSS는 oracle 전면 실행 문제를 해결할 수 있습니다. 위의 피기백 솔루션을 기반으로 구축했지만 추가 솔루션을 추진하여 문제가 발생했습니다. oracle을 통한 트랜잭션 증가 작업은 분산형 오라클 네트워크에 보고됩니다. 높은 수준에서 oracle 노드는 온체인 교환을 위한 트랜잭션을 수집합니다. 실시간 가격 피드에 동의하고 수집된 거래와 함께 가격 피드를 메인 체인 계약에 게시합니다. 개념적으로는 이 접근 방식을 다음과 같이 생각할 수 있습니다. oracle이 최신 상태를 보장하는 "데이터 증강 트랜잭션 일괄 처리" 가격 피드는 항상 거래에 추가됩니다. FSS 솔루션은 거래소 사용자에게 투명하게 구현될 수 있으며, 섹션 5.2에서 자세히 설명하는 것처럼 계약 논리에 대한 최소한의 변경입니다. 보장 새로운 oracle 보고서가 항상 사용자 거래보다 우선시된다는 점은 단지 하나의 예일 뿐입니다. FSS가 채택하고 시행할 수 있는 주문 정책입니다. 질서 보장을 위한 금감원의 정책 공정성은 섹션 5.3에서 더 일반적으로 설명됩니다. 5.1.2 선행 사용자 트랜잭션 이제 위의 방어 방법이 사용되는 일반 애플리케이션에서 전면 실행으로 전환합니다. 작동하지 않습니다. 이 문제는 다음 시나리오를 통해 광범위하게 파악할 수 있습니다. 공격자는 P2P 네트워크로 전송된 일부 사용자 트랜잭션 tx1을 보고 주입합니다. 자신의 적대적 트랜잭션 tx2를 사용하여 tx2가 tx1보다 먼저 처리되도록 합니다(예: 더 높은 거래 수수료). 예를 들어, 이런 종류의 선행 실행은 다음 중 일반적입니다. DeFi 시스템 [90]에서 재정 거래 기회를 이용하고 사용자에게 영향을 미치는 봇 다양한 분산 애플리케이션 [101]. 거래간의 공정한 질서를 확립한다 blockchain에서 처리되면 이 문제가 해결됩니다. 더 근본적으로, tx1의 세부 사항을 보는 것이 때로는 필요하지도 않으며 단순한 존재에 대한 지식으로 인해 적이 tx1을 통해 tx1을 앞지르게 할 수 있습니다. tx2를 소유하고 tx1을 생성한 무고한 사용자를 속이세요. 예를 들어, 사용자는 정기적으로 특정 자산을 거래하는 것으로 알려져 있습니다. 그러한 공격을 예방하려면 다음이 필요합니다. 메타데이터 유출도 방지하는 완화 [62]. 이 문제에 대한 몇 가지 해결책 존재하지만 지연과 유용성 문제가 발생합니다. FSS를 사용하여 네트워크 순서에서 최종 순서까지: 선두주자의 기회 기존 시스템에는 순서를 보장하는 메커니즘이 없기 때문에 발생합니다. 거래는 사건의 순서와 정보 흐름을 존중하여 체인에 나타납니다. 네트워크 외부. 이는 blockchain에서 애플리케이션(예: 거래 플랫폼) 구현의 결함으로 인해 발생하는 문제를 나타냅니다. 이상적으로는 트랜잭션이 blockchain에서 동일한 순서로 커밋되었는지 확인하세요. 생성되어 blockchain의 P2P 네트워크로 전송됩니다. 하지만 blockchain 네트워크 이후
분산되어 있으면 그러한 주문을 캡처할 수 없습니다. 따라서 FSS는 메커니즘을 도입합니다. 분배로 인해 발생하는 공정성 위반으로부터 보호하기 위해 blockchain 네트워크의 성격. 5.2 FSS 세부정보 그림 12: 두 가지 다른 트랜잭션 경로를 갖춘 주문 공정 멤풀: 직접적이고 멤풀 기반. 그림 12는 FSS의 일반적인 개략도를 보여줍니다. 공정성을 보장하기 위해 FSS를 제공하는 DON은 MAINCHAIN에 진입할 때 거래 흐름을 방해해야 합니다. 클라이언트, MAINCHAIN의 smart contracts 또는 둘 다에 대한 조정이 필요할 수 있습니다. 높은 수준에서 FSS의 거래 처리는 세 가지로 분해될 수 있습니다. 아래에 설명된 단계: (1) 거래 모니터링; (2) 거래 순서; 그리고 (3) 거래 게시. 트랜잭션 순서 지정에 사용되는 주문 방법에 따라 다음 섹션에 설명된 대로 추가 프로토콜 단계가 필요합니다. 5.2.1 거래 처리 거래 모니터링: 우리는 FSS가 모니터링할 수 있는 두 가지 접근 방식을 구상합니다. 특정 smart contract을 대상으로 하는 사용자 트랜잭션, 직접 및 mempool 기반: • 직접: 직접 접근 방식은 개념적으로 가장 간단하지만 다음 사항에 대한 변경이 필요합니다. 트랜잭션이 분산형 Oracle로 직접 전송되도록 사용자 클라이언트메인 체인의 노드가 아닌 네트워크 노드. DON는 수집합니다 특정 smart contract SC로 향하는 사용자 트랜잭션을 기반으로 주문합니다. 일부 주문 정책에 대해 그런 다음 DON은 주문된 트랜잭션을 다음으로 보냅니다. smart contract 메인 체인에 있습니다. 일부 주문 메커니즘에는 트랜잭션을 생성하는 사용자가 암호화 방식을 사용해야 하므로 직접적인 접근 방식도 필요합니다. FSS로 보내기 전에 보호하십시오. • Mempool 기반: FSS와 레거시 클라이언트의 통합을 용이하게 하기 위해 DON Mempool Services(MS)를 사용하여 메인 체인의 mempool을 모니터링하고 수집할 수 있습니다. 거래. 직접 전송은 많은 계약에서 선호되는 구현일 가능성이 높습니다. 그리고 우리는 이것이 많은 경우 상당히 실용적일 것이라고 믿습니다. 우리는 기존 DApp을 최소한으로 수정하여 지원하는 방법에 대해 간략하게 논의합니다. 좋은 사용자 경험을 유지하면서 직접 전송합니다. 우리는 접근 방식을 설명합니다 오늘날 가장 인기 있는 선택이기 때문에 Ethereum 및 MetaMask [6]을 사용하지만 언급된 기술은 다른 체인과 지갑으로 확장되어야 합니다. 최근 Ethereum 개선 제안, “EIP-3085: 지갑 추가 Ethereum 체인 RPC 방법” [100], 사용자 정의 Ethereum 체인을 쉽게 타겟팅할 수 있습니다(다른 체인 ID 사용). MetaMask 및 기타 브라우저 기반 지갑의 재생 공격을 방지하기 위한 MAINCHAIN의 것입니다. 이 제안을 구현한 후 DON를 사용하려는 DApp은 직접 전송할 수 있도록 프런트 엔드에 단일 메서드 호출을 추가하기만 하면 됩니다. Ethereum 호환 API를 노출하는 DON에 대한 트랜잭션입니다. 그동안, "EIP-712: Ethereum 유형화된 구조화된 데이터 hash생성 및 서명" [49]은 약간의 정보를 제공합니다. DApp 사용자가 사용할 수 있는 더 복잡하지만 이미 널리 배포된 대안 DON 트랜잭션을 지정하는 구조화된 데이터에 서명하는 MetaMask입니다. DApp은 보낼 수 있습니다 이 서명된 구조화된 데이터를 DON에 보냅니다. 마지막으로 하이브리드 접근 방식도 가능하다는 점에 주목합니다. 예를 들어, 유산 클라이언트는 계속해서 메인 체인의 멤풀로 트랜잭션을 보낼 수 있지만 매우 중요합니다. 거래(예: oracle 보고서)는 DON 노드로 직접 전송됩니다(특히 가격 피드 업데이트와 같은 oracle 보고서를 제공하는 노드 세트 및 노드 세트 FSS 제공은 중복되거나 동일할 수 있습니다). 거래 순서: FSS의 주요 목적은 사용자 트랜잭션이 미리 정의된 정책에 따라 정렬되도록 보장하는 것입니다. 이 정책의 성격은 다음과 같습니다. 애플리케이션의 요구와 불공정 거래 명령 유형에 따라 다릅니다. 예방하는 것을 목표로 합니다. DON의 FSS는 데이터를 처리하고 로컬 상태를 유지할 수 있으므로, 그들은 정보를 기반으로 임의의 순서 지정 정책을 부과할 수 있습니다. oracles에서 사용 가능합니다. 특정 주문 정책과 그 구현은 이후 섹션 5.3에서 논의됩니다.거래 전기: 사용자로부터 직접 받거나 멤풀에서 수집한 사용자 트랜잭션을 수집하고 주문한 후 DON은 이러한 트랜잭션을 메인 체인으로 보냅니다. 따라서 DON의 메인 체인과의 상호 작용은 그대로 유지됩니다. 메인 체인의 채굴자가 관리하는 (잠재적으로 불공평한) 거래 명령이 적용됩니다. 분산형 거래 주문의 이점을 활용하기 위해 대상 스마트 따라서 계약 SC는 DON을 "일류" 시민으로 취급하도록 설계되어야 합니다. 우리 두 가지 접근 방식을 구별합니다. • DON 전용 계약: 가장 간단한 설계 옵션은 메인 체인을 스마트하게 만드는 것입니다. 계약 SC는 DON에 의해 처리된 거래만 수락합니다. 이 smart contract이(가) 제안한 순서대로 트랜잭션을 처리하는지 확인합니다. DON이지만 사실상 smart contract은 위원회 기반 시스템에서 운영되도록 제한됩니다(즉, DON 위원회는 이제 거래 주문 및 포함). • 이중 클래스 계약: 선호되고 보다 세분화된 설계를 통해 메인 체인이 스마트해집니다. 계약 SC는 DON 및 레거시에서 발생하는 트랜잭션을 수락합니다. 사용자10 그러나 DON에 의해 처리되지 않은 거래에는 전통적인 "과속 방지턱"이 적용됩니다. 예를 들어 DON의 거래가 처리될 수 있습니다. 즉시, 레거시 트랜잭션은 smart contract에 의해 "버퍼링"됩니다. 정해진 기간. 선행 실행을 방지하기 위한 기타 표준 메커니즘 커밋-공개 방식이나 VDF [53]과 같은 방식은 레거시에도 적용될 수 있습니다. 거래. 이렇게 하면 DON 주문된 트랜잭션이 처리됩니다. DON에 원치 않는 검열 권한을 부여하지 않고 합의된 명령 거래. FSS의 거래 순서 지정을 위해서는 거래가 "오프체인"으로 집계되어야 하므로 이 솔루션은 자연스럽게 온체인 처리 비용을 줄이기 위한 다른 집계 기술과 결합됩니다. 예를 들어, 수집한 후 거래를 주문하면 DON은 이러한 거래를 메인 체인에 보낼 수 있습니다. 단일 "일괄 트랜잭션"(예: rollup)으로 인해 총 트랜잭션이 줄어듭니다. 수수료. 거래 명령 집행: DON 전용 디자인이든 듀얼 클래스 디자인이든, 메인 체인 smart contract SC와 DON은 DON의 거래 순서가 유지되도록 보장하기 위해 공동 설계되어야 합니다. 여기서도 우리는 다른 것을 상상합니다. 디자인 옵션: • 시퀀스 번호: DON은 각 트랜잭션에 시퀀스 번호를 추가하고 이러한 트랜잭션을 메인 체인의 멤풀로 보낼 수 있습니다. 주요 10DON의 트랜잭션 모니터링이 멤풀을 기반으로 하는 경우 레거시 트랜잭션은 DON 트랜잭션과 구별되어야 DON에 의해 수집되지 않습니다(예: 특수 태그를 통해). 거래에 포함되거나 특정 가스 가격을 지정함으로써 가능합니다. DON 거래에 가스가 있습니다 특정 기준점 이하의 가격.체인 smart contract SC는 "순서가 맞지 않게" 도착하는 트랜잭션을 무시합니다. 우리 이 설정에서 메인 체인 채굴자는 DON을 무시하기로 결정할 수 있습니다. 트랜잭션 주문으로 인해 트랜잭션이 실패하게 됩니다. SC가 올바른 트랜잭션 순서를 강제하도록 (비싼) 상태를 유지함으로써 어느 정도 가능합니다. TCP가 누락된 패킷이 발견될 때까지 순서가 잘못된 패킷을 버퍼링하는 방법과 유사합니다. 받았습니다. • 거래 nonces: 많은 blockchains, 특히 Ethereum의 경우 위의 일련 번호 지정 방식은 내장된 트랜잭션 nonce을 활용하여 다음을 수행할 수 있습니다. 메인 체인 smart contract SC가 트랜잭션을 순서대로 처리하도록 강제합니다. 여기서 DON 노드는 DON 노드 간에 공유되는 키로 보호되는 단일 메인체인 계정을 통해 메인체인에 트랜잭션을 보냅니다. 계정의 transaction nonce은 거래가 올바른 순서로 채굴되고 처리되도록 보장합니다. • 집계 트랜잭션: DON은 rollup에서 여러 트랜잭션을 집계할 수 있습니다. (또는 rollup과 유사한 번들). 메인 체인 smart contract은 다음과 같아야 합니다. 이러한 집계 트랜잭션을 처리하도록 설계되었습니다. • 메인 체인 프록시를 사용한 집계 트랜잭션: 여기서 DON은 마찬가지로 트랜잭션을 메인 체인에 대한 하나의 "메타 트랜잭션"으로 묶지만 사용자 정의 프록시 smart contract를 사용하여 트랜잭션의 압축을 풀고 이를 대상 계약 SC. 이 기술은 레거시 호환성에 유용할 수 있습니다. 메타트랜잭션은 rollup과 유사하게 작동하지만 압축되지 않은 트랜잭션으로 구성된다는 점에서 다릅니다. 메인 체인에 한 번 게시된 거래 목록입니다. 마지막 디자인은 사용자 트랜잭션을 원활하게 지원한다는 장점이 있습니다. DON의 목표에 도달하기 전에 메인 체인 계약을 통해 스스로 프록시됩니다. SC와 계약을 맺다 예를 들어, 어떤 지갑에 거래를 보내는 사용자를 생각해 보세요. 계약은 내부 트랜잭션을 SC로 보냅니다. 시퀀스 할당 사용자의 지갑 계약이 그렇지 않은 경우를 제외하고 그러한 거래에 대한 번호는 까다로울 수 있습니다. 모든 내부 트랜잭션과 함께 시퀀스 번호를 전달하도록 특별히 설계되었습니다. SC. 마찬가지로 이러한 내부 트랜잭션은 SC로 직접 전송되는 메타트랜잭션으로 쉽게 집계될 수 없습니다. 우리는 다음에 대한 추가 설계 고려 사항에 대해 논의합니다. 아래의 프록시 거래. 5.2.2 트랜잭션 원자성 지금까지의 논의에서는 트랜잭션이 단일 개체와 상호작용한다고 암묵적으로 가정했습니다. 온체인 smart contract(예: 사용자가 교환소에 구매 요청을 보냅니다). 그러나 에서는 Ethereum와 같은 시스템에서 단일 트랜잭션은 여러 내부 트랜잭션으로 구성될 수 있습니다. 예를 들어 하나의 smart contract은 다른 계약의 함수를 호출합니다. 아래에서 우리는 "다중 계약" 거래 순서를 지정하기 위한 두 가지 고급 전략을 설명합니다. 트랜잭션의 원자성(즉, 다음에 의해 규정된 일련의 작업)을 보존합니다. 트랜잭션은 모두 올바른 순서로 실행되거나 전혀 실행되지 않습니다.강력한 원자성: 가장 간단한 해결책은 위에서 설명한 대로 FSS를 전체 "다중 계약" 거래에 직접 적용하는 것입니다. 즉, 사용자는 거래를 보냅니다. 네트워크에 들어가고 FSS는 이러한 거래를 모니터링하고 순서를 정하고 게시합니다. 메인 체인. 이 접근 방식은 기술적으로 간단하지만 한 가지 잠재적인 제한 사항이 있습니다. 거래는 공정한 활용을 원하는 두 계약 SC1 및 SC2와 상호 작용합니다. 시퀀싱 서비스를 사용하려면 이 두 계약의 시퀀싱 정책이 일관되어야 합니다. 즉, 각각 상호작용하는 두 개의 서로 다른 트랜잭션 tx1 및 tx2가 있는 경우 SC1과 SC2 모두 SC1의 정책이 tx2보다 먼저 tx1을 주문하는 경우가 있어서는 안 됩니다. SC2의 정책은 반대 순서를 규정합니다. 관심 있는 대부분의 시나리오에 대해 우리는 다양한 계약에서 채택한 순서 정책이 일관될 것이라고 생각합니다. 예를 들어 SC1과 SC2 모두 mempool에 대략적인 도착 시간을 기준으로 트랜잭션을 정렬하기를 원할 수 있습니다. SC1은 특정 oracle 보고서가 항상 먼저 전달되기를 원할 수도 있습니다. 다음과 같이 후자의 oracle 보고서 트랜잭션은 SC2와 상호 작용하지 않으며 정책은 일관됩니다. 약한 원자성: 일반적으로 FSS는 개인 수준에서 적용될 수 있습니다. 내부 거래. 일부 초기 항목으로 구성된 tx = { ~txpre, ~txSC, ~txpost} 형식의 트랜잭션을 고려하십시오. 트랜잭션 ~txpre, 이는 SC에서 내부 트랜잭션 ~txSC로 이어지며, 이는 차례로 내부 트랜잭션 ~txpost를 발행합니다. SC의 시퀀싱 정책에 따라 방법이 결정될 수 있습니다. 내부 트랜잭션 ~txSC는 전송된 다른 트랜잭션과 관련하여 주문되어야 합니다. SC로 이동하되 ~txpre 및 ~txpost에 대한 시퀀스 순서는 열어 둡니다. Ethereum과 같은 시스템에서 트랜잭션 처리의 본질적인 특성을 고려할 때 특정 내부 트랜잭션을 대상으로 하는 시퀀싱 서비스를 개발하는 것은 간단하지 않습니다. 특별히 설계된 계약 SC를 사용하면 다음과 같이 실현할 수 있습니다. 1. 트랜잭션 tx가 네트워크로 전송되어 채굴됩니다(시퀀싱 없이). FSS에서 수행). 초기 ~txpre가 실행되고 ~txSC를 호출합니다. 2. SC는 ~txSC를 실행하지 않고 반환됩니다. 3. FSS는 SC에 대한 내부 거래를 모니터링하고 순서를 정한 후 다시 게시합니다. SC로(즉, 트랜잭션 ~txSC를 SC로 직접 보냄) 4. SC는 FSS로부터 받은 트랜잭션 ~txSC를 처리하고, ~txSC의 결과인 내부 트랜잭션 ~txpost를 발행합니다. 이 접근 방식을 사용하면 트랜잭션이 완전히 원자적으로 실행되지 않습니다(즉, 원본 트랜잭션 tx는 여러 개의 온체인 트랜잭션으로 분할되지만 순서는 내부 거래는 보존됩니다. 이 솔루션에는 여러 가지 설계 제약이 따릅니다. 예를 들어 ~txpre는 다음을 수행할 수 없습니다. ~txSC 및 ~txpost가 실행될 것이라고 가정합니다. 더욱이 SC는 다음과 같이 설계되어야 한다. 특정 사용자를 대신하여 ~txSC 및 ~txpost 트랜잭션을 실행합니다.FSS에서 보냈습니다. 이러한 이유로 보다 세분화된 "Strong Atomicity" 솔루션 실제로는 위의 내용이 바람직할 수 있습니다. 여러 트랜잭션과 관련된 보다 복잡한 종속성을 존중하기 위해 각각의 내부 거래에는 FSS의 거래 스케줄러가 포함될 수 있습니다. 관계형 트랜잭션 관리자에서 볼 수 있는 것과 유사한 정교한 기능 데이터베이스 관리자. 5.3 공정한 거래 순서 여기에서는 FSS에 의해 실현될 수 있는 거래 순서 결정 및 해당 구현에 대한 두 가지 공정성 개념에 대해 논의합니다. 정책 기반 주문 공정성 FSS에 의해 부과되며 인과관계 보존을 보장하므로 FSS에 추가적인 암호화 방법이 필요합니다. 주문 공정성: 질서 공정성은 합의 프로토콜에서 시간적 공정성에 대한 개념입니다. Kelkar et al.에 의해 처음으로 공식적으로 소개되었습니다. [144]. Kelkaret al. 거래가 이루어지는 자연정책의 형태를 달성하는 것을 목표로 합니다. DON(또는 P2P 네트워크, mempool 기반 FSS의 경우). 그러나 분산형 시스템에서는 다릅니다. 노드는 트랜잭션이 다른 순서로 도착하는 것을 볼 수 있습니다. 전체 주문 설정 모든 거래에 대한 문제는 기반이 되는 합의 프로토콜에 의해 해결되는 바로 그 문제입니다. 메인체인. Kelkaret al. [144] 따라서 다음과 같은 약한 개념을 도입합니다. 이는 "블록 주문 공정성"이라고 불리는 분산형 Oracle 네트워크의 도움으로 달성됩니다. DON이(가) 일정 시간 간격 동안 수신한 트랜잭션을 다음과 같이 그룹화합니다. 블록을 생성하고 해당 블록의 모든 트랜잭션을 동시에 동일한 위치에 삽입합니다. (즉, 높이)를 MAINCHAIN에 넣습니다. 따라서 이들은 함께 주문되며 실행 가능해야 합니다. 동시에, 그들 사이에 어떤 갈등도 일으키지 않습니다. 대략적으로 말하자면, 주문 공정성은 많은 노드가 τ2 이전에 트랜잭션 τ1을 본다면 다음과 같이 말합니다. τ1은 τ2 이전 또는 동일한 블록에서 시퀀스됩니다. 이런 거친 짓을 해서 거래 주문을 세분화하면 선행 실행 및 기타 주문 관련 공격 기회가 크게 줄어듭니다. Kelkaret al. Aequitas [144]라는 프로토콜 제품군을 제안합니다. 동기식, 부분 동기식, 비동기식 네트워크 설정을 포함한 다양한 배포 모델. Aequitas 프로토콜은 기본 BFT 합의에 비해 상당한 통신 오버헤드를 부과하므로 실제 사용에는 적합하지 않습니다. 그러나 우리는 사용할 수 있는 Aequitas의 실용적인 변형이 나타날 것이라고 믿습니다. FSS 및 기타 애플리케이션의 트랜잭션 순서 지정을 위한 것입니다. 일부 관련 계획에는 형식주의와 속성이 덜 수반되는 방식이 이미 제안되었습니다. 예를 들어 [36, 151, 236]이지만 실제 성능이 더 좋습니다. 이러한 구성표가 지원될 수 있습니다. FSS에서도요. "공정성"이라는 용어가 blockchain의 다른 곳에 나타난다는 점도 주목할 가치가 있습니다. 다른 의미를 지닌 문학, 즉 기회라는 의미에서의 공정성헌신된 자원 [106, 181] 또는 validators에 비례하는 광부 평등한 기회 [153]. 안전한 인과관계 보존: 분산 플랫폼에서 선행 실행 및 기타 주문 위반을 방지하는 가장 널리 알려진 접근 방식은 암호화에 의존합니다. 기술. 그들의 일반적인 특징은 거래 데이터 자체를 숨기고 합의 계층의 순서가 확립되었으며 거래 데이터를 공개합니다. 나중에 처리를 위해. 이는 거래 간의 인과적 순서를 보존합니다. blockchain에 의해 실행됩니다. 관련 보안 개념 및 암호화 프로토콜 blockchains [71, 190]이 출현하기 전에 상당히 개발되었습니다. "입력 인과성" [190] 및 "안전한 인과성 보존"[71, 97]의 보안 조건은 거래에 대한 정보가 알려지지 않도록 공식적으로 요구합니다. 글로벌 순서에서 이 거래의 위치가 결정되기 전에. 공격자는 그때까지 암호화된 방식으로 어떤 정보도 추론할 수 없어야 합니다. 강한 감각. 인과관계를 보존하기 위해 네 가지 암호화 기술을 구별할 수 있습니다. • 커밋-공개 프로토콜 [29, 142, 145]: 트랜잭션이 발표되는 대신 명확하게는 거래에 대한 암호화된 약속만 공개됩니다. 모든 커밋되었지만 숨겨진 트랜잭션이 주문된 후(blockchain 초기에) MAINCHAIN 자체의 시스템(여기서는 FSS에 의한 시스템)에서 보낸 사람은 미리 결정된 시간 간격 내에 약속을 열고 거래 데이터를 공개해야 합니다. 그런 다음 네트워크는 개시가 이전 약속을 충족하는지 확인합니다. 는 이 방법의 기원은 blockchains 출현 이전입니다. 비록 매우 간단하지만 이 접근 방식은 상당한 단점을 가져오고 두 가지 이유로 사용하기 쉽지 않습니다. 첫째, 주문 프로토콜 수준에서는 커밋만 존재하므로 트랜잭션의 의미는 다음과 같습니다. 합의 중에는 검증할 수 없습니다. 클라이언트까지의 추가 왕복 필요합니다. 그러나 더 심각한 것은 개봉이 불가능할 가능성에 무게를 두고 있습니다. 이는 서비스 거부 공격에 해당할 수 있습니다. 게다가, 그것은 일관되고 분산된 방식으로 오프닝이 유효한지 여부를 결정하는 것은 어렵습니다. 왜냐하면 모든 참가자는 오프닝이 도착했는지 여부에 동의해야 하기 때문입니다. 시간. • 지연된 복구가 포함된 커밋-공개 프로토콜 [145]: 커밋-공개 접근 방식은 클라이언트가 추측에 따라 트랜잭션을 커밋하고 후속 트랜잭션으로 인해 수익성이 있는 경우에만 이를 공개할 수 있다는 것입니다. 에이 커밋-공개 접근 방식의 최근 변형은 이에 대한 탄력성을 향상시킵니다. 일종의 잘못된 행동. 특히 TEX 프로토콜 [145]은 이 문제를 해결합니다. 암호화된 트랜잭션에 암호 해독 키가 포함되는 영리한 접근 방식을 사용합니다. 검증 가능한 지연 함수(VDF)를 계산하여 얻을 수 있습니다[53, 221]. 클라이언트인 경우 적시에 그녀의 거래를 해독하지 못하면 시스템의 다른 사람들이 해독합니다. 그녀를 대신하여 적당히 어려운 암호화 퍼즐을 해결합니다.• 임계값 암호화 [71, 190]: 이 방법은 DON이 수행할 수 있는 기능을 활용합니다. 임계값 암호화 작업. FSS가 공개 암호화를 유지한다고 가정합니다. 키 pkO와 oracle은 해당 개인 키를 서로 공유합니다. 그런 다음 클라이언트는 pkO에서 거래를 암호화하여 FSS로 보냅니다. FSS 주문 DON의 트랜잭션을 해독한 후 마지막으로 DON에 삽입합니다. MAINCHAIN은 고정된 순서로 진행됩니다. 따라서 암호화는 주문이 거래 내용을 기반으로 하는 것이 아니라 데이터 자체를 다음과 같은 경우에 사용할 수 있습니다. 필요합니다. 이 방법은 원래 Reiter와 Birman([190])에 의해 제안되었으며 나중에 Cachin 등에 의해 개선되었습니다. [71], 허가된 합의와 통합되었습니다. 프로토콜. 보다 최근의 연구에서는 임계값 암호화를 다음과 같이 사용하는 방법을 연구했습니다. 일반 메시지 [33, 97] 및 공유 데이터 [41]를 사용한 일반 계산을 위한 합의 수준 메커니즘. 커밋 공개 프로토콜과 비교하여 임계값 암호화는 단순한 서비스 거부 공격을 방지합니다(암호 해독에 드는 계산 비용을 고려할 때 주의가 필요함). DON이(가) 자체 속도로 자동으로 진행되도록 합니다. 추가 클라이언트 작업을 기다리고 있습니다. 거래는 해독된 후 즉시 검증될 수 있습니다. 또한 클라이언트는 모든 거래를 하나로 암호화합니다. DON의 키이며 통신 패턴은 다른 키와 동일하게 유지됩니다. 거래. 임계값 키를 안전하게 관리하고 노드를 변경하여 그러나 O는 추가적인 어려움을 초래할 수 있습니다. • 커밋된 비밀 공유 [97]: 거래 데이터를 암호화하는 대신 DON이 보유한 키인 경우 클라이언트는 이를 O의 노드에 대해 비밀 공유할 수도 있습니다. 하이브리드, 계산적으로 안전한 비밀 공유 방식을 사용하여 트랜잭션 먼저 임의의 키가 있는 대칭 암호를 사용하여 암호화됩니다. 해당 대칭 키만 공유되고 암호문은 DON에 제출됩니다. 클라이언트는 별도로 암호화된 메시지를 사용하여 O의 각 노드에 하나의 키 공유를 보내야 합니다. 나머지 프로토콜 단계는 임계값과 동일합니다. 단, 거래 데이터는 대칭형으로 해독됩니다. 공유에서 트랜잭션별 키를 재구성한 후 알고리즘을 사용합니다. 이 방법에는 공개 키 암호화 시스템의 설정이나 관리가 필요하지 않습니다. DON과 연결되어 있습니다. 그러나 클라이언트는 다음 노드에 대해 알고 있어야 합니다. O 그리고 그들 각각과 안전한 상황에서 통신합니다. 고객의 추가 부담. 암호화 방법은 정보로부터 완전한 보호를 제공하지만 제출된 트랜잭션에서 네트워크로 유출되는 경우 메타데이터를 숨기지 않습니다. 에 대한 예를 들어, 발신자의 IP 주소 또는 Ethereum 주소는 계속해서 사용될 수 있습니다. 전방 공격 및 기타 공격을 수행하는 적입니다. 다양한 프라이버시 강화 네트워크 계층(예: [52, 95, 107]) 또는 트랜잭션 계층에 배포된 기술, 예를 들어, [13, 65]는 이 목표를 달성하는 데 필요할 것입니다. 특정 작품의 영향 즉, 거래가 전송되는 계약에 대한 메타데이터를 (부분적으로) 숨길 수 있습니다.동일한 DON에서 많은 계약을 다중화함으로써. 암호화 은폐 거래 자체도 손상된 거래의 우선순위를 방해하지 않습니다. DON 노드가 거래 발신자와 공모하고 있습니다. 암호화 프로토콜에 의해 보장되는 안전한 인과관계는 모든 정책에 대한 질서 공정성 보장을 보완하며, 우리는 이 두 가지의 조합을 탐색할 계획입니다. 가능한 경우 방법. 상대방이 상당한 이점을 얻을 수 없는 경우 메타데이터를 관찰하면서 안전한 인과관계 보존 프로토콜을 함께 사용할 수 있습니다. 순진한 주문 방식도 마찬가지입니다. 예를 들어 oracle 노드는 트랜잭션을 작성할 수 있습니다. 중복 없이 L에게 수신 즉시 전달됩니다. 그러면 거래는 다음과 같습니다. L에 나타나는 순서에 따라 주문한 후 해독됩니다. 우리는 또한 공정한 주문을 집행하는 데 도움이 되는 방법으로 TEE 사용을 고려할 계획입니다. 에 대한 예를 들어, Tesseract [44]는 인과적 순서의 형태를 달성하는 것으로 볼 수 있지만 명시적인 형식으로 거래를 처리하는 TEE의 능력으로 강화되었습니다. 기밀을 유지합니다. 5.4 네트워크 계층 고려 사항 지금까지 FSS에 대한 설명은 주로 다음 사항을 집행하는 문제에 중점을 두었습니다. 최종 거래 순서는 네트워크에서 관찰된 순서와 일치합니다. 이후, 네트워크 계층 자체에서 발생할 수 있는 공정성 문제를 고려합니다. 기존 전자 시장의 고주파 거래자는 상당한 투자를 합니다. 우수한 네트워크 속도를 얻기 위한 리소스 [64], 암호화폐 거래소의 거래자는 유사한 행동 [90]을 나타냅니다. 네트워크 속도는 두 측면 모두에서 이점을 제공합니다. 다른 당사자의 거래를 관찰하고 경쟁 거래를 제출하는 행위. Flash Boys [155] 책에서 실제로 배포되고 대중화된 한 가지 치료법은 다음과 같습니다. IEX 거래소 [128]에서 처음 도입된 "과속 방지턱"은 나중에 다른 거래소에서도 도입되었습니다. [179]을 교환합니다(혼합된 결과 [19] 포함). 이 메커니즘은 시장 접근에 지연(IEX의 경우 350마이크로초)을 부과합니다. 속도. 경험적 증거. [128], 특정 거래 감소에 대한 효율성을 지원합니다. 일반 투자자의 비용. FSS는 단순히 비대칭을 구현하는 데 사용될 수 있습니다. 과속방지턱 - 들어오는 거래를 지연시키는 것입니다. Budish, Cramton 및 Shim [64]은 속도 이점을 활용한다고 주장합니다. 연속시장에서는 피할 수 없으며, 구조적 해결책을 주장합니다. 일괄 경매 기반 시장의 형태. 그러나 이 접근 방식은 널리 받아들여지지 않았습니다. 기존 거래 플랫폼에서. 기존 거래 시스템은 중앙 집중화되어 있으며 일반적으로 다음을 통해 거래를 받습니다. 단일 네트워크 연결. 대조적으로, 분산형 시스템에서는 다음이 가능합니다. 여러 유리한 지점에서 트랜잭션 전파를 관찰합니다. 결과적으로, P2P 네트워크에서는 네트워크 플러딩과 같은 행위를 관찰할 수 있습니다. 우리는 의도한다 개발자가 정책을 지정하는 데 도움이 되는 FSS에 대한 네트워크 계층 접근 방식을 탐색합니다. 그러한 바람직하지 않은 네트워크 행위를 금지합니다.5.5 엔터티 수준의 공정성 정책 주문 공정성과 안전한 인과성은 다음과 같은 거래에 대한 주문을 시행하는 것을 목표로 합니다. 생성되어 네트워크에 처음 제출된 시간을 존중합니다. 이러한 공정성 개념의 한계는 상대방이 공격하는 것을 방지하지 못한다는 것입니다. 거래가 많은 시스템이 넘쳐 이점을 얻는다. token 판매 [159]에서 효과적인 거래 저격을 수행하는 방법으로 야생에서 CDP(부채담보포지션) 청산으로 인한 혼잡 발생 [48]. 즉, 주문 공정성은 플레이어가 아닌 거래에 대한 공정성을 강화합니다. CanDID 시스템 [160]에 나와 있듯이 DECO와 같은 oracle 도구를 사용할 수 있습니다. 또는 노드 위원회(예: DON)와 함께 Town Crier를 통해 달성할 수 있습니다. 개인 정보를 보호하면서 다양한 형태의 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」と呼ばれますが、これはゼロ知識証明を必ずしも必要としないため、誤った名称です。
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 및 레이어 2 솔루션에 대한 분산형 리소스 지원을 제공합니다. 우리는 분산형 Oracle 네트워크 트랜잭션 실행 프레임워크(DONTEF) 또는 줄여서 TEF라고 부릅니다. 현재 DeFi 계약에 대한 업데이트 빈도는 메인 체인 지연 시간으로 인해 제한됩니다. 예를 들어 Ethereum [104]의 10-15초 평균 블록 간격과 체인에 대량의 데이터를 푸시하고 계산/전송 처리량이 제한됨 샤딩 [148, 158, 232] 및 레이어 2 실행 [5, 12, 121, 141, 169, 186, 187]. 거래 시간이 훨씬 빠른 blockchains라도, 예를 들어 [120]은 오프체인 계산 [168]과 관련된 확장 전략을 제안했습니다. TEF는 이러한 레이어 1/MAINCHAIN 시스템에 대한 레이어 2 리소스 역할을 하기 위한 것입니다. TEF를 사용하면 DONs는 MAINCHAIN 계약에서 더 빠른 업데이트를 지원할 수 있습니다. 메인 체인이 제공하는 주요 신뢰 보증을 유지합니다. TEF는 지원할 수 있습니다 rollups11을 포함한 다양한 레이어 2 실행 기술 및 패러다임 중 하나 낙관적인 rollups, Validium 등 및 DON이 포함된 임계 신뢰 모델 노드는 트랜잭션을 실행합니다. TEF는 FSS를 보완하며 이를 지원하기 위한 것입니다. 즉, 어떤 TEF에서 실행되는 애플리케이션은 FSS를 사용할 수 있습니다. 11영지식 증명이 반드시 필요하지 않기 때문에 종종 "zk-rollups"라고 부르는데 이는 잘못된 명칭입니다.
6.1 TEF 개요 TEF는 고성능 하이브리드의 구축 및 실행을 위한 설계 패턴입니다. smart contract SC. 하이브리드 smart contracts의 기본 아이디어에 따라 TEF에는 다음이 포함됩니다. SC를 두 부분으로 분해: (1) TEF 맥락에서 앵커라고 부르는 것 MAINCHAIN에서 SCa를 계약하고 (2) DON 로직은 TEF 실행 파일을 호출하도록 선택합니다. 여기서는 SCa의 조합으로 구현된 논리적 계약을 나타내기 위해 SC를 사용합니다. 그리고 실행하십시오. (위에서 언급했듯이 우리는 SC를 자동으로 이러한 구성 요소로 변환합니다.) TEF 실행 파일 exect는 SC에서 사용자의 트랜잭션을 처리하는 엔진입니다. 그것 DON에서 실행되므로 성능이 뛰어난 방식으로 실행될 수 있습니다. 여기에는 여러 가지 기능이 있습니다. • 트랜잭션 수집: Exect는 사용자의 트랜잭션을 수신하거나 가져옵니다. 그렇게 할 수 있다 직접, 즉 DON에 대한 거래 제출을 통해 또는 MAINCHAIN을 통해 MS를 이용한 멤풀. • 빠른 거래 실행: Exect는 자산과 관련된 거래를 처리합니다. SC. 즉, DON에서 로컬로 수행됩니다. • 빠르고 저렴한 oracle / 어댑터 액세스: exect는 oracle 보고서에 대한 기본 액세스 권한을 가집니다. 예를 들어 더 빠르고 저렴하며 더 정확한 자산으로 이어지는 기타 어댑터 데이터 MAINCHAIN 실행보다 가격이 책정됩니다. 게다가 오프체인 oracle 액세스가 감소합니다. oracle의 운영 비용, 즉 시스템 사용 비용 값비싼 온체인 스토리지. • 동기화: Exect는 주기적으로 DON의 업데이트를 MAINCHAIN에 푸시하여 SCa를 업데이트합니다. 앵커 계약은 SC의 MAINCHAIN 프런트 엔드입니다. SC의 신뢰도가 높은 구성 요소로서 다음과 같은 여러 목적을 수행합니다. • 자산 보관: 사용자의 자금은 SCa에 예치, 보관 및 인출됩니다. • 동기화 확인: SCa는 실행 시 상태 업데이트의 정확성을 확인할 수 있습니다. 동기화(예: rollups에 연결된 SNARK). • 가드레일: SCa에는 손상이나 고장으로부터 보호하기 위한 조항이 포함될 수 있습니다. 예를 들어. (자세한 내용은 섹션 7을 참조하세요.) TEF에서 사용자의 자금은 MAINCHAIN에 관리됩니다. 즉, DON 자체는 비관리적입니다. 선택한 동기화 메커니즘(아래 참조)에 따라 사용자는 다음이 필요할 수 있습니다. 정확한 oracle 보고서와 MAINCHAIN과의 적시 동기화를 위해서만 DON을 신뢰하십시오. 결과적인 신뢰 모델은 주문서 기반 DEX(예: [2])의 모델과 매우 유사합니다. 오늘날 여기에는 일반적으로 주문 매칭을 위한 오프체인 구성요소와 청산 및 결제를 위한 온체인 구성요소가 포함됩니다.지불 시스템의 용어를 사용하려면 exec를 구성 요소로 생각할 수 있습니다. SC는 청산을 담당하고 SCa는 결제를 담당합니다. 회로도는 그림 13을 참조하세요. TEF의 묘사. 그림 13: TEF 회로도. 이 예에서 트랜잭션은 mempool을 통과합니다. MS를 통해 MAINCHAIN을 DON로 보냅니다. TEF 혜택: TEF는 세 가지 주요 이점을 제공합니다. • 고성능: SC는 MAINCHAIN보다 DON의 훨씬 높은 처리량을 상속합니다. 거래 및 oracle 보고서 모두에 대해. 또한 Exect는 MAINCHAIN 단독 구현보다 트랜잭션을 더 빠르게 처리하고 oracle 보고서에 적시에 응답할 수 있습니다. • 낮은 수수료: 동기화 프로세스는 트랜잭션 처리보다 시간에 덜 민감하며 트랜잭션은 DON에서 MAINCHAIN으로 일괄적으로 전송될 수 있습니다. 결과적으로, 이 접근 방식을 사용하면 트랜잭션당 온체인 수수료(예: 가스 비용)가 MAINCHAIN에서만 실행되는 계약보다 훨씬 낮습니다. • 기밀성: DON의 기밀성 메커니즘을 가져올 수 있습니다. SC에 곰.
TEF 제한사항: TEF의 한 가지 제한 사항은 순간적인 기능을 지원하지 않는다는 것입니다. MAINCHAIN에서만 발생하는 출금: 출금 요청을 보낼 때 SCa에 대해 사용자는 exec가 포함된 상태 업데이트를 수행할 때까지 기다려야 할 수도 있습니다. 인출 거래가 승인되기 전에. 우리는 부분적인 해결 방법을 논의합니다. 그러나 섹션 6.2. TEF의 또 다른 제한 사항은 DeFi의 원자 구성을 지원하지 않는다는 것입니다. MAINCHAIN 계약, 특히 여러 DeFi을 통해 자산을 라우팅하는 기능 단일 거래로 계약을 체결합니다. 그러나 TEF는 이러한 원자성을 지원할 수 있습니다. DeFi 계약은 동일한 DON에서 실행됩니다. 또한 이 문제를 해결하는 몇 가지 방법에 대해서도 논의합니다. 6.2절의 문제. 6.2 거래 라우팅 SC에 대한 거래는 사용자가 DON로 직접 보내거나 다음을 통해 라우팅될 수 있습니다. MAINCHAIN의 멤풀(FSS를 통해). 4가지의 서로 다른 거래 유형이 있으며, 각각 그 중 다른 처리가 필요합니다. 계약 내 거래: TEF는 가스 역학의 복잡성을 회피하기 때문에 SC에 트랜잭션 처리에 있어 다른 것보다 더 많은 유연성을 제공합니다. 레이어-1 계약에서 사용 가능합니다. 예를 들어, Ethereum의 mempool 트랜잭션이 있는 동안 가스 가격이 더 높은 새로운 거래로 덮어쓸 수 있으며, SC는 SC 내 자산에서 운영되는 거래가 눈에 보이는 즉시 권위 있는 거래로 처리할 수 있습니다. 멤풀에서. 결과적으로 SC는 거래가 확인될 때까지 기다릴 필요가 없습니다. 블록 내에서 지연 시간이 크게 단축됩니다. 프록시: 사용자는 지갑 계약을 통해 SC에 거래 τ를 보내거나 MAINCHAIN의 다른 계약. DON에서 실행을 시뮬레이션하는 것이 가능합니다. MAINCHAIN에서 τ를 수행하여 SC에 대한 후속 트랜잭션이 발생하는지 여부를 결정합니다. 그렇다면 τ는 SC에 대한 다른 트랜잭션과 순서를 지정할 수 있습니다. 몇 가지가 있습니다 DON이 그러한 거래를 식별하는 방법에 대한 가능성: (1) DON은 시뮬레이션할 수 있습니다 mempool의 모든 트랜잭션(비용이 많이 드는 접근 방식) (2) 특정 계약 또는 지갑과 같은 계약 유형은 DON에 의해 모니터링을 위해 나열될 수 있습니다. 또는 (3) 사용자는 다음을 수행할 수 있습니다. DON 검사를 위해 거래에 주석을 답니다. 단일 거래가 두 거래와 상호 작용할 때 문제는 더욱 복잡해집니다. SC1 및 SC2 계약은 둘 다 Fair Sequencing Services를 사용하고 호환되지 않는 주문 정책을 가지고 있습니다. 예를 들어 DON은 가장 최근에 τ를 시퀀스할 수 있습니다. 그것은 둘 다와 호환됩니다. 예금: MAINCHAIN 자산을 SC에 예치하는 거래는 SC가 이를 유효한 것으로 처리하기 전에 블록에서 확인되어야 합니다. 채굴이 감지되면 자산(예: Ether)을 SCa로 보내는 거래는 즉시 확인할 수 있습니다.보증금. 예를 들어, DON에 대해 현재 oracle 보고된 가격을 적용할 수 있습니다. 자산. 인출: 위에서 언급했듯이 TEF의 한계는 인출이 항상 즉시 실행될 수 없다는 것입니다. rollup 유형 실행 모델에서는 철회가 요청은 안전하게 처리되기 위해 다른 트랜잭션과 순서대로 처리되어야 합니다. 즉, 롤업되어야 합니다. 처리됨. 그러나 이 제한 사항에 대한 몇 가지 부분적인 해결 방법이 있습니다. DON이 인출 트랜잭션까지 rollup 유효성 증명을 신속하게 계산할 수 있다면 mempool exect에서 사용자의 트랜잭션 τ를 관찰하면 일종의 유익한 선행 실행인 더 높은 가스 가격으로 τ에 대한 상태 업데이트 트랜잭션 τ'를 보낼 수 있습니다. τ'가 멤풀에 도달하기 전에 τ가 채굴되지 않으면 τ'가 τ보다 먼저 발생하고 τ가 채굴됩니다. 승인된 철회에 영향을 미칩니다. 상태 업데이트를 계산하기 위해 DON을 사용하는 TEF 변형에서(참조: 아래의 임계값 서명 변형), 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] 참조) 아래에서는 세 가지 주요 속성과 관련하여 이러한 동기화 옵션을 비교합니다. TEF: • 데이터 가용성: SC의 상태는 어디에 저장됩니까? 최소한 세 가지 옵션이 있습니다. TEF에서 사용 가능: MAINCHAIN, DON 또는 일부 타사 저장소에서 사용 가능 IPFS와 같은 공급자. 그들은 다양한 보안 보장, 가용성을 달성합니다. 수준 및 성능 프로필. 간략하게, MAINCHAIN에 상태를 저장하면 온체인 감사 가능성을 제공하고 상태 가용성에 대한 모든 당사자에 대한 의존성을 제거합니다. 반면에 상태를 오프체인에 저장하면 저장 비용을 줄이고 성능을 향상할 수 있습니다. 처리량은 신뢰할 수 있는 스토리지 제공업체(DON 또는 제3자)의 비용으로 데이터 가용성. 물론 이러한 옵션을 결합한 유연한 모델도 있습니다. 가능합니다. 표 1에는 필요한 데이터 가용성 형식이 나와 있습니다.• 정확성 보장: SCa는 업데이트의 정확성을 어떻게 확인합니까? exect에 의해 밀렸나요? 이는 Exect 및 SCa의 계산 부하에 영향을 미치며 동기화 대기 시간(아래 참조) • 지연 시간: 동기화 지연 시간에는 세 가지 요인이 있습니다. (1) 소요 시간 동기화 트랜잭션 τsync를 생성하기 위해; (2) τsync에 걸리는 시간 MAINCHAIN에서 확인됩니다. (3) τsync가 효과를 발휘하는 데 걸리는 시간 SCa. 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]은 상태 전환이 다음에 의해 영향을 받는 프로토콜입니다. 일괄 거래는 오프체인으로 계산됩니다. 그런 다음 상태 변경이 전파됩니다. MAINCHAIN에. rollups를 구현하기 위해 앵커 smart contract SCa는 실제 상태의 압축 표현 Rstate(예: Merkle 루트)를 저장합니다. 동기화하려면 Exec가 τsync =를 보냅니다. (티, R' 상태)를 SCa로 변환합니다. 여기서 T는 마지막 이후 처리한 트랜잭션 집합입니다.동기화 및 R' 상태는 다음을 적용하여 계산된 새 상태의 간략한 표현입니다. T의 이전 상태 Rstate로의 트랜잭션. SCa가 τsync에서 상태 업데이트를 확인하는 방법에는 두 가지 인기 있는 변형이 있습니다. 첫 번째 (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의 모든 데이터를 유지하지 않습니다. 구체적으로 exec는 새 항목만 보냅니다. 상태 및 증거는 있지만 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. TEF 동기화의 TEE 기반 변형은 다음을 통해 구현할 수 있습니다. 기술을 사용하여 (zk-)rollups 또는 Validium의 증명을 TEE 증명으로 대체합니다. [80]에서. rollups 및 Validium에서 사용되는 영지식 증명과 비교할 때 TEE는 더 성능이 좋습니다. 임계값 서명과 비교하여 TEE는 다음의 복잡성을 제거합니다. 원칙적으로 단 하나의 TEE만 필요하므로 임계값 ECDSA 서명을 생성합니다. 참여. 그러나 TEE를 사용하면 추가 하드웨어 종속 신뢰 가정이 도입됩니다. TEE를 임계값 서명과 결합하여 복원력을 생성할 수도 있습니다. 이 보호 조치는 TEE 인스턴스의 일부가 손상되는 것을 방지합니다. 임계값 ECDSA 서명 생성의 복잡성이 다시 도입되었습니다. 추가적인 유연성: 이러한 동기화 옵션은 다음과 같은 방법으로 더 많은 유연성을 제공하도록 구체화될 수 있습니다. • 유연한 트리거링: TEF 애플리케이션은 다음 조건을 결정할 수 있습니다. 동기화가 트리거됩니다. 예를 들어 동기화는 배치 기반일 수 있습니다. N개의 트랜잭션마다, 시간 기반(예: 10개 블록마다) 또는 이벤트 기반(예: 발생) 목표 자산 가격이 크게 움직일 때마다. • 부분 동기화: 가능하며 어떤 경우에는 바람직합니다(예: rollups, 부분 동기화는 대기 시간을 줄일 수 있음) 작은 것의 빠른 동기화를 제공하기 위해 상태 양, 아마도 주기적으로만 전체 동기화를 수행합니다. 예를 들어, exect는 SCa에서 사용자 잔액을 업데이트하여 출금 요청을 승인할 수 있습니다. MAINCHAIN 상태를 별도로 업데이트하지 않고. 6.4 재구성 네트워크 불안정 또는 51% 공격으로 인한 블록체인 재구성 메인체인의 무결성에 위협이 될 수 있습니다. 실제로, 적들은 다음과 같은 방법을 사용했습니다. 이중 지출 공격을 가하기 위해 [34]. 주요 체인에 대한 이러한 공격은 장착이 까다로우나 일부 체인에서는 여전히 실행 가능합니다([88]). MAINCHAIN과 독립적으로 작동하기 때문에 DON는 흥미로운 이점을 제공합니다. 다음과 관련된 재구성에 대한 일부 보호를 관찰하고 제공할 가능성 공격. 예를 들어, DON는 MAINCHAIN의 의존 계약 SC에 일부 임계 길이 τ의 경쟁 포크의 존재를 보고할 수 있습니다. DON은 추가적으로 가능합니다. 12보충 세부 정보는 부록 B.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
図 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가 기본적으로 서명하지 않기 때문에 생략한 데이터에 디지털 서명을 합니다. 데이터. TLS는 "핸드셰이크" 프로토콜에서 디지털 서명을 사용합니다. 서버와 클라이언트 사이의 공유 키). 따라서 HTTPS 지원 서버에는 인증서가 있습니다. 원칙적으로 데이터 서명에 사용할 수 있는 공개 키에 대해 일반적으로 사용하지는 않습니다. 데이터 서명을 지원하는 인증서입니다. 결과적으로 DON의 보안은 다음과 같습니다. 오늘날의 oracle 네트워크에서는 데이터에서 데이터를 충실하게 중계하는 oracle 노드에 의존합니다. 계약에 대한 소스입니다. Chainlink의 신뢰 최소화를 위한 우리 비전의 중요한 장기 구성 요소에는 데이터 서명을 위한 도구 및 표준 지원을 통한 더욱 강력한 데이터 소스 인증이 포함됩니다. 데이터 서명은 엔드투엔드 무결성 보장을 강화하는 데 도움이 될 수 있습니다. 원칙적으로 계약이 데이터가 직접 서명한 데이터 D 조각을 입력으로 수락하는 경우
그림 14: 이 섹션에서 논의된 신뢰 최소화 메커니즘의 위치. 1⃝데이터 소스는 데이터의 기능을 종속 항목에 전달하는 2⃝DON에 데이터를 제공합니다. 3⃝smart contract. 또한 DON 또는 oracle 네트워크에는 4⃝노드가 포함되어 있습니다. 보상 노드, 가드 등을 위한 MAINCHAIN의 smart contract 관리 레일 등. 소스가 있으면 oracle 네트워크는 D를 실질적으로 변조할 수 없습니다. 다양한 격려 OpenID Connect를 포함하여 이러한 데이터 서명을 활성화하려는 노력이 나타났습니다. 주로 사용자 인증을 위해 설계되었습니다. [9], TLS-N, 학술 프로젝트 TLS 인증서 및 TLS 증거 확장 [63]을 용도 변경하여 TLS [191]을 확장합니다. OpenID Connect가 일부 채택되었지만 TLS Evidence Extensions는 TLS-N은 아직 채택되지 않았습니다. 데이터 소스 인증의 또 다른 잠재적인 방법은 게시자의 자체 인증을 사용하는 것입니다. AMP(Accelerated Mobile Pages) 프로토콜 [225]의 일부로 콘텐츠 전달 네트워크에서 캐시할 수 있는 서명된 HTTP 교환(SXG) [230]. Chrome 모바일 브라우저는 AMP 캐시된 SXG의 콘텐츠를 마치 AMP에서 제공되는 것처럼 표시합니다. 캐시 서버 도메인 대신 게시자의 자체 네트워크 도메인. 이러한 브랜딩 인센티브는 CloudFlare의 실제 URL [83] 및 Google의 amppackager [124]과 같은 서비스를 사용하여 상대적으로 쉽게 활성화할 수 있다는 점과 결합되어 캐시된 뉴스 콘텐츠에 SXG를 널리 채택하게 할 수 있습니다. Chainlink oracles가 유효한 SXG에 보고된 뉴스 가치가 있는 이벤트에서 트리거되는 방법입니다. 뉴스 게시자의 AMP 캐시 SXG는 빠른 템포에는 유용하지 않습니다. 거래 데이터에 대한 보고서와 같은 애플리케이션은 사용자 정의를 위한 안전한 소스가 될 수 있습니다. 기상 이변이나 선거 결과와 같은 실제 사건과 관련된 계약. 우리는 간단한 배포, 성숙한 도구, 유연성이 핵심이라고 믿습니다. 데이터 소스 서명 가속화. 데이터 공급자가 Chainlink 노드를 다음과 같이 사용할 수 있도록 설정 인증된 API 프런트 엔드는 유망한 접근 방식으로 보입니다. 우리는네트워크 참여 여부에 관계없이 노드가 이 모드에서 작동하는 옵션 본격적인 oracle로. 우리는 이 기능을 인증된 데이터 생성이라고 부릅니다. (ADO). ADO와 함께 Chainlink 노드를 사용하면 데이터 소스가 이점을 얻을 수 있습니다. Chainlink 커뮤니티에서 개발한 경험과 도구를 통해 디지털 기능을 추가했습니다. 기존 오프체인 API 제품군에 서명 기능을 제공합니다. 그들은 달리기를 선택해야 할까요? 노드를 oracles로 사용하면 잠재적인 새로운 수익원을 추가로 열 수 있습니다. 기존 데이터 제공자와 동일한 모델(예: Kraken [28], Kaiko [140]) 다른 것들은 Chainlink 노드를 실행하여 체인에서 API 데이터를 판매합니다. 7.1.1 인증된 데이터 생성의 한계 데이터 소스에 의한 디지털 서명은 인증을 강화하는 데 도움이 될 수 있지만 그 자체로는 oracle의 모든 자연스러운 보안 또는 운영 목표를 달성하는 데 충분하지 않습니다. 네트워크. 우선, 주어진 데이터 D 조각은 여전히 강력하고 시기적절하게 전달되어야 합니다. 데이터 소스에서 smart contract 또는 다른 데이터 소비자로 가는 방법. 즉, 에서도 종속 항목에 사전 프로그래밍된 키를 사용하여 모든 데이터가 서명되는 이상적인 설정 계약을 체결하더라도 소스로부터 데이터를 안정적으로 전달하려면 DON이 여전히 필요합니다. 계약에. 또한 계약이나 기타 oracle-데이터가 소비자는 계산된 다양한 기능의 인증된 출력에 액세스하기를 원합니다. 두 가지 주요 이유는 소스 데이터입니다. • 기밀성: 데이터 소스 API는 민감하거나 독점적인 데이터를 제공할 수 있습니다. 체인에 공개되기 전에 수정하거나 정리해야 합니다. 그러나 서명된 데이터를 수정하면 서명이 무효화됩니다. 다른 것을 넣어 그런데 순진한 ADO와 데이터 삭제는 호환되지 않습니다. 예제 3에 나와 있습니다. 향상된 형태의 ADO를 통해 이 둘을 어떻게 조화시킬 수 있는지 알아보세요. • 데이터 소스 오류: 오류와 실패 모두 데이터 소스에 영향을 미칠 수 있으며 디지털 서명은 두 가지 문제를 모두 해결하지 못합니다. [98], Chainlink은 처음부터 이러한 결함을 해결하기 위한 메커니즘인 중복성이 이미 포함되어 있습니다. oracle 네트워크에서 발행한 보고서는 일반적으로 여러 네트워크의 결합된 데이터를 나타냅니다. 소스. 이제 소스 데이터의 기밀성을 강화하고 여러 소스의 데이터를 안전하게 결합하기 위해 ADO 설정에서 탐색 중인 구성표에 대해 논의합니다. 7.1.2 기밀성 데이터 소스는 원하는 API의 전체 영역을 예상하고 제공하지 못할 수 있습니다. 사용자에 의해. 특히 사용자는 사전 처리된 데이터에 액세스하여 다음을 보장할 수 있습니다. 기밀성. 다음 예에서는 문제를 보여줍니다.예시 3. Alice는 다음과 같은 DID(분산 신원) 자격 증명을 얻고 싶어합니다. 그녀는 18세 이상이어야 합니다(예를 들어 대출을 받을 수 있음). 해야 할 일 따라서 그녀는 자신의 나이에 대한 사실을 DID 자격 증명 발급자에게 증명해야 합니다. Alice는 자신이 거주하는 주의 DMV(Department of Motor Vehicles)의 데이터를 사용하기를 원합니다. 목적으로 웹사이트. DMV는 그녀의 생년월일 기록을 가지고 있으며 다음 형식의 디지털 서명된 증명 A: A = {이름: Alice, DoB: 1999년 2월 16일}. 이 예에서 증명 A는 Alice가 DID에 증명하기에 충분할 수 있습니다. 하지만 이는 민감한 정보를 불필요하게 유출합니다: Alice의 정확한 DoB. 이상적으로는 Alice가 DMV에서 원하는 것은 자동차 보험에 서명하는 것입니다. “앨리스는 18세 이상입니다.”라는 간단한 진술 A'입니다. 즉, 그녀는 그녀의 생일 X에 대한 함수 G의 출력. 여기서 (비공식적으로) A′ = G(X) = True인 경우 현재 날짜 −X ≥18년; 그렇지 않으면 G(X) = 거짓입니다. 일반화하자면, Alice는 데이터 소스로부터 서명된 데이터를 요청할 수 있기를 원합니다. 다음 형식의 증명 A': A′ = {이름: Alice, Func:G(X), 결과: True}, 여기서 G(X)는 함수 G와 그 입력 X의 사양을 나타냅니다. 사용자는 자신의 요청에 따라 원하는 G(X)를 입력으로 제공할 수 있어야 합니다. 해당 증명 A'. 데이터 소스의 증명 A'에는 사양 G(X)가 포함되어야 합니다. A'가 올바르게 해석되었는지 확인하세요. 위의 예에서 G(X)는 다음 의미를 정의합니다. A'의 부울 값이므로 True는 증명의 주제를 의미합니다. 18세 이상입니다. 우리는 사용자가 G(X)를 기능적 쿼리로 지정할 수 있는 유연한 쿼리를 참조합니다. 예제 3과 같은 사용 사례와 쿼리와 관련된 사용 사례를 지원하기 위해 계약에서 직접적으로 다음과 관련된 기능적 쿼리에 대한 지원을 포함할 계획입니다. ADO의 일부인 간단한 함수 G. 7.1.3 소스 데이터 결합 온체인 비용을 줄이기 위해 계약은 일반적으로 결합된 데이터를 소비하도록 설계됩니다. 다음 예에 설명된 것처럼 여러 소스에서 가져옵니다. 예 4(가격 데이터 중위화) 가격 피드 제공, 즉 하나의 가치 자산(예: ETH)을 다른 자산(예: USD)에 비해 oracle 네트워크는 일반적으로 거래소 등 다양한 소스에서 현재 가격을 얻습니다. oracle 네트워크 일반적으로 이러한 값의 중앙값을 종속 계약 SC에 보냅니다. 데이터 서명이 있는 환경에서 올바르게 작동하는 oracle 네트워크는 데이터 소스 S = {S1, . . . , SnS} 값의 시퀀스 V = {v1, v2, . . . , vnS} 에서 소스별 서명이 수반되는 nS 소스 Σ = {σ1, σ2, . . . , σnS}. 시 서명을 확인한 후 가격 v = 중앙값(V)을 SC로 전송합니다.불행하게도 oracle 네트워크가 중앙값을 전송하는 간단한 방법은 없습니다. v가 올바르게 계산되었다는 간결한 증거 σ와 함께 예제 4의 v 값을 SC에 전달합니다. 과도하게 서명된 입력. 순진한 접근 방식은 SC에서 모든 nS 데이터 소스의 공개 키를 인코딩하는 것입니다. 그런 다음 oracle 네트워크는 (V, Σ)를 중계하고 SC가 V의 중앙값을 계산하도록 허용합니다. 그러나 이는 크기 O(nS)의 증명 σ가 됩니다. 즉, σ는 간결하지 않습니다. 또한 모든 서명을 확인해야 하는 SC에 높은 가스 비용이 발생합니다. Σ. 이와 대조적으로 SNARK를 사용하면 올바르게 결합된 인증된 소스 값에 대한 간결한 증거가 가능합니다. 실제로 실행 가능할 수도 있지만 상당히 높은 수준을 부과합니다. 증명자의 계산 비용과 체인의 가스 비용이 다소 높습니다. 사용 Town Crier도 가능하지만 TEE를 사용해야 하므로 모든 사람에게 적합하지는 않습니다. 사용자의 신뢰 모델. 소스에서 결합된 데이터에 서명하는 일반적인 문제에 대한 솔루션을 구성하는 유용한 개념은 기능 서명으로 알려진 암호화 도구입니다[59, 132]. 간단히 말해서, 기능적 서명을 통해 서명자는 다음과 같은 서명 기능을 위임할 수 있습니다. 위임자는 서명자가 선택한 함수 F 범위의 메시지에만 서명할 수 있습니다. 우리는 부록 D에서 이 기능적 제약이 어떻게 범위를 제한하는 역할을 할 수 있는지 보여줍니다. 데이터 소스에서 서명된 값의 함수로 DON에서 내보내는 보고서 값입니다. 또한 정확성에 대한 완화된 요구 사항을 포함하지만 잠재적으로 훨씬 더 성능이 뛰어난 이산화된 기능 시그니처라고 하는 새로운 기본 요소를 도입합니다. SNARK와 같은 접근 방식보다. 소스 인증을 포함하는 방식으로 데이터 소스를 결합하는 문제 출력은 CoinCap, CoinMarketCap, CoinGecko와 같은 데이터 수집자에도 적용됩니다. 다양한 거래소로부터 데이터를 얻는 CryptoCompare 등 경우에 따라 공개하는 방법론을 사용하여 부피에 따른 무게 다른 경우에는 독점적입니다. 다음과 같은 값을 게시하려는 수집자 소스 인증은 노드 집합과 동일한 문제에 직면합니다. 소스 데이터. 7.1.4 소스 데이터 처리 정교한 smart contract은 사용자 정의 집계 통계에 의존할 가능성이 높습니다. 많은 자산에 대한 최근 가격 기록의 변동성과 같은 기본 데이터 소스 또는 관련 사건에 대한 뉴스의 텍스트 및 사진. DON에서는 계산 및 대역폭이 상대적으로 저렴하기 때문에 이러한 통계는 — 입력이 많은 복잡한 기계 학습 모델이라도 blockchain에 대한 출력 값이 충분히 간결하다면 경제적으로 처리할 수 있습니다. DON 참가자가 서로 다를 수 있는 계산 집약적인 작업의 경우 복잡한 입력에 대한 견해가 있는 경우 결과를 계산하기 전에 입력에 대한 합의를 확립하기 위해 DON 참가자 간의 추가 의사소통이 필요할 수 있습니다. 최종 값이 입력에 의해 완전히 결정되는 한, 입력 합의가 확립되면 각 참가자는 간단히 값을 계산하여 다른 참가자에게 알릴 수 있습니다.참가자는 부분 서명을 사용하거나 이를 수집자에게 보냅니다. 7.2 DON 신뢰 최소화 우리는 DON 구성 요소에 대한 신뢰를 최소화하는 두 가지 주요 방법을 구상합니다. 장애 조치 클라이언트 및 소수 보고서. 7.2.1 장애 조치 클라이언트 암호화 및 분산 시스템 문헌의 적대적 모델은 일반적으로 노드의 하위 집합을 손상(즉, 손상)할 수 있는 공격자를 고려합니다. 예를 들어 많은 BFT 프로토콜의 경우 1/3 미만입니다. 흔히 관찰되지만, 모든 노드가 동일한 소프트웨어를 실행하는 경우 치명적인 공격을 식별한 공격자는 원칙적으로 모든 노드를 어느 정도 동시에 손상시킵니다. 이 설정은 종종 소프트웨어 단일 문화라고 합니다 [47]. 문제를 해결하기 위해 소프트웨어 및 소프트웨어 구성을 자동으로 다양화하기 위한 다양한 제안이 제시되었습니다(예: [47, 113]). [47]에 명시된 바와 같이, 그러나 소프트웨어 다양성은 복잡한 문제이므로 신중한 고려가 필요합니다. 예를 들어, 소프트웨어 다양화는 다음과 같은 경우 단일 문화보다 더 나쁜 보안을 초래할 수 있습니다. 시스템의 공격 표면을 증가시켜 가능한 공격 벡터를 초과합니다. 그것이 제공하는 보안 이점. 우리는 강력한 장애 조치 클라이언트(즉, 노드가 연결되는 클라이언트)에 대한 지원이 가능하다고 믿습니다. 재앙이 닥쳤을 때 전환할 수 있다는 점은 특히 매력적인 형태입니다. 소프트웨어 다양화. 장애 조치 클라이언트는 잠재적 벡터 수를 늘리지 않습니다. 공격의 위험이 있습니다. 메인라인 소프트웨어로 배포되지 않기 때문입니다. 그들은 분명한 이점을 제공합니다. 그러나 두 번째 방어선으로 사용됩니다. 우리는 DONs에서 장애 조치 클라이언트를 다음과 같이 지원할 계획입니다. 단일 클라이언트에 대한 보안 의존도를 줄이는 주요 수단입니다. Chainlink에는 이미 강력한 장애 조치 클라이언트 시스템이 마련되어 있습니다. 우리의 접근 방식 철저한 테스트를 거친 이전 클라이언트 버전을 유지 관리하는 작업이 포함됩니다. 예를 들어 현재 OCR(오프체인 보고)을 기본 클라이언트로 사용하는 Chainlink 노드에는 지원이 포함됩니다. 필요한 경우 Chainlink의 이전 FluxMonitor 시스템용. 일부 사용 중이던 FluxMonitor는 보안 감사와 현장 테스트를 받았습니다. 그것은 동일한 것을 제공합니다 OCR 기능을 더 높은 비용으로 제공합니다. 비용은 필요할 때만 발생합니다. 7.2.2 마이너리티 리포트 충분히 큰 소수 집합이 주어지면 소수(다수의 불법 행위를 관찰하는 정직한 노드의 일부)가 소수를 생성하는 데 도움이 될 수 있습니다. 보고. 이는 종속 계약 SC 온체인에 전달되는 병렬 보고서 또는 플래그입니다. Ominority에 의해. SC는 자체 계약별 정책에 따라 이 플래그를 사용할 수 있습니다. 예를 들어, 생명력이나 반응성보다 안전이 더 중요한 계약의 경우 소수 보고서로 인해 계약에서 보충 보고서를 요청할 수 있습니다. 다른 DON에서 연결하거나 회로 차단기를 작동시키세요(다음 섹션 참조).다수가 정직할 때에도 소수 보고서는 중요한 역할을 할 수 있으며, 왜냐하면 모든 보고서 집계 체계는 기능적 서명을 사용하더라도 oracle 또는 데이터 오류에 대한 복원력을 보장하기 위해 임계값 방식으로 작동합니다. 에서 즉, 입력 내용을 기반으로 유효한 보고서를 생성하는 것이 가능해야 합니다. kS < nS oracles, 일부 임계값 kS의 경우. 이는 손상된 DON에 일부 오류가 있음을 의미합니다. 다음 중에서 선호하는 kS 값을 선택하여 보고서 값을 조작할 수 있는 위도 모든 소스가 정직하더라도 oracle 전체 세트에 의해 V에서 보고된 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가 더 높은 보안을 제공하는 상황에 결과 메커니즘을 적용합니다. 플랫폼보다 그 반대입니다.) 따라서 자연스러운 신뢰 최소화 전략에는 MAINCHAIN 프런트 엔드에서 smart contracts의 모니터링 및 안전 장치 메커니즘 구현이 포함됩니다. DON의 경우 또는 종속 계약 SC에서 직접. 우리는 이러한 메커니즘을 다음과 같이 지칭합니다. 가드레일을 확인하고 여기에 가장 중요한 사항을 열거하세요. • 회로 차단기: SC는 상태 업데이트 자체의 특성에 따라 상태 업데이트를 일시 중지하거나 중지할 수 있습니다(예: 순차 업데이트에 대한 큰 차이). 보고서) 또는 기타 입력을 기반으로 합니다. 예를 들어 회로 차단기가 작동할 수 있습니다. oracle 보고서가 시간이 지남에 따라 믿을 수 없을 정도로 변하는 경우입니다. 회로 차단기가 또한 소수 보고서에 의해 넘어질 수도 있습니다. 따라서 회로 차단기는 DONs를 방지할 수 있습니다. 심하게 잘못된 보고를 하는 것으로부터. 회로 차단기는 추가 개입을 고려할 시간을 제공할 수 있습니다. 아니면 운동을 했는지. 그러한 개입 중 하나는 탈출구입니다. • 탈출구: 일련의 관리인, 커뮤니티 token 보유자 또는 기타 수탁자 기관이 확인한 불리한 상황에서 계약이 실행될 수 있습니다. 탈출구 [163]라고도 불리는 비상 시설. 탈출용 해치 SC가 어떤 방식으로든 종료되거나 보류 중으로 종료됩니다. 미래 거래. 예를 들어, 보관된 자금을 사용자 [17])에게 반환할 수 있습니다.계약 조건을 종료하거나([162]) 보류 중인 거래 및/또는 향후 거래를 취소할 수 있습니다([173]). 탈출 해치는 계약 유형뿐만 아니라 모든 유형의 계약에 배치될 수 있습니다. DON에 의존하지만 잠재적인 완충 장치로 관심이 있습니다. DON 불법 행위. • 장애 조치: SC가 필수 서비스를 위해 DON에 의존하는 시스템에서는 SC가 서비스 지속을 보장하는 장애 조치 메커니즘을 제공할 수 있습니다. DON 실패 또는 잘못된 행동의 경우. 예를 들어, TEF(섹션 6)에서는 앵커 계약 SCa는 온체인과 특정 중요 작업에 대해 오프체인 실행 인터페이스가 지원됩니다(예: 인출) 또는 일반 거래의 경우 DON 거래의 선취를 방지하기 위해 적절한 지연이 있습니다. 데이터 소스가 데이터에 서명하는 경우 사용자는 다음을 수행할 수 있습니다. 또한 DON이 실패할 경우 SCa에 보고서를 제공합니다. 다양한 형태의 낙관적 rollup(섹션 6.3 참조)에 대해 제안된 사기 증명, 위에서 열거한 메커니즘과 맛이 유사하고 보완적입니다. 그들은 또한 온체인 모니터링의 형태를 제공하고 잠재적인 오류에 대한 보호를 제공합니다. 오프체인 시스템 구성요소. 7.4 신뢰를 최소화한 거버넌스 모든 분산형 시스템과 마찬가지로 Chainlink 네트워크에는 거버넌스 메커니즘이 필요합니다. 시간이 지남에 따라 매개변수를 조정하고, 긴급 상황에 대응하고, 진화를 안내합니다. 이러한 메커니즘 중 일부는 현재 MAINCHAIN에 있으며 앞으로도 계속될 수 있습니다. DON을 배포하더라도 그렇게 할 수 있습니다. 한 가지 예는 결제 메커니즘입니다. oracle 노드 공급자(DON 노드)의 경우. DON MAINCHAIN의 프런트 엔드 계약 가드레일과 같이 주기적으로 영향을 받을 수 있는 추가 메커니즘이 포함되어 있습니다. 수정. 우리는 진화적 메커니즘과 비상사태라는 두 가지 종류의 거버넌스 메커니즘을 예상합니다. 진화적 거버넌스: Chainlink 생태계에 대한 많은 수정 사항은 다음과 같습니다. 구현이 긴급한 문제가 되지 않도록: 성능 개선, 기능 향상, (긴급하지 않은) 보안 업그레이드 등. Chainlink이(가) 거버넌스에 더 많은 참여자를 향해 점진적으로 나아감에 따라 우리는 더 많은 또는 이러한 변경 사항의 대부분은 해당 변경 사항의 영향을 받은 특정 DON 커뮤니티에 의해 비준됩니다. 변화. 그 동안 그리고 아마도 궁극적으로는 병렬 메커니즘으로서 우리는 다음과 같이 믿습니다. 시간적 최소 특권의 개념은 진화적 거버넌스를 구현하는 데 유용한 수단이 될 수 있습니다. 아주 간단히 말하면, 변경 사항을 점진적으로 배포하여 다음을 보장하는 것입니다. 커뮤니티는 이에 대응할 수 있는 기회를 제공합니다. 예를 들어, 새로운 MAINCHAIN 계약은 새로운 계약을 배포해야 하도록 제한될 수 있습니다. 활성화하기 최소 30일 전.비상 거버넌스: MAINCHAIN의 악용 가능하거나 악용된 취약점 계약이나 기타 형태의 활성 또는 안전 오류는 치명적인 결과를 방지하기 위해 즉각적인 개입이 필요할 수 있습니다. 우리의 의도는 다중서명을 지원하는 것입니다. 모든 조직의 불법 행위를 방지하기 위한 개입 메커니즘 서명자는 여러 조직에 분산됩니다. 서명자의 일관된 가용성 보장 비상사태 승인을 위해 적절한 명령 체계에 대한 시기적절한 접근 변경 사항을 적용하려면 신중한 운영 계획과 정기적인 검토가 필요합니다. 이것들 과제는 다른 사이버 보안 사고 대응 테스트와 관련된 과제와 유사합니다. 기능 [134], 경계 감소 [223]과 같은 일반적인 문제를 해결하기 위한 유사한 필요성이 있습니다. DONs의 거버넌스는 많은 분산형 시스템의 거버넌스와 다릅니다. 잠재적인 이질성 정도. 각 DON에는 고유한 데이터 소스, 실행 파일, 가동 시간과 같은 서비스 수준 요구 사항 및 사용자가 있을 수 있습니다. Chainlink 네트워크의 거버넌스 메커니즘은 이러한 변화를 수용할 수 있을 만큼 유연해야 합니다. 운영 목표 및 매개변수. 우리는 디자인 아이디어를 적극적으로 탐구하고 있으며, 앞으로 이 주제에 대한 연구를 발표하세요. 7.5 공개 키 인프라 점진적인 분권화로 인해 강력한 식별이 필요해집니다. DON 노드를 포함한 네트워크 참가자. 특히 Chainlink에는 강력한 공개 키 인프라(PKI). PKI는 키를 ID에 바인딩하는 시스템입니다. 에 대한 예를 들어 PKI는 인터넷의 보안 연결(TLS) 시스템을 뒷받침합니다. HTTPS(예: https://www.chainlinklabs.com)을 통해 웹사이트에 연결하고 브라우저에 자물쇠가 나타나면 이는 도메인 소유자의 공개 키가 특히 디지털 서명을 통해 권한에 의해 해당 소유자에게 바인딩되었습니다. 일명 자격증. 최상위 루트 인증 기관이 널리 사용되는 브라우저에 내장되어 있는 CA(인증 기관)의 계층적 시스템은 인증서가 합법적인 도메인 소유자에게만 발급됩니다. 우리는 Chainlink이 결국 분산형 이름 서비스를 사용할 것으로 예상합니다. 처음에는 Ethereum 이름 서비스(ENS) [22]를 PKI의 기반으로 삼았습니다. 다음과 같이 이름에서 알 수 있듯이 ENS는 매핑을 수행하는 도메인 이름 시스템인 DNS와 유사합니다. (사람이 읽을 수 있는) 도메인 이름을 인터넷의 IP 주소로 변환합니다. 그러나 ENS는 대신 사람이 읽을 수 있는 Ethereum 이름을 blockchain 주소에 매핑합니다. 왜냐하면 ENS Ethereum blockchain에서 작동하며 키 손상을 방지하고 네임스페이스는 원칙적으로 이를 관리하는 계약을 변조하는 것만큼 어렵습니다. 및/또는 기본 blockchain. (반대로 DNS는 역사적으로 취약했습니다. 스푸핑, 하이재킹 및 기타 공격에 사용됩니다.) 우리는 Ethereum 메인넷의 ENS에 data.eth를 등록했으며, oracle 데이터 서비스의 ID가 있는 루트 네임스페이스로 설정하고 다른 Chainlink 네트워크 엔터티가 상주합니다. ENS의 도메인은 계층적입니다. 즉, 각 도메인에 참조가 포함될 수 있습니다. 그 아래 다른 이름으로. ENS의 하위 도메인은 구성 및 관리 방법으로 사용될 수 있습니다.신뢰를 위임합니다. data.eth의 주요 역할은 온체인 디렉터리 서비스 역할을 하는 것입니다. 데이터 피드. 전통적으로 oracles의 개발자와 사용자는 오프체인 소스를 사용해 왔습니다. (예: docs.chain.link 또는 data.chain.link와 같은 웹사이트 또는 다음과 같은 소셜 네트워크 Twitter) oracle 데이터 피드 주소(예: ETH-USD 가격)를 게시하고 획득합니다. 피드). data.eth와 같이 매우 신뢰할 수 있는 루트 네임스페이스를 사용하면 대신 eth-usd.data.eth를 smart contract 주소에 매핑하는 것이 가능합니다. ETH-USD 가격 피드에 대한 온체인 oracle 네트워크 수집기. 이것은 누구든지 blockchain를 정보 소스로 참조할 수 있는 보안 경로를 만듭니다. 해당 가격/이름 쌍(ETH-USD)의 데이터 피드입니다. 결과적으로 ENS를 사용하는 방법은 다음과 같습니다. 오프체인 데이터 소스에서는 얻을 수 없는 두 가지 이점을 실현합니다. • 강력한 보안: 도메인에 대한 모든 변경 사항과 업데이트는 불변하게 기록됩니다. 웹사이트의 텍스트 주소와 달리 암호화 방식으로 보호됩니다. 이 두 가지 보안 속성 중 어느 것도 누리지 마십시오. • 자동화된 온체인 전파: 데이터피드의 smart contract 기본 주소를 업데이트하면 종속 스마트에 전파되는 알림이 트리거될 수 있습니다. 예를 들어 종속 계약을 자동으로 업데이트할 수 있습니다. 새 주소.13 그러나 ENS와 같은 네임스페이스는 합법적인 소유권을 자동으로 확인하지 않습니다. 주장된 이름의. 따라서 예를 들어 네임스페이스에 항목이 포함된 경우 ⟨"Acme Oracle Node Co.", 주소⟩, 그런 다음 사용자는 addr이 Acme라는 이름의 청구자에 속한다는 확신을 얻습니다. Oracle Node Co.는 네임스페이스 관리에 대한 추가 메커니즘 없이 그러나 그녀는 그 이름이 합법적으로 법인에 속해 있다는 확신을 얻지 못합니다. 의미 있는 현실 세계의 의미에서 Acme Oracle Node Co.라고 불립니다. 이름 검증, 즉 상응하는 합법적인 실제 개체의 소유권을 보장하는 우리의 접근 방식은 여러 구성 요소에 의존합니다. 오늘은 Chainlink 연구소 Chainlink 네트워크에 대한 CA 역할을 효과적으로 수행합니다. Chainlink 실습은 계속됩니다. 이름을 검증하기 위해 PKI는 두 가지 방법으로 보다 분산된 모델로 발전할 것입니다. • 신뢰 웹 모델: 계층적 PKI의 분산형 대응물을 종종 신뢰 웹이라고 합니다.14 변형은 1990년대부터 제안되었습니다. 예를 들어 [98], 그리고 많은 연구자들은 blockchains가 전 세계적으로 일관된 인증서를 기록함으로써 아이디어(예: [227])의 사용을 용이하게 할 수 있음을 관찰했습니다. 원장. 우리는 엔터티의 신원을 검증하기 위해 이 모델의 변형을 탐색하고 있습니다. Chainlink 네트워크에서 보다 분산된 방식으로. 13A 종속 계약은 선택적으로 수동 검사를 허용하기 위해 미리 결정된 지연을 포함할 수 있습니다. 종속 계약 관리자의 개입. 14PGP [238]에 대해 Phil Zimmermann이 만든 용어입니다.• 검증 데이터에 대한 연결: 오늘날 상당한 양의 oracle 노드 성능 데이터가 온체인에서 볼 수 있으므로 노드 주소에 보관됩니다. 이러한 데이터는 네트워크에 (신뢰할 수 있는) 참여에 대한 역사적 증거를 제공함으로써 PKI의 정체성을 강화하는 것으로 볼 수 있습니다. 추가적으로 도구 DECO 및 Town Crier [160] 활성화 노드를 기반으로 한 분산 ID용 실제 데이터에서 파생된 자격 증명을 축적합니다. 한 가지 예로서, 노드 운영자는 소유를 증명하는 PKI 신원에 자격 증명을 첨부할 수 있습니다. Dun and Bradstreet 등급입니다. 이러한 보완적인 검증 형태는 다음과 같습니다. 네트워크 보안을 보장할 때 staking을 보완하세요. 실제 신원이 확립된 oracle 노드는 지분을 보유한 것으로 간주될 수 있습니다. 그 명성에서 비롯된 시스템에서. (섹션 4.3 및 섹션 9.6.3 참조) Chainlink PKI의 최종 요구 사항은 보안 부트스트래핑입니다. Chainlink 네트워크의 루트 이름, 현재 data.eth 게시(유사하게) 브라우저의 최상위 도메인을 하드와이어링합니다. 즉, Chainlink 사용자는 어떻게 data.eth가 실제로 Chainlink과 연결된 최상위 도메인인지 확인합니다. 프로젝트? Chainlink 네트워크의 이 문제에 대한 해결책은 다각적이며 다음이 포함될 수 있습니다: • 다음을 지정하는 chain.link의 도메인 레코드에 TXT 레코드 [224] 추가 data.eth를 Chainlink 생태계의 루트 도메인으로 사용합니다. (따라서 Chainlink은 루트 ENS 도메인의 유효성을 검사하기 위해 인터넷 도메인에 대한 PKI를 암시적으로 활용합니다.) • Chainlink의 기존 웹사이트(예: https://docs.chain.link. (인터넷 도메인에 대한 PKI의 또 다른 암시적 사용) • 본 백서를 포함한 다양한 문서를 통해 data.eth의 사용을 알립니다. • Twitter와 같은 소셜 미디어 채널에 data.eth를 공개적으로 게시합니다. 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 배포 고려 사항
핵심 설계의 일부는 아니지만 몇 가지 중요한 기술적 고려 사항이 있습니다. 여기서 치료받을 가치가 있는 DON을 실현합니다.
8.1 출시 접근 방식 이 문서에서는 고급 Chainlink 기능에 대한 야심찬 비전을 제시합니다. 이를 실현하려면 그 과정에서 많은 과제에 대한 솔루션이 필요합니다. 이 백서 몇 가지 문제를 식별하지만 예상치 못한 문제도 발생할 수 있습니다. 우리는 이 비전의 요소를 점진적인 방식으로 구현할 계획입니다. 연장된 기간. 우리는 DONs가 처음에 다음과 같이 출시될 것으로 예상합니다. 내부 팀이 공동으로 구축한 사전 구축된 특정 구성 요소에 대한 지원 Chainlink 커뮤니티. 의도는 DON을 더 광범위하게 사용하는 것입니다. 임의의 실행 파일을 실행하면 나중에 지원될 예정입니다. 이러한 주의가 필요한 한 가지 이유는 최근 플래시 대출 기반 공격이 예를 들어 [127, 189]에 표시되어 있습니다. 마찬가지로 smart contract, 어댑터 및 실행 파일에는 극도의 주의가 필요합니다. DONs의 초기 배포에서는 사전 구축된 템플릿화된 실행 파일 및 어댑터 세트만 포함할 계획입니다. 이를 통해 구성 보안에 대한 연구가 가능해집니다. 공식적인 방법 [46, 170] 및 기타 접근 방식을 사용하여 이러한 기능을 수행합니다. 그럴 것이다 또한 가격 책정을 단순화합니다. 기능 가격 책정은 채택된 접근 방식인 일반화된 측정을 통하지 않고 기능별로 DON 노드별로 설정할 수 있습니다. 예: [156]. 우리는 또한 Chainlink 커뮤니티가 창작에 참여할 것으로 기대합니다. 다양한 어댑터와 실행 파일을 점점 더 많이 결합하는 추가 템플릿 수천 명은 아니더라도 수백 명이 운영할 수 있는 유용한 분산형 서비스 DONs. 또한 이 접근 방식은 상태 팽창(즉, DON의 필요성)을 방지하는 데 도움이 될 수 있습니다. 작업 메모리에 작업할 수 없는 양의 상태를 유지하는 노드입니다. 이 문제는 무허가형 blockchains에서 이미 발생하고 있으며, "상태 비저장"과 같은 접근 방식에 동기를 부여합니다. 클라이언트”(예: [206] 참조). 처리량이 높은 시스템에서는 더욱 심각해질 수 있습니다. DON이 상태 크기에 최적화된 실행 파일만 배포하는 접근 방식입니다. DON이 발전하고 성숙해지며 섹션 7에 설명된 강력한 가드레일, 섹션 9에 설명된 암호화폐 경제 및 평판 기반 보안 메커니즘, DON 사용자에게 높은 수준의 보증을 제공하는 기타 기능을 포함함에 따라 우리는 또한 보다 광범위한 출시와 사용을 촉진하기 위한 프레임워크와 도구를 개발할 것으로 예상됩니다. DONs는 커뮤니티에서 제공합니다. 이상적으로 이러한 도구는 노드 운영자 모음을 활성화합니다. oracle 네트워크로 함께 모여서 무허가 환경에서 자신만의 DON을 시작합니다. 또는 셀프 서비스 방식으로 일방적으로 그렇게 할 수 있음을 의미합니다. 8.2 동적 DON 멤버십 특정 DON을 실행하는 노드 집합은 시간이 지남에 따라 변경될 수 있습니다. 두 가지 접근 방식이 있습니다. O의 동적 멤버십을 통해 SKL의 키 관리에 사용됩니다. 첫 번째는 멤버십 변경 시 노드가 보유한 SKL의 지분을 업데이트하는 것입니다. pkL을 변경하지 않고 유지합니다. [41, 161, 198]에서 탐구된 이 접근법은 장점이 있습니다. 신뢰 당사자가 pkL을 업데이트하도록 요구하지 않습니다.[122]에 도입된 전통적인 공유 재공유 기술은 다음과 같은 간단한 기능을 제공합니다. 그리고 그러한 공유 업데이트를 실현하는 효율적인 방법입니다. 비밀을 전송할 수 있게 해줍니다. 한 세트의 노드 O(1)과 두 번째 노드 사이에서, 아마도 하나의 O(2)와 교차할 수 있습니다. 이에 접근 방식, 각 노드 O(1) 나 전체에서 비밀 공유의 (k(2), n(2)) 비밀 공유를 수행합니다. n(2) = |O(2)|에 대한 O(2)의 노드 그리고 원하는(아마도 새로운) 임계값 k(2). 다양한 VSS(검증 가능한 비밀 공유) 체계 [108]는 다음과 같은 공격자에 대한 보안을 제공할 수 있습니다. 노드를 적극적으로 손상시킵니다. 즉, 프로토콜에 악의적인 동작을 도입합니다. [161]의 기술은 통신 복잡성을 줄이고 다음을 제공하는 동시에 이를 수행하는 것을 목표로 합니다. 암호화 경도 가정의 실패에 대한 탄력성. 두 번째 접근 방식은 원장 키 pkL을 업데이트하는 것입니다. 이는 앞으로의 이점이 있습니다. 보안: pkL의 오래된 공유(예: 이전 위원회 노드)가 손상되지 않습니다. 현재 키가 손상될 수 있습니다. 그러나 pkL 업데이트에는 두 가지 단점이 있습니다. (1) pkL로 암호화된 데이터는 키 새로 고침 중에 다시 암호화되어야 하며 (2) 주요 업데이트는 신뢰 당사자에게 전파되어야 합니다. 우리는 두 가지 접근 방식과 두 가지의 하이브리드화를 모두 탐색할 계획입니다. 8.3 DON 책임 기존 Chainlink oracle 네트워크와 마찬가지로 DONs에는 올바른 노드 동작을 기록, 모니터링 및 시행하는 책임 메커니즘이 포함됩니다. DON은(는) 기존의 많은 무허가 blockchain보다 훨씬 더 많은 데이터 용량, 특히 외부 분산 저장소에 연결할 수 있다는 점을 고려하면 더욱 그렇습니다. 결과적으로 노드의 성능 내역을 자세히 기록할 수 있게 됩니다. 보다 세분화된 책임 메커니즘. 예를 들어, 오프체인 계산은 다음과 같습니다. 자산 가격에는 중간 결과가 전송되기 전에 폐기되는 입력이 포함될 수 있습니다. 체인. DON에는 이러한 중간 결과가 기록될 수 있습니다. 따라서 DON의 개별 노드에 의한 오작동 또는 성능 저하가 해결되거나 처벌될 수 있습니다. DON을 세밀하게 처리합니다. 우리는 구축 방법에 대해서도 추가로 논의했습니다. 시스템 장애의 계약별 영향을 다루는 섹션 7.3의 가드레일. 그러나 DON 자체에 대한 안전 장치 메커니즘을 갖추는 것도 중요합니다. 즉, 체계적이고 잠재적으로 치명적인 DON 오류로부터 보호합니다. 지금 설명하는 것처럼 포크/모호함 및 서비스 수준 계약(SLA) 실패. 포크/모호함: 결함이 있는 노드가 충분히 많으면 DON는 분기할 수 있습니다. 또는 모호하게 표현하여 L에서 두 개의 서로 다른 일관성 없는 블록 또는 블록 시퀀스를 생성합니다. 그러나 DON은 L의 내용에 디지털 서명을 하기 때문에 모호함을 방지 및/또는 처벌하기 위한 메인 체인 MAINCHAIN. DON은 MAINCHAIN의 감사 계약에서 L의 상태를 주기적으로 체크포인트할 수 있습니다. 미래 상태가 체크포인트 상태에서 벗어나면 사용자/감사자는 증거를 제시할 수 있습니다. 감사 계약에 대한 이러한 잘못된 행동. 이러한 증거는 경고를 생성하는 데 사용될 수 있습니다. 또는 계약에서 슬래싱을 통해 DON 노드에 불이익을 줍니다. 이 후자의 접근 방식은 특정 oracle 피드에 대한 것과 유사한 인센티브 설계 문제이며 이를 기반으로 구축할 수 있습니다. 우리의 작업은 섹션 9에 설명되어 있습니다.서비스 수준 계약 시행: DON이 반드시 그런 것은 아닙니다. 무한정 실행되므로 SLA(서비스 수준 계약)를 준수하는 것이 중요합니다. 사용자와 함께. 기본 SLA 시행은 메인 체인에서 가능합니다. 예를 들어, DON 노드는 특정 날짜까지 DON을 유지하거나 서비스 종료에 대한 사전 통지(예: 3개월 전 통지)를 제공하기로 약속할 수 있습니다. 에 대한 계약 MAINCHAIN은 기본적인 암호경제학적 SLA 시행을 제공할 수 있습니다. 예를 들어 SLA 계약은 체크포인트가 다음과 같은 경우 예치된 자금 DON을 삭감할 수 있습니다. 필요한 간격으로 제공되지 않습니다. 사용자는 자금을 입금하고 DON에 이의를 제기할 수 있습니다. 체크포인트가 유효한 블록의 시퀀스를 정확하게 나타내는지 증명하기 위해(어떤 방식으로든) 예를 들어 다음과 유사합니다. [141]). 물론 블록생산은 거래와 동일하지 않습니다. 처리하지만 SLA 계약은 후자를 시행하는 역할도 할 수 있습니다. 예를 들어, 트랜잭션을 mempool에서 가져오고(섹션 5.2 참조) 트랜잭션을 채굴하여 체인에 배치하는 레거시 호환 버전의 FSS입니다. 사용자 다음 거래와 함께 SLA 계약을 제공하여 DON 불법 행위를 입증할 수 있습니다. 채굴되었지만 대상 계약에 의한 처리를 위해 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 ノードの運用コストを超えています。
図 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)를 통해 각각. 스테이킹: 다른 blockchain 시스템과 마찬가지로 Chainlink에 스테이킹하려면 네트워크 참가자(예: oracle 노드)가 참여하고 LINK tokens 형식으로 잠긴 자금을 예치해야 합니다. 이것들 지분 또는 명시적 지분이라고도 하는 자금은 명시적인 인센티브입니다. 그들은 노드 장애 또는 불법 행위 시 몰수될 수 있습니다. blockchain 맥락에서, 이 절차를 흔히 슬래싱이라고 합니다. 그러나 Chainlink의 oracle 노드에 의한 스테이킹은 staking과 근본적으로 다릅니다. 권한이 없는 blockchains에서 validators에 의해. 검증인은 거래를 모호하게 하거나 적대적으로 주문함으로써 잘못된 행동을 할 수 있습니다. 기본 합의 프로토콜 15사용자는 mempool의 트랜잭션을 대체할 수 있으므로 채굴된 트랜잭션과 DON 제출된 트랜잭션 간의 올바른 대응을 보장하기 위해 주의가 필요합니다.하지만 무허가 blockchain은 확실하고 빠른 블록 유효성 검사 규칙과 암호화 프리미티브를 사용하여 validator이 잘못된 블록을 생성하는 것을 방지합니다. 대조적으로, 프로그래밍 방식의 보호로는 부정 행위 oracle 네트워크가 생성되는 것을 방지할 수 없습니다. 잘못된 보고서. 그 이유는 두 가지 시스템 유형 간의 주요 차이점입니다. blockchains의 트랜잭션 유효성 검사는 내부 일관성의 속성인 반면 정확성은 oracle의 blockchain에 대한 보고서는 외부, 즉 오프체인 데이터의 속성입니다. 우리는 Chainlink 네트워크 기반을 위한 예비 staking 메커니즘을 설계했습니다. 외부 데이터를 사용할 수 있는 oracle 노드 간의 대화형 프로토콜에서. 이 메커니즘은 명시적인 보상을 사용하여 올바른 행동에 대한 재정적 인센티브를 생성합니다. 페널티(슬래싱). 메커니즘이 경제적이므로 노드를 방지하도록 설계되었습니다. 금융 자원을 사용하여 노드를 손상시키는 적에 의한 부패 뇌물 수수. (이러한 적은 매우 일반적이며, 예를 들어 협력하는 노드까지 확장됩니다. 집단적인 잘못된 행동에서 가치를 추출합니다.) 우리가 디자인한 Chainlink staking 메커니즘에는 강력하고 새로운 기능이 있습니다. 특징.16 이러한 주요 특징은 초선형 영향(구체적으로는 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 노드에 대한 두 가지 주요 경제적 인센티브를 요약해 보겠습니다. 개발 중인 Chainlink 네트워크의 동작은 다음과 같습니다. • 스테이킹(예치된 지분) 오 명시적 인센티브 • 미래 수수료 기회(FFO) 오 암묵적 인센티브 이 두 가지 형태의 인센티브는 상호보완적입니다. Oracle 노드는 동시에 Chainlink staking 프로토콜에 참여하고, 지속적인 수익원을 즐기세요. 사용자는 지속적인 좋은 행동으로 인해 총체적으로 이익을 얻습니다. 따라서 두 인센티브 모두 oracle 네트워크가 제공하는 암호경제적 보안에 기여합니다. 추가적으로, 두 가지 인센티브는 서로 강화되거나 거래될 수 있습니다. 예를 들어, 실적 내역과 수익원이 없는 새로운 oracle 운영자는 정직한 행동을 보장하기 위해 대량의 LINK를 제공하여 사용자를 유치합니다. 그리고 수수료. 반대로, 길고 상대적으로 결함이 없는 확립된 oracle 연산자 성과 기록은 대규모 사용자 기반에서 상당한 수수료를 부과할 수 있으므로 이에 의존합니다. 암묵적인 인센티브의 형태로 FFO에 더 중점을 두고 있습니다. 일반적으로 여기서 고려하는 접근 방식은 주어진 양의 oracle-네트워크를 목표로 합니다. 합리적으로 Chainlink에서 가능한 최대의 경제적 인센티브를 창출할 수 있는 자원 에이전트(즉, 재정적 효용을 극대화하는 노드)는 정직하게 행동합니다. 다른 것을 넣어 방식으로, 목표는 적이 공격하는 데 필요한 재정 자원을 최대화하는 것입니다. 네트워크가 성공적으로 완료되었습니다. staking 프로토콜을 수학적으로 잘 공식화함으로써 경제적 안보를 정의하고 IIF를 사용하여 우리는 경제 안보의 강도를 측정하는 것을 목표로 합니다. Chainlink의 인센티브를 최대한 정확하게 전달하세요. 의존 계약의 작성자는 그런 다음 oracle 네트워크가 충족하는지 여부를 자신있게 결정할 수 있습니다. 필요한 수준의 암호화폐 보안. 경제 안보의 선순환: 이 섹션에서 논의하는 인센티브인 staking 및 FFO는 보안 강화 이상의 영향을 미칩니다. DONs. 그들은 우리가 경제 안보의 선순환이라고 부르는 것을 유도할 것을 약속합니다. 초선형 staking 영향(및 기타 규모의 경제)으로 인해 운영이 저하됩니다. DON의 보안이 강화됨에 따라 비용이 증가합니다. 비용이 낮아지면 DON에 더 많은 사용자가 유입됩니다.수수료 지불을 강화합니다. 수수료 인상은 계속해서 성장을 촉진합니다. 선순환을 이어가는 네트워크입니다. 우리는 경제 안보의 선순환이 하나의 예일 뿐이라고 믿습니다. 이 섹션의 뒷부분에서 논의할 규모의 경제와 네트워크 효과 등이 있습니다. 섹션 구성: 스테이킹은 주목할만한 기술 및 개념적 과제를 제시합니다. 우리는 새로운 기능을 갖춘 메커니즘을 설계했습니다. 따라서 스테이킹은 이 섹션의 주요 초점은 다음과 같습니다. 섹션 9.1에서 이 문서에 소개된 staking 접근 방식에 대한 개요를 제공하고 섹션 9.2~9.5에서 자세한 논의를 진행합니다. IFF를 소개합니다 섹션 9.6에서. 섹션 9.7에서는 Chainlink 네트워크 인센티브에 대한 요약 보기를 제시합니다. 섹션 9.8에서는 우리가 제안한 staking 접근 방식이 oracle 네트워크에 가져올 수 있는 경제적 보안의 선순환에 대해 논의합니다. 마지막으로 다른 가능성에 대해 간단히 설명하겠습니다. 섹션 9.9에서 Chainlink 네트워크의 성장을 촉진하는 효과가 있습니다. 9.1 스테이킹 개요 위에서 언급한 것처럼 여기서 소개하는 staking 메커니즘 설계에는 oracle 노드 간의 불일치를 해결할 수 있는 대화형 프로토콜이 포함됩니다. 외부 데이터 보고. 스테이킹은 합리적인 oracle 노드의 정직한 행동을 보장하는 것을 목표로 합니다. 따라서 우리는 staking 프로토콜을 공격하는 공격자를 모델링할 수 있습니다. 뇌물 수수: 적의 전략은 재정적 인센티브를 사용하여 oracle 노드를 부패시키는 것입니다. 공격자는 성공적인 변조를 통해 전향적으로 재정적 자원을 확보할 수 있습니다. oracle 보고서를 사용하여 예를 들어 결과 이익을 손상된 노드와 공유하겠다고 제안합니다. 우리는 staking 메커니즘 설계를 동시에 두 가지 야심찬 목표로 삼고 있습니다. 1. 강력한 적에 저항: staking 메커니즘은 보호하기 위해 설계되었습니다. oracle 네트워크는 복잡하고, 뇌물을 제공하는 장래의 뇌물 수수를 포함한 조건부 뇌물 수수 전략 사실 이후에 신원이 확인된 oracles에게(예: 뇌물 제공) 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차 스케일링하여 뇌물 수수를 거의 비현실적으로 만듭니다. 노드가 적당한 양만 스테이킹하는 경우. 이 두 가지 목표를 달성하려면 혁신적인 인센티브 설계 조합이 필요합니다. 그리고 암호화. 주요 아이디어: 우리의 staking 접근 방식은 감시 우선 순위라고 부르는 아이디어에 달려 있습니다. Chainlink oracle 네트워크에서 생성되어 신뢰 계약으로 전송되는 보고서 (예: 자산 가격)은 참여 노드가 제공한 개별 보고서에서 집계됩니다(예: 중앙값을 사용하여). 일반적으로 서비스 수준 계약(SLA) 보고서에 대해 허용 가능한 편차 범위, 즉 노드의 보고서가 얼마나 멀리까지 허용되는지를 지정합니다. 집계 보고서에서 벗어나는 범위와 집계가 어느 정도까지 허용되어야 하는지 실제 값에서 벗어나면 올바른 것으로 간주됩니다. staking 시스템에서 특정 보고 라운드에 대해 각 oracle 노드는 다음과 같은 역할을 할 수 있습니다. 집계 보고서가 부정확하다고 판단되면 경고를 발생시키는 감시자입니다. 각각 보고 라운드에서 각 oracle 노드에는 다음을 결정하는 공개 우선순위가 할당됩니다. 경고(있는 경우)가 처리되는 순서입니다. 우리의 메커니즘은 보상을 목표로 합니다. 이는 경보를 발생시키는 최우선 순위의 감시자가 결함이 있는 노드의 예금을 압수하여 전체 보상을 얻습니다. staking 시스템 설계에는 두 가지 계층, 즉 첫 번째 기본 계층과 두 번째 계층이 포함됩니다. 백스톱 계층. 첫 번째 계층은 n개의 노드 집합인 oracle 네트워크 자체입니다. (단순화를 위해, 우리는 n이 홀수라고 가정합니다.) 대다수의 노드가 잘못된 값을 보고하면 첫 번째 계층은 경고를 발생시키도록 강력한 인센티브를 받습니다. 경고가 발생하면 보고는 그런 다음 네트워크 결정은 네트워크 서비스 수준 계약에서 사용자가 지정할 수 있는 고비용, 최대 신뢰성 시스템인 두 번째 계층으로 승격됩니다. 예를 들어, 강력한 노드로만 구성된 시스템일 수 있습니다. 과거 신뢰도 점수 또는 그보다 훨씬 더 많은 oracle을 가진 점수 첫 번째 계층. 또한 섹션 9.4.3에서 설명한 대로 DECO 또는 Town Crier가 서비스를 제공할 수 있습니다. 두 번째 계층에서 효율적이고 결정적인 판결을 보장하는 데 도움이 되는 강력한 도구입니다. 단순화를 위해 우리는 이 두 번째 계층 시스템이 올바른 보고서에 도달한다고 가정합니다. 가치. 모든 보고서를 생성하기 위해 두 번째 계층에 의존하는 것이 매력적으로 보일 수도 있지만, 우리 설계의 이점은 보안 속성을 지속적으로 달성한다는 것입니다.일반적인 경우에는 운영 비용만 지불하면서 두 번째 계층 시스템을 운영합니다. 1차 시스템. Watchdog 우선 순위는 다음과 같은 방식으로 초선형 staking 영향을 미칩니다. 1차 계층 oracle 네트워크가 잘못된 결과와 다수의 감시 노드를 출력합니다. 경고, staking 인센티브 메커니즘은 우선순위가 가장 높은 감시자에게 다음과 같은 보상을 제공합니다. $dn/2 이상은 (대부분) 오작동하는 노드의 예금에서 인출됩니다. 는 따라서 총 보상은 이 단일 감시자의 손에 집중됩니다. 적이 잠재적인 감시자에게 약속해야 하는 최소값을 결정합니다. 경고하지 않도록 장려하십시오. 우리 메커니즘은 모든 oracle이 우선순위가 높은 감시자가 뇌물을 받은 경우 감시자 역할을 할 수 있는 기회 (그리고 경고하지 않기로 결정한 경우) 따라서 적수는 다음보다 더 많은 뇌물을 제공해야 합니다. 경고가 발생하는 것을 방지하기 위해 모든 노드에 $dn/2. n개의 노드가 있으므로, 성공적인 뇌물 수수를 위해 적의 필수 예산은 $dn2/2 이상입니다. 는 네트워크의 노드 수 n에 대해 2차입니다. 9.2 배경 staking에 대한 우리의 접근 방식은 게임 이론 및 메커니즘 분야의 연구를 바탕으로 합니다. 디자인(MD)(교과서 참조는 [177] 참조). 게임이론은 수학적으로 전략적 상호작용에 대한 공식화된 연구. 이런 맥락에서 게임은 그러한 모델이다. 일반적으로 현실 세계에서 사용 가능한 일련의 작업을 체계화하는 상호 작용 플레이어라고 하는 게임 참가자. 게임은 또한 획득한 보상을 지정합니다. 개별 플레이어에 의한 보상 - 플레이어가 선택한 행동과 결과에 따라 달라지는 보상 다른 플레이어의 행동. 아마도 게임에서 연구된 게임의 가장 잘 알려진 예일 것입니다. 이론은 죄수의 딜레마 [178]입니다. 게임 이론가들은 일반적으로 이해하는 것을 목표로 합니다. 주어진 게임에서 표현되는 평형 또는 평형(있는 경우). 균형은 어느 누구도 더 높은 점수를 얻을 수 없는 일련의 전략(각 플레이어당 하나씩) 일방적으로 전략에서 벗어나는 결과를 초래합니다. 한편, 메커니즘 디자인은 인센티브를 디자인하는 과학입니다. 상호 작용(및 관련 게임)의 균형에는 몇 가지 바람직한 속성이 있습니다. MD는 게임 이론의 반대라고 볼 수 있습니다: 게임의 정식 질문 이론은 "인센티브와 모델이 주어지면 균형은 어떻게 될까요?"입니다. MD에서는 대신 질문은 "어떤 인센티브가 바람직한 균형을 이루는 게임을 만들 것인가?"입니다. 메커니즘 설계자의 일반적인 목표는 '인센티브 호환' 메커니즘을 만드는 것입니다. 즉, 메커니즘 참가자(예: 경매 또는 기타 정보)가 유도 시스템 [228])은 어떤 문제(예: 어떻게 그들은 특정 품목을 매우 중요하게 생각합니다). Vickrey(2차 가격) 경매는 아마도 참가자가 봉인된 입찰을 제출하는 가장 잘 알려진 인센티브 호환 메커니즘 품목에 대해 가장 높은 입찰자가 품목을 획득하지만 두 번째로 높은 가격을 지불합니다. [214]. 암호경제학은 암호학을 활용하는 도메인별 MD 형태입니다. 분산형 시스템 내에서 바람직한 균형을 만드는 기술. 뇌물수수와 공모는 MD 분야 전반에 걸쳐 심각한 문제를 야기합니다. 거의 모든 메커니즘은 담합(부차적 계약으로 정의됨)이 있는 경우 중단됩니다.메커니즘에 참여하는 당사자 사이를 연결합니다[125, 130]. 외부 당사자가 게임에 새로운 인센티브를 도입하는 뇌물수수는 더욱 심각한 문제를 야기합니다. 공모보다; 담합은 게임 간 뇌물수수의 특수한 경우로 볼 수 있다. 참가자. 블록체인 시스템은 종종 금전적(암호화폐 기반) 보상을 제공하는 게임으로 개념화될 수 있습니다. 간단한 예는 작업 증명 채굴입니다. 채굴자는 행동 공간을 갖습니다. 블록을 채굴할 hash비율을 선택할 수 있습니다. 채굴의 보상은 보장된 음의 보상(전기 및 장비 비용)에 확률론적 보상을 더한 것입니다. 다른 활성 채굴자 수에 따라 달라지는 긍정적인 보상(채굴 보조금) [106, 172] 및 거래 수수료. SchellingCoin [68]과 같은 크라우드소싱 oracle은 또 다른 예입니다. 작업 공간은 oracle이 보낼 수 있는 가능한 보고서 세트입니다. 지불은 oracle 메커니즘에 의해 지정된 보상입니다. 예를 들어 지불은 달라질 수 있습니다. oracle의 보고서가 다른 보고서의 중앙값에 얼마나 가까운지에 대한 정보입니다[26, 68, 119, 185]. 블록체인 게임은 공모 및 뇌물 공격의 기회를 제공합니다. 실제로, smart contracts는 이러한 공격을 용이하게 할 수도 있습니다[96, 165]. 아마도 가장 잘 알려진 크라우드소싱된 oracles에 대한 뇌물 수수 공격은 p-plus-epsilon 공격 [67]입니다. 이 공격 플레이어가 부울 값 보고서(즉, 거짓 또는 참)를 제출하고 해당 내용에 동의할 경우 p로 보상받는 SchellingCoin과 유사한 메커니즘의 맥락에서 발생합니다. 다수 제출. p-plus-epsilon 공격에서 공격자는 다음과 같이 확실하게 약속합니다. 예를 들어, 다수의 제출이 사실인 경우에만 거짓 투표에 대해 사용자에게 $p + ϵ를 지불합니다. 그 결과 모든 플레이어가 허위 보고를 하도록 장려되는 균형이 이루어졌습니다. 다른 플레이어가 무엇을 하든 상관없습니다. 결과적으로 뇌물은 노드를 유도할 수 있습니다. 약속된 뇌물을 통해 실제로 뇌물을 주지 않고 허위신고를 하게 됩니다(!). 그러나 oracle, 특히 크라우드소싱되지 않은 oracle의 맥락에서 다른 뇌물 수수 전략을 탐색하는 것은 상당히 약한 적에게만 국한되었습니다. 모델. 예를 들어, PoW 환경에서 연구자들은 결과에 따른 결과를 연구했습니다. 뇌물, 즉 대상 메시지가 성공적으로 검열되고 검열되지 않은 경우에만 뇌물이 지급됩니다. 개별 광부의 행동과 관계없이 블록에 나타납니다[96, 165]. 이 경우 그러나 p-plus-epsilon 공격 외에 우리는 oracles의 작업만 알고 있습니다. 뇌물수수자가 조건부로 뇌물을 보내는 엄격하게 제한된 뇌물수수 모델 결과가 아닌 개별 플레이어의 행동에 따라 결정됩니다. 여기서 우리는 인센티브를 유지하는 정보 추출 메커니즘의 설계를 스케치합니다. 다음 하위 섹션에서 설명하는 것처럼 강력한 적대적 모델에서도 호환됩니다. 9.3 모델링 가정 이 하위 섹션에서는 플레이어의 행동과 능력을 모델링하는 방법을 설명합니다. 우리 시스템, 특히 첫 번째 계층 oracle 노드, 두 번째 계층의 노드(판정) 레이어와 적.9.3.1 1차 인센티브 모델: Rational Actors 많은 blockchain 시스템은 몇 가지 정직한 정보를 가정하여 보안에 의존합니다. 참여 노드. 노드는 프로토콜을 따르면 정직하다고 정의됩니다. 그렇게 하는 것이 재정적으로 이익이 되지 않는 경우. 일반적으로 작업 증명 시스템 솔직히 말해서 대부분의 hash 권한이 필요합니다. 지분 증명 시스템은 일반적으로 솔직히 말해서 모든 참여 지분의 2/3 이상이 필요하며 심지어 다음과 같은 레이어 2 시스템도 필요합니다. Arbitrum [141]에는 최소한 한 명의 정직한 참가자가 필요합니다. staking 메커니즘을 모델링할 때 우리는 훨씬 약한 가정을 합니다. (될 명확하고 약한 가정은 더 강력한 보안 특성을 의미하므로 바람직합니다.) 우리는 적이 손상, 즉 통제, 일부(소수)를 손상했다고 가정합니다. 첫 번째 계층 oracle 노드의 비율입니다. 우리는 정직한 에이전트가 아닌 나머지 노드를 모델링합니다. 그러나 합리적 기대효용 극대화자로서. 이러한 노드는 전적으로 이기적인 재정적 인센티브에 따라 행동하며 예상되는 재정적 결과를 가져오는 행동을 선택합니다. 이득. 예를 들어, 노드가 다음으로 인한 보상보다 더 큰 뇌물을 제공받는 경우 정직하게 행동하면 뇌물을 받을 것입니다. 적대적 노드에 대한 참고 사항: 일반적인 신뢰 모델링에 따르면 분산형 시스템에서는 모든 노드가 합리적이라고 가정합니다. 즉, 최대화를 추구합니다. 악의적인 적에 의해 통제되는 것이 아니라 순수익입니다. 그러나 우리의 주장은— 특히 초선형 또는 2차 staking 영향 - 점근적으로 제공됨 적대적으로 제어되는 노드 세트는 최대 (1/2 −c)n입니다. 일부 긍정적인 경우 상수 다. 9.3.2 2차 판단 모델: 가정에 의한 정확성 보안을 달성하는 데 도움이 되는 staking 메커니즘의 중요한 기능은 합리적인 노드에 대한 두 번째 계층 시스템입니다. 제안된 staking 메커니즘에서 모든 oracle은 다음을 나타내는 경고를 발생시킬 수 있습니다. 메커니즘의 출력이 올바르지 않다고 생각합니다. 경고로 인해 신뢰도가 높아집니다. 두 번째 계층 시스템을 활성화하고 올바른 결과를 보고합니다. 따라서 핵심 모델링 우리의 접근 방식에 대한 요구 사항은 올바른 판결, 즉 2차 시스템. 우리의 staking 모델은 부패할 수 없고 최대한 신뢰할 수 있는 정보 소스 역할을 하는 2차 계층 시스템을 가정합니다. 이러한 시스템은 비용이 많이 들고 속도가 느릴 수 있습니다. 일반적인 경우에 사용하기에는 부적절합니다. 그러나 평형의 경우, 즉 첫 번째 계층 시스템이 올바르게 작동하면 두 번째 계층 시스템이 호출되지 않습니다. 대신, 그 존재는 다음을 제공함으로써 전체 oracle 시스템의 보안을 강화합니다. 높은 보증 백스톱. 신뢰도가 높고 비용이 높은 판결 레이어의 사용은 항소 프로세스와 유사합니다. 대부분의 사법 시스템의 핵심입니다. oracle 디자인에서도 이미 흔히 볼 수 있는 현상입니다. 시스템(예: [119, 185]). 우리는 두 번째 계층의 실현에 대한 접근 방식을 간략하게 논의합니다. 섹션 9.4.3의 메커니즘에서.우리의 staking 프로토콜은 oracle 노드의 올바른 보고를 시행하기 위한 신뢰할 수 있는 위협으로 두 번째 계층 시스템의 올바른 판결 가정을 사용합니다. 프로토콜 다음으로 식별되는 보고서를 생성하는 oracle 노드 지분의 일부 또는 전부를 압수합니다. 두 번째 계층 시스템이 잘못된 것으로 간주됩니다. 따라서 Oracle 노드는 오작동을 방지합니다. 그에 따른 금전적 처벌을 받습니다. 이 접근 방식은 다음에서 사용되는 방식과 유사합니다. 낙관적인 rollups(예: [141, 10]) 9.3.3 적대적 모델 우리의 staking 메커니즘은 광범위하고 잘 정의된 적군에 대해 보안을 달성하면서 진실한 정보를 도출하도록 설계되었습니다. 이전 작품에 비해 개선되었으며, 이는 명시적인 적대적 모델을 생략하거나 위에서 논의한 p-plus-epsilon 적과 같은 좁은 하위 클래스의 적에 초점을 맞춥니다. 우리의 목표는 staking을 디자인하는 것입니다. 모든 종류의 공격자에 대해 공식적으로 입증된 보안을 갖춘 메커니즘 실무에서 접하게 됩니다. 우리는 상대방이 다음과 같이 고정된(매개변수화 가능한) 예산을 갖고 있다고 모델링합니다. $B. 적은 oracle와 개별적으로 비밀리에 통신할 수 있습니다. 네트워크를 통해 개인에게 비밀리에 뇌물 지급을 보장할 수 있습니다. 메커니즘의 공개적으로 관찰 가능한 결과에 따라 달라집니다. 결과 결정 뇌물에는 예를 들어 oracle에서 보고한 값, 공개 메시지 등이 포함될 수 있습니다. oracle에 의해 메커니즘(예: 경고)으로 전송된 값은 다른 oracles 및 메커니즘에 의해 출력되는 값입니다. 무제한의 능력을 갖춘 공격자로부터 보호할 수 있는 메커니즘은 없습니다. 따라서 일부 동작은 비현실적이거나 범위를 벗어난 것으로 간주됩니다. 우리는 공격자를 가정합니다 표준 암호화 기본 형식을 깨뜨릴 수 없으며 위에서 언급한 것처럼 고정되어 있습니다(만약 잠재적으로 큰 규모) 예산 $B. 또한 적이 통제하지 못한다고 가정합니다. oracle 네트워크에서의 통신은 특히 실질적으로 지연될 수 없습니다. 첫 번째 계층 및/또는 두 번째 계층 노드 간의 트래픽. (상대가 그러한 통신을 관찰할 수 있는지 여부는 아래에서 설명하는 것처럼 특정 메커니즘에 따라 다릅니다.) 그러나 위에서 언급한 바와 같이 비공식적으로는 적이 다음과 같이 할 수 있다고 가정합니다. (1) 부패 oracle 노드의 일부(일부 상수 c에 대한 (1/2 −c)-분수), 즉 완전히 제어 (2) 지불 조건을 보장하여 원하는 노드에 뇌물을 제공합니다. 위에서 설명한 대로 적이 지정한 결과에 따라 결정됩니다. 우리는 적의 전체 공격에 대한 공식적인 모델이나 완전한 분류를 제공하지 않습니다. 본 백서에 나와 있는 다양한 뇌물 수수 능력에 대한 예는 다음과 같습니다. 우리 모델에 포함되는 뇌물 수수. 단순화를 위해 oracles가 부울을 방출한다고 가정합니다. 정확한 값(w.l.o.g.)이 참이고 최종 결과가 다음과 같이 계산되는 보고서입니다. smart contract 소비에 의해 사용되는 이러한 보고서의 집합입니다. 뇌물을 준 사람의 목표는 최종 결과가 부정확해지는 것, 즉 거짓이 되는 것입니다. • 무조건적인 뇌물수수: 뇌물수수자는 허위 보고를 하는 모든 oracle에게 $b 뇌물을 제공합니다. • 확률적 뇌물수수: 뇌물수수자는 임의의 oracle에게 q 확률로 $b 뇌물을 제공합니다. 거짓으로 보고하는 것입니다.• 거짓 결과 조건부 뇌물: 뇌물은 최종 결과가 거짓인 경우 거짓을 보고하는 모든 oracle에게 뇌물 $b를 제공합니다. • 비경고 조건 뇌물수수: 뇌물수수자는 보고하는 모든 oracle에게 뇌물 $b를 제공합니다. 경고가 발생하지 않는 한 false입니다. • p-plus-epsilon 뇌물 수수: 뇌물 수수는 다음과 같이 허위 보고를 하는 모든 oracle에게 뇌물 $b를 제공합니다. oracles의 대다수가 거짓을 보고하지 않는 한. • 잠재적 뇌물 수수: 뇌물 수수자는 oracle을 선택한 사람에게 미리 $b의 뇌물을 제공합니다. 무작위 역할에 대해 거짓으로 보고합니다. 우리가 제안한 staking 프로토콜에서는 모든 노드는 잠재적인 감시자 역할을 하며, 우리는 무작위화를 보여줄 수 있습니다 감시 우선 순위는 잠재적인 뇌물 수수에 적합하지 않습니다. 많은 작업 증명, proof-of-stake 및 허가된 시스템은 잠재적으로 취약합니다. 그러나 뇌물수수는 적의 입장에서 이를 고려하는 것이 중요함을 보여줍니다. 모델을 만들고 staking 프로토콜이 이에 대한 탄력성을 갖도록 보장합니다. 부록 E를 참조하세요. 자세한 내용은 9.3.4 암호경제학적 보안은 어느 정도면 충분합니까? 합리적인 공격자는 이익을 얻을 수 있는 경우에만 시스템을 공격하는 데 돈을 지출합니다. 지출보다 더 크다. 따라서 우리의 적대적 모델과 제안된 staking에 대해 메커니즘에서 $B는 적이 얻을 수 있는 잠재적 이익의 척도로 볼 수 있습니다. oracle 네트워크를 손상시키고 이를 유발하여 의존하는 smart contract에서 추출합니다. 잘못된 보고서 또는 보고서 세트를 생성합니다. oracle 네트워크 여부를 결정할 때 목적에 맞는 충분한 수준의 암호경제적 보안을 제공하는 경우, 사용자는 다음을 수행해야 합니다. 이러한 관점에서 네트워크를 평가하십시오. 실제 상황에서 그럴듯한 적의 경우 $B는 일반적으로 smart contracts에 의존하는 총 자산보다 훨씬 작습니다. 대부분의 경우, 공격자가 이러한 자산을 전체적으로 추출하는 것은 불가능합니다. 9.4 스테이킹 메커니즘: 스케치 여기서 우리는 staking 메커니즘의 주요 아이디어와 일반 구조를 제시합니다. 현재 고려 중입니다. 프레젠테이션의 편의를 위해 간단하지만 느린 방법을 설명합니다. (다중) 프로토콜. 그러나 우리는 이 계획이 상당히 실용적. 메커니즘이 제공하는 경제적 보장, 즉 결함이 있는 노드에 대한 처벌 및 그에 따른 인센티브를 고려하면 많은 사용자가 기꺼이 다음을 수행할 수 있습니다. 보고서를 낙관적으로 받아들입니다. 즉, 해당 사용자는 신고 이전에 신고를 수락할 수 있습니다. 두 번째 계층의 잠재적인 판결. 낙관적으로 보고서를 받아들이고 싶지 않은 사용자는 프로토콜이 나올 때까지 기다리도록 선택할 수 있습니다. 즉, 두 번째 계층으로의 잠재적인 에스컬레이션이 발생할 때까지 실행이 종료됩니다. 이, 그러나 보고서 확인 시간이 상당히 느려질 수 있습니다. 그러므로 우리는 간략하게그림 15: 경고가 포함된 staking 체계의 도식. 이 예에서는 1⃝a 다수 의 노드가 손상되거나 뇌물을 받고 올바른 값이 아닌 잘못된 값 ~r을 방출합니다. 보고서 값 r. 감시 노드 2⃝는 2차 위원회에 경고를 보냅니다. 3⃝은 올바른 보고 값 r을 결정하고 내보내며, 그 결과 노드가 손상됩니다. 각 $d는 워치독 노드 4⃝에 예치금을 몰수합니다. 다소 더 많은 경우 더 빠른(단일 라운드) 결과를 가져오는 몇 가지 최적화에 대한 개요를 설명합니다. 섹션 9.5의 복잡한 설계. staking 메커니즘의 첫 번째 계층은 기본 oracle로 구성됩니다. 네트워크 자체. 위에서 설명한 것처럼 우리 메커니즘의 주요 구조는 각 라운드마다 다음과 같습니다. 각 노드는 우선 순위에 따라 "감시자" 역할을 할 수 있습니다. 메커니즘이 올바른 출력이 아닌 잘못된 출력 ~r에 도달하면 경고를 발생시킵니다. 하나의 r. 이 경고는 올바른 결과에 도달한다고 가정하는 두 번째 계층 해결 방법을 발생시킵니다. 보고. 잘못된 보고를 한 노드는 지분이 있다는 의미에서 처벌됩니다. 감시견에게 베고 수여했습니다. 이 기본 구조는 oracle 시스템에서 일반적입니다. 예를 들어 [119, 185]와 같습니다. 위에서 간략히 언급한 우리 설계의 핵심 혁신은 모든 노드가 잠재적인 감시자 순서에 따라 뚜렷한 우선순위가 할당됩니다. 즉 감시견이다. 우선순위에 따라 경고할 기회가 주어집니다. 노드에 경고를 발생시키는 것이 가장 높은 우선순위이며 모든 오작동에 대해 $d의 삭감된 예치금을 받습니다. 잘못된 보고는 다음을 의미하므로 총 \(dn/2 = \)d × n/2보다 많은 노드 대부분의 불량 노드. 결과적으로, 적은 최소한 이 보상을 지불해야 합니다. 임의의 노드에 뇌물을 줍니다. 따라서 대다수의 노드에 뇌물을 제공하려면 공격자는 다음과 같은 비용을 지불해야 합니다. 즉, 엄밀히 말하면 $dn2/2보다 많은 대규모 뇌물을 노드에 제공합니다. 그림 15에서는 경고 및 감시 에스컬레이션이 어떻게 작동하는지 개략적으로 보여줍니다.9.4.1 추가 메커니즘 세부정보 이제 우리가 더 자세히 설명하는 뇌물 방지 시스템은 다음과 같은 단순화된 개요입니다. 우리가 건설하려는 2층 구조. 우리의 초점은 대부분 설명하는 것입니다. 첫 번째 계층 네트워크(이하 맥락에서 명확한 경우 간단히 "네트워크") 인센티브 메커니즘과 두 번째 계층으로의 에스컬레이션 절차를 설명합니다. 다음을 담당하는 n개의 oracle 노드로 구성된 Chainlink 네트워크를 생각해 보세요. 정기적으로(예: 1분에 한 번) 부울 값(예: 시장이 BTC의 시가총액이 ETH의 시가총액을 초과합니다. staking 메커니즘의 일부로 노드는 두 가지 보증금을 제공해야 합니다. 보증금 $d는 동의하지 않을 경우 삭감될 수 있습니다. 다수 및 감시 예치금 $dw에 결함이 있는 경우 삭감될 수 있음 에스컬레이션. 우리는 노드가 다른 노드의 제출물을 복사할 수 없다고 가정합니다. 섹션 5.3에서 논의된 커밋-공개 체계를 통해. 각 라운드에서 노드가 먼저 보고서를 커밋하고 모든 노드가 커밋되면(또는 제한 시간이 만료되면) 노드는 보고서를 공개합니다. 생성될 각 보고서에 대해 모든 노드에는 무작위로 선택된 1과 n 사이의 감시 우선순위가 부여되며, 1이 최고 우선순위입니다. 이 우선순위를 사용하면 한 감시자의 손에 보상이 집중됩니다. 모든 신고가 공개된 후, 경고 단계가 이어집니다. n(동기) 라운드의 시퀀스에 걸쳐 노드는 우선 순위는 i 라운드에서 경고할 기회가 있습니다. 노드가 공개된 후 메커니즘에 대한 가능한 결과를 고려해 보겠습니다. 그들의 보고서. 다시 이진 보고서를 가정하고 올바른 값이 true이고 잘못된 것은 거짓입니다. 또한 첫 번째 계층 메커니즘이 다음을 출력한다고 가정합니다. 최종 보고서 r로서 노드에 의해 출력된 다수의 값. 메커니즘에는 세 가지 가능한 결과가 있습니다. • 완전한 합의: 최선의 경우 노드는 완전한 합의에 있습니다. 모든 노드는 사용 가능하며 동일한 값 r에 대한 보고를 시기적절하게 제공했습니다(둘 중 하나). 또는 거짓). 이 경우 네트워크는 r을 의존 계약으로 전달하기만 하면 됩니다. 각 노드에 라운드당 고정 지불금 $p를 지급합니다. 이는 훨씬 작은 금액입니다. $d보다. • 부분적 동의: 일부 노드가 오프라인이거나 어떤 값이 올바른지에 대해 의견 차이가 있을 수 있지만 대부분의 노드는 true를 보고하고 소수의 보고가 거짓입니다. 이 경우도 간단합니다. 다수의 가치 (true)가 계산되어 올바른 보고서 r이 생성됩니다. r을 보고한 모든 노드는 잘못 신고한 oracles가 예치금을 가지고 있는 동안 $p로 보상을 받습니다. 예를 들어 $10p 정도 인하되었습니다. • 경고: 감시자가 네트워크의 출력이 잘못되었다고 판단하는 경우, 이는 공개적으로 경고를 트리거하여 메커니즘을 2차 계층 네트워크로 확대합니다. 그러면 두 가지 결과가 나올 수 있습니다. – 올바른 경고: 두 번째 계층 네트워크에서그림 16: 집중된 경고 보상을 통해 뇌물 수수 비용을 증폭시킵니다. 뇌물 공격자는 경고를 통해 얻을 수 있는 보상보다 더 많은 것을 각 노드에 뇌물을 주어야 합니다. (빨간색 막대로 표시됨) 경고 보상이 공유되는 경우 이 보상은 상대적일 수 있습니다. 작다. 집중된 경고 보상은 단일 노드가 얻을 수 있는 보상을 증가시킵니다. (높은 빨간색 막대)를 얻습니다. 결과적으로 상대방이 실행 가능한 뇌물에 대해 지불한 총 금액은 다음과 같습니다. (회색 영역)은 공유된 알림 보상보다 집중된 알림 보상이 훨씬 더 큽니다. 첫 번째 계층 네트워크가 올바르지 않아 경고하는 감시 노드가 보상을 받습니다. 모두 삭감된 예금으로 구성되므로 $dn/2 이상입니다. – 잘못된 경고: 두 번째 계층과 첫 번째 계층 oracle이 동의하는 경우 에스컬레이션은 결함이 있는 것으로 간주되고 경고 노드는 $dw 보증금을 잃습니다. 보고서가 긍정적으로 받아들여지는 경우 감시 경보는 다음을 유발하지 않습니다. 의존 계약 실행의 모든 변경. 기다리도록 설계된 계약의 경우 2위 위원회 중재 가능성, 감시단 경고는 늦어졌지만 계약 실행을 동결하지 마십시오. 계약을 통해 지정하는 것도 가능합니다. 판정 기간 동안 장애 조치 DON. 9.4.2 2차 스테이킹 영향 엄격한 노드 우선순위와 결합하여 모든 노드가 감시 역할을 하는 기능 집중된 보상을 보장하여 메커니즘이 2차 staking을 달성할 수 있도록 합니다. 섹션 9.3.3에 설명된 각 종류의 뇌물 공격자에 대한 영향. 이것을 기억하십시오 이는 우리 설정에서 각각 보증금이 있는 n개의 노드가 있는 네트워크의 경우를 의미합니다. $d, 성공적인 뇌물 제공자(위의 종류 중 하나)는 다음보다 더 큰 예산을 가져야 합니다. $dn2/2. 정확하게 말하면 뇌물수수자는 최소한 (n+1)/2개의 노드를 부패시켜야 합니다. n 노드의 대다수를 손상시킵니다(가정에 따라 홀수 n의 경우). 따라서 감시자는 다음을 수행합니다. $d(n + 1)/2의 보상을 얻습니다. 따라서 뇌물 제공자는 모든 사람에게 이 금액을 지불해야 합니다.노드가 감시자 역할을 하지 않도록 합니다. 우리는 다음과 같은 사실을 공식적으로 보여주기 위해 노력하고 있습니다. 뇌물 제공자는 최대 $d(n2 + n)/2의 예산을 가지며, 하위 게임 완전 균형이 됩니다. 뇌물수수자와 oracles 사이의 게임, 즉 균형 게임이 진행되는 동안 어느 시점에서든 뇌물을 준 사람은 뇌물을 발행해서는 안 되며, 각 oracle의 진정한 가치를 정직하게 보고합니다. 우리는 성공적인 뇌물 제공을 위해서는 다음과 같은 방법이 필요할 수 있다는 점을 위에서 설명했습니다. 노드 예치금의 합계보다 예산이 훨씬 더 많습니다. 이것을 설명하기 위해 직관적인 결과, 그림 16은 집중된 경고 보상의 영향을 그래픽으로 보여줍니다. 거기에서 볼 수 있듯이, 감시자 경보에 대한 보상, 즉 뇌물 예치금이 지급된다면 false를 보고하는 노드) - 모든 잠재적 경고로 분할되었으며, 개별 경고 노드는 상대적으로 작을 것이라고 예상할 수 있습니다. $d. $d보다 큰 지불금이 있을 가능성이 낮다는 것을 알고 있는 뇌물 제공자는 다음과 같은 방법을 사용할 수 있습니다. n개의 노드 각각에 다음보다 약간 더 많은 뇌물을 제공하는 거짓 결과 조건부 뇌물 $d + ϵ. 반직관적으로, 그림 16은 보상을 광범위하게 분배하는 시스템을 보여줍니다. 경고를 보내는 노드 중 보상을 집중시키는 노드보다 훨씬 약합니다. 하나의 감시견의 손. 예시 매개변수: n = 100개의 노드가 있는 (1차 계층) 네트워크를 생각해 보세요. \(d = \)20K를 입금합니다. 이 네트워크에는 총 200만 달러가 예치되어 있지만 예산 \(100M = \)dn2/2로 뇌물로부터 보호받을 수 있습니다. 수의 증가 oracles는 물론 $d를 늘리는 것보다 더 효과적이며 극적인 효과를 가질 수 있습니다. n = 300개 노드와 예치금 \(d = \)20K를 가진 네트워크는 다음과 같은 위험으로부터 보호됩니다. 최대 9억 달러의 예산으로 뇌물을 제공합니다. staking 시스템은 많은 경우에 다음을 나타내는 smart contract을 보호할 수 있습니다. 제공되는 뇌물수수 방지 수준보다 더 많은 가치를 갖습니다. 그 이유는 상대방이 이러한 계약을 공격하면 많은 경우 전체 가치를 추출할 수 없습니다. 예를 들어, 10억 달러의 가치를 보장하는 Chainlink 기반 계약에는 담보만 필요할 수 있습니다. 그러한 적이 실현 가능하게 이익을 추출할 수 있기 때문에 1억 달러의 자원을 가진 뇌물 수수자 계약금액의 10%에 불과하다. 참고: 네트워크의 가치가 2차적으로 증가할 수 있다는 생각은 다음과 같이 표현됩니다. 잘 알려진 Metcalfe의 법칙[167, 235]은 네트워크의 가치가 연결된 엔터티 수가 2차적으로 증가합니다. 그러나 Metcalfe의 법칙은 잠재적인 쌍별 네트워크 연결 수의 증가로 인해 발생합니다. 이는 인센티브에 기본이 되는 2차 staking 영향과는 다른 현상입니다. 메커니즘. 9.4.3 Second Tier 실현 두 가지 운영 기능으로 신뢰성이 높은 두 번째 계층의 실현을 촉진합니다. (1) 2단계 판결은 oracle 네트워크에서는 드문 경우이므로 다음과 같은 일이 발생할 수 있습니다. 첫 번째 계층의 일반 운영보다 훨씬 더 많은 비용이 듭니다. (2) 가정낙관적으로 받아들여진 보고서 또는 실행이 중재를 기다릴 수 있는 계약 두 번째 계층은 실시간으로 실행될 필요가 없습니다. 이러한 기능으로 인해 다양한 결과가 발생합니다. 특정 DON의 요구 사항을 충족하기 위한 두 번째 계층의 구성 옵션입니다. 접근 방식의 예로서, 두 번째 계층 위원회는 다음과 같은 노드로 구성될 수 있습니다. Chainlink에서 가장 오래 서비스되고 가장 안정적인 노드의 DON(즉, 첫 번째 계층) 네트워크. 상당한 관련 운영 경험 외에도 운영자는 그러한 노드 중 FFO에는 욕구를 유발하는 상당한 암시적 인센티브가 있습니다. Chainlink 네트워크의 신뢰성이 높게 유지되도록 합니다. 그들은 또한 공개적으로 신뢰성에 대한 투명성을 제공하는 사용 가능한 성능 기록입니다. 두 번째 계층 노드는 첫 번째 계층 네트워크에 참여할 필요가 없으며 주목할 가치가 있습니다. 여러 1차 네트워크 전반에 걸쳐 결함을 판정할 수 있습니다. 주어진 DON의 노드는 다음과 같은 n' 집합을 미리 지정하고 공개적으로 커밋할 수 있습니다. 노드는 해당 DON에 대한 2차 위원회를 구성합니다. 또한 DON 노드는 2차 투표 수를 결정하는 매개변수 k′ ≤n′을 게시합니다. 첫 번째 계층 노드에 페널티를 적용하는 데 필요합니다. 특정 보고서에 대해 경고가 생성되면 두 번째 계층의 구성원은 각 계층이 제공한 값의 정확성에 대해 투표합니다. 첫 번째 계층 노드 중 하나입니다. k′ 부정 투표를 받은 첫 번째 계층 노드는 해당 노드를 상실합니다. 워치독 노드에 예치합니다. 재판이 드물고, 장기집행 기회가 드물기 때문이다. 위에서 언급했듯이 첫 번째 계층과 달리 두 번째 계층의 노드는 다음을 수행할 수 있습니다. 1. 판결 수행에 대해 높은 보상을 받습니다. 2. 첫 번째 데이터 소스에서 사용하는 다양한 세트를 넘어서는 추가 데이터 소스를 활용합니다. 3. 수동 및/또는 전문가 검사 및 개입에 의존합니다. 예를 들어 식별하고 소스 데이터의 오류를 조정하고 정직한 노드 중계를 구별합니다. 잘못된 데이터와 오작동하는 노드. 우리는 두 번째 계층 노드 선택과 판결을 관리하는 정책에 대해 방금 설명한 접근 방식이 대규모 노드 내의 한 지점일 뿐이라는 점을 강조합니다. 두 번째 계층의 가능한 실현을 위한 설계 공간. 우리의 인센티브 메커니즘은 다음과 같습니다. 두 번째 계층을 구현하는 방법에 대한 완전한 유연성. 따라서 개별 DON은(는) 특정 요구 사항을 충족하는 두 번째 계층에 대한 규칙을 구성하고 설정합니다. 참여 노드와 사용자의 기대. 심사 도구로서의 DECO 및 Town Crier: 2층에서는 꼭 필요합니다 우리 메커니즘에서는 적대적인 첫 번째 계층 노드를 구별할 수 있습니다. 의도적으로 잘못된 보고서를 생성하고 의도치 않게 정직한 1차 노드를 생성합니다. 소스에서 잘못된 데이터를 중계합니다. 그래야만 두 번째 계층에서 구현할 수 있습니다. 우리 메커니즘의 목표인 부정 행위를 방지하기 위해 삭감합니다. DECO와 타운 크라이어 두 번째 계층 노드가 이러한 중요한 구별을 할 수 있도록 하는 강력한 도구입니다. 안정적으로.두 번째 계층 노드는 경우에 따라 사용된 데이터 소스를 직접 쿼리할 수 있습니다. 잘못된 보고가 있는지 확인하려면 첫 번째 계층 노드를 사용하거나 ADO 섹션 7.1을 사용하세요. 잘못된 데이터 소스로 인해 발생했습니다. 그러나 다른 경우에는 두 번째 계층 노드가 부족할 수 있습니다. 첫 번째 계층 노드의 데이터 소스에 직접 액세스합니다. 이런 경우에는 올바른 판단이 필요합니다. 실행 불가능해 보이거나 주관적인 판단에 의존해야 합니다. 이전 oracle 분쟁 시스템은 이러한 문제를 해결하기 위해 비효율적이고 확대되는 투표에 의존해 왔습니다. 도전. 그러나 DECO 또는 Town Crier를 사용하면 첫 번째 계층 노드가 올바른 동작을 증명할 수 있습니다. 두 번째 계층 노드에. (두 시스템에 대한 자세한 내용은 섹션 3.6.2를 참조하십시오.) 특히 다음과 같은 경우 두 번째 계층 노드는 첫 번째 계층 노드가 잘못된 보고서 값 ~r을 출력한 것으로 식별합니다. 첫 번째 계층 노드는 DECO 또는 Town Crier를 사용하여 변조 방지 증거를 생성할 수 있습니다. (TLS 지원) 소스에서 ~r을 올바르게 중계하고 있는 두 번째 계층 노드 DON에 의해 권위 있는 것으로 인정되었습니다. 중요한 것은 첫 번째 계층 노드가 이 작업을 수행할 수 있다는 것입니다. 데이터 소스에 직접 액세스해야 하는 2차 계층 노드가 없습니다.17 결과적으로, 원하는 데이터 소스에 대해 Chainlink에서 올바른 판결이 가능합니다. 9.4.4 보험을 잘못 보고함 우리의 staking 메커니즘을 통해 달성된 강력한 뇌물수수 저항은 근본적으로 다음과 같습니다. 경고자에게 수여되는 삭감된 자금에 대해. 금전적 보상이 없으면 경고자는 뇌물을 거부할 직접적인 동기가 없습니다. 그러나 결과적으로 삭감된 자금은 그렇지 않습니다. 잘못된 신고로 인해 피해를 입은 사용자(예: 돈을 잃은 사용자)에게 보상이 가능합니다. 잘못된 가격 데이터가 smart contract에 전달되는 경우. 가정에 따르면 잘못된 보고서는 보고서가 승인된 경우 문제를 일으키지 않습니다. 잠재적인 판결, 즉 두 번째 단계의 조치 후에만 계약을 체결합니다. 설명대로 그러나 가능한 최상의 성능을 달성하기 위해 계약은 대신에 의존할 수 있습니다. 올바른 보고를 시행하는 메커니즘에 대해 낙관적으로 생각합니다. 잠재적인 2차 판결 이전에 보고합니다. 실제로 그러한 낙관적인 행동은 예산이 예산을 초과하지 않는 합리적인 적을 가정하는 우리 모델에서는 안전합니다. staking 메커니즘의 영향. 사용자는 다음과 같은 이유로 메커니즘 오류가 발생할 가능성이 없는 상황을 우려하고 있습니다. 예를 들어, 압도적인 재정 자원을 보유한 적들은 보험을 잘못 보고하는 형태로 추가적인 경제적 보안 계층을 사용하기를 원할 수 있습니다. 우리는 알고있다 이미 이러한 종류의 스마트 계약 기반 정책을 제공하려는 여러 보험사 DAO(예: [7])과 같은 혁신적인 메커니즘을 포함하여 가까운 미래에 Chainlink 보안 프로토콜을 위해. Chainlink에 대한 공연 내역이 존재합니다. 노드 및 지분 금액과 같은 노드에 관한 기타 데이터는 위험에 대한 통계적 평가를 위한 매우 강력한 기반을 제공하여 정책 가격 책정을 가능하게 합니다. 보험 계약자에게는 저렴하면서도 보험사에게는 지속 가능한 방식으로 말입니다. 17Town Crier를 사용하면 1차 노드가 로컬에서 증명을 생성하는 것도 가능합니다. 출력된 보고서의 정확성을 확인하고 이러한 증명을 두 번째 계층 노드에 제공합니다. 필요에 따라.기본적인 형태의 허위신고 보험은 신뢰할 수 있고 smart contracts를 사용하는 효율적인 방식입니다. 간단한 예로 파라메트릭 보험을 들 수 있습니다. 계약 SCins는 인센티브 메커니즘이 다음과 같은 경우 보험 계약자에게 자동으로 보상할 수 있습니다. 두 번째 계층은 첫 번째 계층에서 생성된 보고서의 오류를 식별합니다. 보험 가입을 원하는 사용자 U(예: 대상 생성자) 계약 SC는 분산형 보험사에 보험 금액 요청을 제출할 수 있습니다. 100만 달러 계약. U를 승인하면 보험사는 지속적인(예: 월별) 서비스를 설정할 수 있습니다. SCins의 프리미엄은 $P입니다. U가 보험료를 지불하는 동안 그녀의 보험은 계속 유효합니다. SC에서 보고 실패가 발생하면 결과는 (r1, r2) 쌍의 방출이 됩니다. SC에 대한 충돌 보고서의 경우 r1은 우리 메커니즘의 첫 번째 계층에서 서명되고 해당 수정 보고서인 r2는 두 번째 계층에서 서명됩니다. U가 제공한다면 SCins에 대한 유효한 쌍(r1, r2)인 경우 계약은 자동으로 $M을 지불합니다. 그녀의 보험료 지불은 최신 상태입니다. 9.5 단일 라운드 변형 이전 하위 섹션에 설명된 프로토콜에서는 2단계 위원회가 감시자가 경보를 발령했는지 여부를 확인하기 위해 n 라운드를 기다려야 합니다. 이 요구사항은 낙관적인 경우, 즉 첫 번째 계층이 작동하는 경우에도 유지됩니다. 올바르게. 낙관적으로 보고서를 받아들이고 싶지 않은 사용자의 경우, 즉 잠재적인 판결이 내려지면 해당 접근 방식과 관련된 지연은 실행 불가능할 것입니다. 이러한 이유로 우리는 단 하나의 프로토콜만 필요로 하는 대체 프로토콜도 탐색하고 있습니다. 라운드. 이 접근 방식에서 모든 oracle 노드는 여부를 나타내는 비밀 비트를 제출합니다. 그들은 경고를 보내고 싶어합니다. 그런 다음 두 번째 계층 위원회에서는 이러한 값을 확인합니다. 우선순위. 대략적인 스케치를 제공하기 위해 이러한 계획에는 다음이 포함될 수 있습니다. 단계: 1. Watchdog 비트 제출: 각 노드 Oi는 1비트 Watchdog 값을 비밀 공유합니다. 생성된 모든 보고서에 대해 두 번째 계층의 노드 사이에서 wi ∈{no Alert, Alert}가 발생합니다. 2. 익명 팁: 모든 oracle 노드는 감시 비트가 제출되는 동일한 라운드에서 두 번째 계층 위원회에 익명 팁 α를 제출할 수 있습니다. 이 팁α 현재 보고서에 대해 경고가 발생했음을 나타내는 메시지입니다. 3. 워치독 비트 확인: 2차 위원회에서 oracle 노드의 워치독 공개 비트를 우선순위로 합니다. 노드는 경고하지 않을 때 경고 감시 비트를 보내서는 안 됩니다. 그렇지 않으면 트래픽 분석이 모든 노드의 비트를 드러냅니다. 프로토콜은 경고 없음을 나타냅니다. 우선순위가 가장 높은 경고 워치독보다 우선순위가 높은 노드의 워치독 비트입니다. 밝혀진 내용은 n-라운드 프로토콜의 내용과 동일합니다. 보상은 또한 해당 체계와 동일하게 분배됩니다. 즉, 처음으로 식별된 감시자 잘못된 보고서를 제출한 노드의 예치금을 삭감합니다.익명 제보를 사용하면 경고가 발생하지 않은 경우 2차 위원회가 비대화형 상태를 유지하여 의사소통의 복잡성을 줄일 수 있습니다. 일반적인 경우. 경고를 발생시키는 감시자는 익명 제보를 제출할 경제적 인센티브가 있습니다. 제보가 제출되지 않으면 누구에게도 보상이 지급되지 않습니다. 노드. 익명 제보 α의 보낸 사람 Oi가 식별되지 않도록 하기 위해 네트워크 데이터를 기반으로 적에게 익명 제보를 보낼 수 있습니다. 예를 들어 Tor를 통하거나 보다 실질적으로 클라우드 서비스 제공업체를 통해 프록시되는 채널입니다. 받는 사람 팁이 O에서 시작된 것으로 인증하면 Oi는 링 서명을 사용하여 α에 서명할 수 있습니다[39, 192]. 또는 악의적인 oracle 노드에 의한 2차 위원회에 대한 원인 없는 서비스 거부 공격을 방지하기 위해 α는 다음과 같은 익명 자격 증명이 될 수 있습니다. 취소 가능한 익명성 [73]. 이 프로토콜은 실질적으로 달성 가능하지만 다소 무거운 엔지니어링을 가지고 있습니다. (저희는 이를 줄이는 방법을 모색 중입니다) 예를 들어 첫 번째 계층 노드는 디렉터리 유지 관리가 필요한 두 번째 계층 노드와 직접 통신해야 합니다. 익명 채널 및 링 서명의 필요성이 엔지니어링에 추가됩니다. 계획의 복잡성. 마지막으로, 간략하게 논의된 특별한 신뢰 요구 사항이 있습니다. 아래 메모에. 따라서 우리는 여전히 달성할 수 있는 더 간단한 계획을 모색하고 있습니다. 초선형 staking 영향은 있지만 뇌물 제공자는 점근적으로 최소한 $n log n의 자원을 필요로 하는 2차식보다 덜할 수 있습니다. 아래 계획 중 일부 감시자 역할을 할 노드의 엄격한 하위 집합을 무작위로 선택하는 것을 고려합니다. 이 경우 뇌물 수수 가능성이 특히 강력한 공격이 됩니다. 비고: 이 단일 라운드 staking 메커니즘의 보안에는 접근할 수 없는 기술이 필요합니다. oracle과 2계층 노드 사이의 채널 — 투표[82, 138]와 같은 강제 저항 시스템의 표준 요구 사항이며 실제로는 합리적인 요구 사항입니다. 그러나 추가적으로 뇌물수수자와 협력하려는 노드 Oi는 뇌물 수수자에게 특정 정보를 암호화했음을 보여주는 방식으로 비밀 공유 가치. 예를 들어, Oi가 뇌물 제공자가 어느 노드를 제어하는지 알지 못하는 경우 Oi는 다음을 수행할 수 있습니다. 모든 위원회 구성원에게 가치가 0인 주식을 제출합니다. 그러면 뇌물 제공자는 Oi의 사실을 확인할 수 있습니다. 확률적으로 준수합니다. 단일 라운드 프로토콜에서 이 문제를 피하기 위해 우리는 Oi가 적어도 하나의 정직한 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 생태계에 참여하여 이 백서에서 설명한 다양한 서비스에 대해 네트워크가 지불하는 수수료의 일부를 얻습니다. 분산 ID, 공정한 순서 지정과 같은 고급 서비스에 대한 일반 데이터 피드, 기밀 유지 DeFi. Chainlink 네트워크의 수수료는 서버 운영, 필요한 데이터 라이선스 획득, 유지 관리 등에 대한 노드 운영자의 비용을 지원합니다. 높은 가동 시간을 보장하는 글로벌 직원. FFO는 서비스 수수료, 순 비용을 나타냅니다. 노드가 미래에 이익을 얻거나 잘못된 동작을 보여주면 잃을 것입니다. FFO는 네트워크 보안에 도움이 되는 지분 형태입니다. FFO의 유용한 기능은 온체인 데이터(오프체인으로 보완됨)입니다. 데이터) 노드 이력에 대한 높은 신뢰 기록을 수립하여 FFO 계산을 가능하게 합니다. 투명하고 경험적으로 주도되는 방식으로. FFO에 대한 간단한 1차 측정은 특정 기업의 평균 순수익에서 파생될 수 있습니다. 일정 기간 동안의 노드(예: 총 수익에서 운영 비용을 뺀 값) FFO는 다음을 수행할 수 있습니다. 예를 들어 누적 미래 순수익의 순 현재 가치 [114]로 계산됩니다. 즉, 미래의 모든 수입을 시간으로 할인한 가치입니다. 그러나 노드 수익은 그림 17에서 볼 수 있듯이 변동이 심할 수 있습니다. 더 중요한 것은 노드 수익이 고정된 분포를 따르지 않을 수 있다는 것입니다. 시간이 지남에 따라. 결과적으로 FFO 추정 시 탐구할 다른 요소는 다음과 같습니다. • 성과 내역: 보고서의 정확성과 적시성, 가동 시간을 포함한 운영자의 성과 내역은 목표를 제공합니다. 사용자가 신뢰성을 평가할 수 있는 시금석입니다. 실적 내역은 다음과 같습니다. 사용자가 oracle 노드를 선택하는 데 중요한 요소를 제공합니다(또는 출현과 함께). DON 중, DON 중 선택). 강력한 실적 이력이 있을 가능성이 높습니다. 지속적인 높은 수익과 상관관계가 있습니다.18 18우리가 다루고자 하는 중요한 연구 문제는 위조된 서비스 양을 탐지하는 것입니다.그림 17: 단일 데이터 피드(ETH-USD)에서 Chainlink 노드가 얻은 수익 2021년 3월의 대표적인 주간. • 데이터 액세스: oracles는 개방형 API에서 다양한 형태의 데이터를 얻을 수 있지만 특정 형태의 데이터나 특정 고품질 소스는 구독 기반 또는 계약 계약을 통해. 특정에 대한 특권적 접근 데이터 소스는 안정적인 수익원을 창출하는 역할을 할 수 있습니다. • DON 참여: DONs의 출현으로 노드 커뮤니티가 등장할 것입니다. 특별한 서비스를 제공하기 위해 함께 모입니다. 많은 DON에 포함될 것으로 예상됩니다. 선택적으로 운영자를 통해 평판이 좋은 DON에 참여하도록 설정합니다. 일관된 수익원을 보장하는 데 도움이 되는 특권적인 시장 지위. • 크로스 플랫폼 활동: 일부 노드 운영자는 PoS validators 또는 blockchain 이외의 컨텍스트의 데이터 공급자. 이러한 다른 시스템에서의 성과(데이터가 신뢰할 수 있는 형식으로 제공되는 경우)는 평가에 정보를 제공할 수 있습니다. 그들의 공연 기록. 마찬가지로 Chainlink 네트워크의 잘못된 동작 사용자를 몰아냄으로써 다른 시스템의 수익을 위태롭게 할 수 있습니다(예: FFO). 여러 플랫폼으로 확장할 수 있습니다. 9.6.2 투기적 FFO 노드 운영자는 단지 수익을 창출하기 위해 Chainlink 네트워크에 참여하지 않습니다. 그러나 작업을 실행하기 위한 새로운 기회를 활용하기 위해 스스로를 만들고 위치를 정하는 것입니다. 즉, 네트워크 내 oracle 노드의 지출도 DeFi 및 기타 스마트 계약 애플리케이션의 미래에 대한 긍정적인 진술 도메인뿐만 아니라 oracle 네트워크의 새로운 비 blockchain 애플리케이션도 포함됩니다. 오늘날 노드 운영자는 기존 Chainlink 네트워크에서 사용 가능한 수수료를 얻는 동시에 동시에 이는 문제가 인터넷 사이트에서 더 쉽다는 점을 제외하면 인터넷 사이트의 가짜 리뷰와 어느 정도 유사합니다. oracle 상품이 주문되었는지, 즉 보고서가 주문되었는지에 대한 확실한 기록이 있기 때문에 설정됩니다. 예를 들어 온라인 상점에서 주문한 실제 상품과 반대되는 배송입니다. 다른 말로 하면 oracle에서 고객의 진실성은 검증할 수 없더라도 설정을 통해 성능을 검증할 수 있습니다.평판, 실적 이력, 운영 전문성을 구축하여 입지를 다질 것입니다. 미래 네트워크에서 사용할 수 있는 수수료를 얻는 데 유리합니다(물론 조건에 따라). 정직한 행동에 대해). 현재 Chainlink 생태계에서 운영되는 노드는 다음과 같습니다. Chainlink 추가 수수료를 받는 데 신규 이민자보다 유리하다는 의미입니다. 서비스가 가능해집니다. 이러한 이점은 새로운 운영업체는 물론 평판이 좋은 기술 회사에도 적용됩니다. 예를 들어 T-Systems는 전통적인 기술 제공업체(Deutsche Telekom의 자회사)와 대규모 중앙 집중식 회사인 Kraken Exchange는 Chainlink 생태계 [28, 143]에서 초기 입지를 구축했습니다. 향후 기회에 oracle 노드가 참여하는 것은 그 자체로 간주될 수 있습니다. 일종의 투기적 FFO로서 Chainlink의 지분 형태를 구성합니다. 네트워크. 9.6.3 외부 평판 우리가 설명한 대로 IIF는 엄격한 가명으로 네트워크에서 작동할 수 있습니다. 즉, 관련된 사람이나 실제 실체를 공개하지 않습니다. 그러나 사용자가 공급자를 선택할 때 잠재적으로 중요한 요소 중 하나는 외부입니다. 평판. 외부 평판이란 가명이 아닌 실제 신원에 부여된 신뢰성에 대한 인식을 의미합니다. 평판 위험 실제 정체성은 암묵적인 인센티브의 한 형태로 볼 수 있습니다. 평판을 본다 즉, 암호경제학적 의미에서 IIF의 렌즈를 통해 FFO 추정치에 통합될 수 있는 크로스 플랫폼 활동. FFO 추정의 요인으로 외부 평판을 사용하는 이점은 이와 반대로 가명 연결은 외부 평판이 성과를 단순히 연결하는 것이 아니라 운영자의 기존 활동뿐만 아니라 향후 활동에도 적용됩니다. 예를 들어 평판이 좋지 않은 경우 개인에게 부착되면 그 사람의 미래 사업을 오염시킬 수 있습니다. 다르게 말하면, 외부 평판은 가명보다 더 넓은 범위의 FFO를 포착할 수 있습니다. 개인 또는 확립된 불법 행위의 영향으로서의 성과 기록 회사는 가명 운영과 관련된 것보다 탈출하기가 더 어렵습니다. Chainlink은(는) 분산형 ID 기술(섹션 4.3)과 호환됩니다. IIF에서 외부 평판 사용에 대한 지원을 제공할 수 있습니다. 이러한 기술 운영자가 주장하는 실제 세계의 진실성을 검증하고 보장하는 데 도움이 될 수 있습니다. 신원.19 9.6.4 IIF 분석 열기 앞서 언급했듯이 IIF는 신뢰할 수 있는 오픈 소스 데이터와 도구를 제공하는 것을 목표로 합니다. 암시적 인센티브 분석. 목표는 지역사회 내에서 서비스 제공자를 활성화하는 것입니다. 다양한 부분의 위험 평가 요구에 맞는 분석을 개발합니다. Chainlink 사용자 기반. 19분산형 신원 증명은 원하는 경우 검증된 인증을 통해 가명을 장식할 수도 있습니다. 보충 정보. 예를 들어, 노드 운영자는 원칙적으로 그러한 자격 증명을 사용하여 다음을 수행할 수 있습니다. 어떤 회사인지 밝히지 않고 Fortune 500대 기업임을 입증합니다.노드의 수익 및 성능에 관한 상당한 양의 과거 데이터 신뢰도가 높고 변경 불가능한 형태로 체인에 상주합니다. 그러나 우리의 목표는 오직 눈에만 보이는 행동에 대한 데이터를 포함한 가장 포괄적인 데이터 오프체인 보고(OCR) 또는 DON 활동과 같은 체인. 이러한 데이터는 잠재적으로 방대하다. 데이터를 저장하고 무결성을 보장하는 가장 좋은 방법입니다. 변조는 논의된 기술을 사용하여 DONs의 도움을 받을 것이라고 믿습니다. 섹션 3.3에서. 일부 인센티브는 staking와 같은 직접적인 측정 형태에 적합합니다. 예금 및 기본 FFO. 투기적 FFO 및 평판과 같은 다른 것들은 파악하기가 더 어렵습니다. 객관적인 방식으로 측정하지만, 다음을 포함한 뒷받침하는 데이터 형태가 있다고 믿습니다. Chainlink 생태계의 역사적 성장, 평판에 대한 소셜 미디어 지표 등 정량화하기 어려운 요소에 대해서도 IIF 분석 모델을 지원할 수 있습니다. 우리는 특별히 모니터링, 검증 및 확인을 위해 전용 DON이 발생한다고 상상할 수 있습니다. 노드의 오프체인 성능 기록과 관련된 데이터 및 기타 데이터를 기록합니다. 검증된 신원 정보와 같이 IIF에서 사용됩니다. 이러한 DON은 Chainlink 커뮤니티에 서비스를 제공하는 모든 분석 제공자에게 균일하고 신뢰도가 높은 IIF 데이터를 제공할 수 있습니다. 또한 분석 제공업체의 주장을 뒷받침하는 황금 기록을 제공할 것입니다. 커뮤니티에서 독립적으로 검증할 수 있습니다. 9.7 종합적으로: 노드 운영자 인센티브 노드 운영자에 대한 명시적 및 암시적 인센티브에 대한 위의 논의를 종합합니다. 노드 운영자가 참여하고 혜택을 받는 방식에 대한 전체적인 관점을 제공합니다. Chainlink 네트워크. 개념적 가이드로서 주어진 Chainlink에 의해 위험에 처한 총 자산을 표현할 수 있습니다. 노드 연산자 $S는 다음과 같이 대략적으로 양식화된 형식으로 표시됩니다. \(S ≈\)D + \(F + \)FS + $R, 여기서: • $D는 모든 네트워크에 걸쳐 명시적으로 예치된 모든 지분의 합계입니다. 운영자가 참여합니다. • $F는 모든 네트워크에 걸쳐 모든 FFO를 합산한 순 현재 가치입니다. 운영자가 참여하는 것; • $FS는 운영자의 투기적 FFO의 순 현재 가치입니다. 그리고 • $R은 Chainlink 생태계 외부 운영자의 평판 자산입니다. oracle 노드에서 확인된 오작동으로 인해 위험에 처할 수 있습니다. 대체로 개념적이지만, 이 대략적인 동등성은 Chainlink 노드의 높은 신뢰성 성능을 선호하는 다양한 경제적 요인이 있음을 유용하게 보여줍니다. $D를 제외한 이러한 모든 요소는 오늘날의 Chainlink 네트워크에 존재합니다.9.8 경제 안보의 선순환 초선형 staking 영향과 수수료 지불 표현의 조합 IIF의 미래 수수료 기회(FFO)는 우리가 선순환이라고 부르는 것으로 이어질 수 있습니다. oracle 네트워크의 경제적 안정. 일종의 경제라고 볼 수 있다. 규모의. 특정 네트워크가 확보한 총액이 늘어날수록 고정된 양의 경제적 안정을 추가하는 데 필요한 추가 지분은 감소합니다. 평균 사용자당 비용. 따라서 사용자가 가입하는 것이 수수료 측면에서 더 저렴합니다. 동일한 네트워크 경제성 증가를 달성하는 것보다 이미 존재하는 네트워크를 사용하는 것보다 새로운 네트워크를 생성하여 보안을 강화합니다. 중요한 것은 각각의 신규 사용자 추가가 낮아진다는 것입니다. 해당 네트워크의 모든 이전 사용자에 대한 서비스 비용. 특정 수수료 구조(예: 스테이킹된 금액에 대한 특정 수익률)를 고려하면 네트워크가 벌어들이는 총 수수료가 증가하면 이는 추가 자금 흐름을 장려합니다. 더 높은 비율로 네트워크를 보호하려면 네트워크에 지분을 투자하세요. 특히, 총 지분이 개별 노드가 시스템에 보유할 수 있는 한도가 제한되어 있으며, 새로운 수수료 지불 시 시스템에 들어가서 FFO를 높이면 노드 수 n이 증가합니다. 덕분에 인센티브 시스템 설계의 초선형 staking 영향, 경제적 안정 시스템은 n보다 빠르게 상승할 것입니다. 예를 들어 섹션 9.4에서 설명한 메커니즘의 n2와 같습니다. 결과적으로 경제적 안정을 위한 평균 비용, 즉 기여하는 지분의 양은 1달러의 경제적 안정이 떨어질 것입니다. 따라서 네트워크는 사용자에게 요금을 청구할 수 있습니다. 더 낮은 수수료. oracle 서비스에 대한 수요가 탄력적이라고 가정합니다(예: 간략한 내용은 [31] 참조). 설명) 수요가 증가하여 추가 수수료와 FFO가 발생합니다. 다음 예를 통해 이 점을 설명합니다. 예시 5. 인센티브를 통해 oracle 네트워크의 경제적 보안이 강화된 이후 계획은 \(dn2 for stake \)dn이며, 1달러 지분으로 인한 경제적 안정입니다. n은 경제적 안정의 달러당 평균 비용, 즉 지분의 양입니다. 1달러의 경제적 안정에 기여하는 금액은 1/n입니다. 경제적 인센티브가 전적으로 FFO로 구성된 네트워크를 생각해 보세요. 노드당 \(d ≤\)10K입니다. 네트워크에 n = 3개의 노드가 있다고 가정합니다. 그러면 평균비용 경제적 안정의 1달러당 약 0.33달러입니다. 네트워크의 총 FFO가 \(30K (e.g., to \)31K 이상으로 증가한다고 가정합니다. 주어진 노드당 FFO의 한도를 늘리면 네트워크는 (적어도) n = 4로 성장합니다. 이제 평균 비용은 경제적 안정의 1달러당 약 0.25달러로 떨어집니다. 우리는 그림 18에서 oracle 네트워크의 경제적 안정의 전체 선순환을 개략적으로 설명합니다. 경제 안보의 선순환은 다음과 같은 효과에서 비롯된다는 점을 강조합니다. 사용자가 수수료를 합산합니다. 더 큰 이익을 위해 일하는 것은 그들의 집단 FFO입니다. 네트워크 규모가 커지고 집단 보안이 강화됩니다. 우리는 또한 선순환이 경제적 안정은 DON의 재정적 지속 가능성 달성에 유리합니다. 한 번 사용자 요구 사항을 해결하는 DON이 생성된 지점 이상으로 성장해야 합니다. 수수료 수익이 oracle 노드의 운영 비용을 초과합니다.
그림 18: Chainlink staking의 선순환 도식. 사용자 수수료 인상 oracle 네트워크 1⃝에 지불하면 네트워크가 성장하고 경제적 성장으로 이어집니다. 보안 2⃝. 이러한 초선형 성장은 Chainlink 네트워크에서 규모의 경제를 실현합니다. 3⃝. 구체적으로 이는 경제적 안정을 위한 평균 비용의 감소를 의미합니다. 수수료 지불 또는 기타 지분 소스에서 발생하는 달러당 경제적 안정 증가합니다. 비용 절감이 사용자에게 전달되어 oracle에 대한 수요 증가를 촉진합니다. 서비스 4⃝. 9.9 네트워크 성장을 이끄는 추가 요인 Chainlink 생태계가 계속 확장됨에 따라 우리는 그 매력을 믿습니다. blockchain 경제를 위한 인프라로서의 중요성이 가속화될 것입니다. oracle 네트워크가 제공하는 가치는 초선형적이므로 더 빠르게 성장합니다.네트워크 자체의 크기보다 이러한 가치 성장은 두 가지 모두에서 비롯됩니다. 규모의 경제 - 서비스 양이 증가함에 따라 사용자당 비용 효율성이 향상됩니다. 네트워크 효과 - 사용자가 DON을 더 광범위하게 채택함에 따라 네트워크 유틸리티가 증가합니다. 기존 smart contract은 계속해서 더 많은 가치를 확보하고 완전히 새로운 것을 보여줍니다. smart contract 애플리케이션은 보다 분산화된 서비스를 통해 가능해지며, 총 DONs의 사용 및 총 수수료가 증가해야 합니다. 수수료 풀 증가 더욱 분산화된 서비스를 창출하기 위한 수단과 인센티브로 전환됩니다. 결과적으로 선순환이 됩니다. 이 선순환은 닭고기와 달걀의 중요한 문제를 해결합니다. 하이브리드 smart contract 생태계의 문제: 혁신적인 smart contract 기능 아직 존재하지 않는 분산형 서비스가 필요한 경우가 많습니다(예: 새로운 DeFi 시장이 자주 발생함) 새로운 데이터 피드가 필요하지만 존재하기 위해서는 충분한 경제적 수요가 필요합니다. 기존 DON에 대한 다양한 smart contract의 수수료 풀링은 다음에 대한 수요를 나타냅니다. 증가하는 사용자 기반에서 추가 분산형 서비스를 생성하여 생성 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의 진화에 대한 비전을 제시했습니다. 주요 테마 이 비전에는 훨씬 더 광범위한 서비스를 제공할 수 있는 네트워크의 능력이 있습니다. 단순한 데이터 전달보다 smart contracts. DON을 미래의 분산형 서비스의 기반으로 사용하여 Chainlink은 성능과 기밀성이 강화된 oracle 기능을 제공하는 것을 목표로 합니다. oracle 네트워크는 강력한 신뢰 최소화를 제공합니다. staking과 같은 원칙적인 암호 경제 메커니즘의 조합을 통해 메인 체인에 의존하여 신중하게 고안된 가드레일과 서비스 수준 시행. DONs는 또한 레이어 2 시스템이 트랜잭션에 대해 유연하고 공정한 주문 정책을 시행하고 멤풀 라우팅 트랜잭션에 대한 가스 비용을 줄이는 데 도움이 됩니다. 함께 찍은, 이러한 기능은 모두 안전하고 풍부한 기능을 갖춘 하이브리드 스마트의 방향으로 나아가고 있습니다. 계약. DONs의 유연성은 기존 Chainlink 서비스를 향상시키고 많은 추가 smart contract 기능 및 응용 프로그램. 그 중에는 원활한 다양한 오프체인 시스템과의 연결, 분산형 ID 생성 기존 데이터, 인프라에 중요한 정보를 적시에 제공하는 데 도움이 되는 우선순위 채널 거래 및 기밀 유지 DeFi 도구. 우리가 여기서 제시한 비전은 야심적입니다. 단기적으로는 역량 강화를 추구합니다. 현재 smart contracts의 도달 범위를 넘어서는 목표를 달성하기 위한 하이브리드 계약을 체결하는 동시에 장기적으로 우리는 분산형 금속층을 구현하는 것을 목표로 하고 있습니다. 행복하게 그릴 수 있어요 합의 알고리즘부터 영지식 증명까지 다양한 새로운 도구와 아이디어 빠르게 발전하는 연구의 결과로 커뮤니티가 발전하고 있는 시스템입니다.
마찬가지로, 우리는 이에 대한 대응으로 이 백서의 아이디어 구현을 우선시할 것으로 기대합니다. Chainlink 사용자 커뮤니티의 요구에 부응합니다. 우리는 다음 단계를 기대합니다 보편적인 연결을 통해 smart contracts에게 권한을 부여하고 세계 차세대 금융의 중추로서의 분산형 기술 그리고 법률 시스템. 감사의 말 이 문서에 그림을 제공한 Julian Alterini와 Shawn Lee에게 감사드립니다.