Polkadot: 이기종 다중 체인 프레임워크에 대한 비전
概要
POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 DR.ギャビン・ウッド 創設者、イーサリアム、パリティ ギャビン@PARITY.IO 抽象的。現在の blockchain アーキテクチャはすべて、拡張性とスケーラビリティの実際的な手段をはじめとする多くの問題を抱えています。私たちは、これはコンセンサス アーキテクチャの 2 つの非常に重要な部分を結び付けることに起因すると考えています。 正規性と有効性が近すぎる。この論文では、異種マルチチェーンというアーキテクチャを紹介します。 これが根本的にこの 2 つを区別します。 これら 2 つの部分を区分けし、提供される全体的な機能を最小限に抑えることで、 セキュリティとトランスポートの観点から、現場でのコア拡張性の実用的な手段を導入します。スケーラビリティには次のような方法があります。 これら 2 つの機能に対する分割統治アプローチであり、 信頼できないパブリックノード。 このアーキテクチャの異質な性質により、多くの非常に多様なタイプのコンセンサス システムがトラストレスで完全に分散された「フェデレーション」で相互運用できるようになり、オープン ネットワークとクローズド ネットワークがトラストフリーでアクセスできるようになります。 お互いに。 私たちは、次のような 1 つ以上の既存のネットワークとの下位互換性を提供する手段を提案します。 Ethereum。私たちは、このようなシステムが、実用的なシステムの全体的な探索において有用な基本レベルのコンポーネントを提供すると信じています。 グローバルコマースレベルのスケーラビリティとプライバシーを実現できる実装可能なシステム。 1. はじめに これは技術的な「ビジョン」の概要を目的としています。 blockchain パラダイムをさらに発展させる際に取られる可能性のある 1 つの方向性と、この方向性が合理的である理由についての理論的根拠を示します。にレイアウトされます 開発のこの段階で可能な限り詳細を 具体的な改善をもたらす可能性のあるシステム blockchain テクノロジーのさまざまな側面。 これは、形式的であるかどうかにかかわらず、仕様を意図したものではありません。包括的であることや、 最終デザイン。コア以外の側面をカバーすることを目的としたものではありません API、バインディング、言語などのフレームワークの 使用法。 これは特に実験的なものです。ここでパラメータ 指定されていますが、変更される可能性があります。メカニズムは、 コミュニティに応じて追加、改良、削除される アイデアと批評。この文書の大部分は、おそらく 実験的証拠やプロトタイピングによって得られるものとして改訂される 何が機能し、何が機能しないのかについての情報を提供します。 この文書には、プロトコルの核となる説明と、取るべき方向性のアイデアが含まれています。 さまざまな面を改善するために。コアとなると想定されるのは、 説明は最初の作業の開始点として使用されます。 一連の概念実証。最終的な「バージョン 1.0」は次のようになります。 この洗練されたプロトコルと、実証され決定された追加のアイデアをベースにしています。 プロジェクトが目標を達成するために必要です。 1.1.歴史。 • 2016 年 9 月 10 日: 0.1.0 耐性 1 • 2016/10/20: 0.1.0-proof2 • 2016 年 11 月 1 日: 0.1.0-proof3 • 2016 年 10 月 11 日: 0.1.0 2. はじめに ブロックチェーンは、「モノのインターネット」を含むいくつかの分野で有用性が大いに期待できることが証明されています。 (IoT)、財務、ガバナンス、アイデンティティ管理、ウェブ分散化、資産追跡。しかし、にもかかわらず、 技術的な約束と壮大な話はまだわかりません 現在のテクノロジーの重要な現実世界への展開。 私たちは、これは現在の 5 つの主要な失敗に起因すると考えています。 テクノロジースタック: スケーラビリティ: 世界中でどれだけのリソースが費やされているか システムが単一のトランザクションを処理するための処理、帯域幅、およびストレージ、およびそのトランザクション数 トランザクションは以下に基づいて合理的に処理できます ピークコンディション? 分離性: 複数の異なるニーズに対応できるか 関係者とアプリケーションは、同じフレームワークの下で最適に近い程度まで対処できるでしょうか? 開発性: ツールはどの程度うまく機能しますか?する API は開発者のニーズに対応しているでしょうか?教育用の教材はありますか?適切な統合は行われていますか? ガバナンス: ネットワークは柔軟性を維持できるか 時間の経過とともに進化して適応しますか? 決定は可能ですか 十分な包括性、正当性、そして 効果的なリーダーシップを発揮するための透明性 分散型システム? 適用可能性: そのテクノロジーは実際にそれ自体で切実なニーズに対応しているのでしょうか?ギャップを埋めるには他の「ミドルウェア」が必要ですか? 実際のアプリケーションは? 現在の作業では、最初の 2 つに対処することを目指しています。 問題: スケーラビリティと分離性。そうは言っても、私たちは信じています Polkadot フレームワークは、これらの問題のそれぞれのクラスにおいて有意義な改善を提供できます。 最新の効率的な blockchain 実装 パリティ Ethereum クライアント [17] は proc できます超過 高性能のコンシューマ ハードウェアで実行すると、1 秒あたり 3,000 トランザクション。 しかし、現在の現実世界では、 blockchain ネットワークは実質的に約 30 に制限されています 1秒あたりのトランザクション数。 この制限は主に、現在の同期コンセンサス メカニズムが広いタイミング安全マージンを必要とするという事実に起因しています。 予想される処理時間は、 1
초록
POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 박사. 개빈 우드 창립자, 이더리움 및 패리티 개빈@PARITY.IO 추상. 현재의 blockchain 아키텍처는 모두 확장성과 확장성의 실질적인 수단뿐만 아니라 여러 가지 문제로 어려움을 겪고 있습니다. 우리는 이것이 합의 아키텍처의 두 가지 매우 중요한 부분을 연결하는 데서 비롯된다고 믿습니다. 정준성과 타당성은 너무 밀접하게 연관되어 있습니다. 본 논문에서는 이종 다중 체인 아키텍처인 아키텍처를 소개합니다. 이는 근본적으로 두 가지를 구분합니다. 이 두 부분을 구분하고 전체적인 기능을 최소한으로 유지함으로써 보안 및 운송 측면에서 핵심 확장성을 위한 실용적인 수단을 현장에서 소개합니다. 확장성은 다음을 통해 해결됩니다. 이 두 가지 기능에 대한 분할 및 정복 접근 방식은 인센티브를 통해 결합된 핵심을 확장합니다. 신뢰할 수 없는 공개 노드. 이 아키텍처의 이질적인 특성으로 인해 무신뢰, 완전 분산형 "연합"에서 상호 운용되는 다양한 유형의 합의 시스템이 가능해지며 개방형 네트워크와 폐쇄형 네트워크가 신뢰 없이 액세스할 수 있습니다. 서로. 우리는 다음과 같은 하나 이상의 기존 네트워크와의 하위 호환성을 제공하는 수단을 제시합니다. Ethereum. 우리는 그러한 시스템이 실질적으로 전반적인 검색에 유용한 기본 수준 구성 요소를 제공한다고 믿습니다. 글로벌 상거래 수준의 확장성과 개인 정보 보호를 달성할 수 있는 구현 가능한 시스템입니다. 1. 서문 이는 기술적인 "비전" 요약을 위한 것입니다. blockchain 패러다임을 더욱 발전시키는 데 취할 수 있는 한 가지 가능한 방향과 이 방향이 왜 합리적인지에 대한 몇 가지 근거를 설명합니다. 그것은에 배치 현재 개발 단계에서 가능한 한 많은 세부정보를 제공합니다. 구체적인 개선을 제공할 수 있는 시스템 blockchain 기술의 다양한 측면. 이는 공식적이거나 다른 방식으로 사양을 제시하려는 의도가 없습니다. 포괄적이거나 포괄적인 의도는 아닙니다. 최종 디자인. 핵심이 아닌 측면을 다루려는 의도는 없습니다. API, 바인딩, 언어 등 프레임워크의 사용법. 이는 특히 실험적입니다. 여기서 매개변수 지정되어 있으므로 변경될 가능성이 있습니다. 메커니즘은 커뮤니티에 대한 반응으로 추가, 개선 및 제거됩니다. 아이디어와 비평. 이 문서의 많은 부분이 실험적 증거와 프로토타입을 통해 수정될 수 있습니다. 무엇이 효과가 있고 무엇이 효과가 없는지에 대한 정보를 제공합니다. 이 문서에는 프로토콜에 대한 핵심 설명과 함께 취할 수 있는 방향에 대한 아이디어가 포함되어 있습니다. 다양한 측면을 개선합니다. 핵심이 될 것으로 예상된다. 설명은 초기 작업의 시작점으로 사용됩니다. 일련의 개념 증명. 최종 "버전 1.0"은 다음과 같습니다. 입증되고 다음으로 결정된 추가 아이디어와 함께 이 세련된 프로토콜을 기반으로 합니다. 프로젝트가 목표를 달성하기 위해 필요합니다. 1.1. 역사. • 2016년 9월 10일: 0.1.0-proof1 • 2016년 10월 20일: 0.1.0-proof2 • 2016년 1월 11일: 0.1.0-proof3 • 2016년 10월 11일: 0.1.0 2. 소개 블록체인은 "사물 인터넷"을 포함한 여러 분야에서 큰 유용성을 보여주었습니다. (IoT), 금융, 거버넌스, ID 관리, 웹 분산화 및 자산 추적. 그러나 그럼에도 불구하고 기술적 약속과 거창한 이야기, 우리는 아직 보지 못했습니다 현재 기술의 중요한 실제 배포. 우리는 이것이 현재의 다섯 가지 주요 실패로 귀결된다고 믿습니다. 기술 스택: 확장성: 전 세계적으로 얼마나 많은 리소스가 소비되는지 단일 트랜잭션을 처리하는 시스템의 처리, 대역폭 및 저장 공간과 트랜잭션 수 거래는 다음과 같이 합리적으로 처리될 수 있습니다. 최고 조건? 격리성: 여러 회사의 다양한 요구 사항을 충족할 수 있습니까? 당사자와 신청서가 동일한 프레임워크에서 거의 최적의 수준으로 처리됩니까? 개발 가능성: 도구가 얼마나 잘 작동합니까? 마 API가 개발자의 요구 사항을 해결합니까? 교육자료가 있나요? 올바른 통합이 있습니까? 거버넌스: 네트워크가 유연하게 유지될 수 있습니까? 시간이 지남에 따라 진화하고 적응합니까? 결정이 가능할까요? 충분한 포용성, 정당성 및 투명성을 통해 효과적인 리더십을 제공합니다. 분산 시스템? 적용 가능성: 기술이 실제로 자체적으로 긴급한 요구 사항을 해결합니까? 격차를 해소하기 위해 다른 "미들웨어"가 필요합니까? 실제 응용? 현재 작업에서 우리는 처음 두 가지 문제를 해결하는 것을 목표로 합니다. 문제: 확장성 및 격리성. 즉, 우리는 믿습니다 Polkadot 프레임워크는 이러한 각 문제 클래스에서 의미 있는 개선을 제공할 수 있습니다. 다음과 같은 현대적이고 효율적인 blockchain 구현 패리티 Ethereum 클라이언트 [17]이(를) 실행할 수 있습니다.초과하다 고성능 소비자 하드웨어에서 실행 시 초당 3,000건의 트랜잭션. 그러나 현재 현실 세계에서는 blockchain 네트워크는 실질적으로 약 30개로 제한됩니다. 초당 트랜잭션. 이러한 제한은 주로 현재의 동기식 합의 메커니즘이 광범위한 타이밍 안전 마진을 요구한다는 사실에서 비롯됩니다. 예상되는 처리 시간으로 인해 악화됩니다. 1
導入
ブロックチェーンは、「モノのインターネット」を含むいくつかの分野で有用性が大いに期待できることが証明されています。 (IoT)、財務、ガバナンス、アイデンティティ管理、ウェブ分散化、資産追跡。しかし、にもかかわらず、 技術的な約束と壮大な話はまだわかりません 現在のテクノロジーの重要な現実世界への展開。 私たちは、これは現在の 5 つの主要な失敗に起因すると考えています。 テクノロジースタック: スケーラビリティ: 世界中でどれだけのリソースが費やされているか システムが単一のトランザクションを処理するための処理、帯域幅、およびストレージ、およびそのトランザクション数 トランザクションは以下に基づいて合理的に処理できます ピークコンディション? 分離性: 複数の異なるニーズに対応できるか 関係者とアプリケーションは、同じフレームワークの下で最適に近い程度まで対処できるでしょうか? 開発性: ツールはどの程度うまく機能しますか?する API は開発者のニーズに対応しているでしょうか?教育用の教材はありますか?適切な統合は行われていますか? ガバナンス: ネットワークは柔軟性を維持できるか 時間の経過とともに進化して適応しますか? 決定は可能ですか 十分な包括性、正当性、そして 効果的なリーダーシップを発揮するための透明性 分散型システム? 適用可能性: そのテクノロジーは実際にそれ自体で切実なニーズに対応しているのでしょうか?ギャップを埋めるには他の「ミドルウェア」が必要ですか? 実際のアプリケーションは? 現在の作業では、最初の 2 つに対処することを目指しています。 問題: スケーラビリティと分離性。そうは言っても、私たちは信じています Polkadot フレームワークは、これらの問題のそれぞれのクラスにおいて有意義な改善を提供できます。 最新の効率的な blockchain 実装 パリティ Ethereum クライアント [17] は、 高性能のコンシューマ ハードウェアで実行すると、1 秒あたり 3,000 トランザクション。 しかし、現在の現実世界では、 blockchain ネットワークは実質的に約 30 に制限されています 1秒あたりのトランザクション数。 この制限は主に、現在の同期コンセンサス メカニズムが広いタイミング安全マージンを必要とするという事実に起因しています。 予想される処理時間は、POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 2 遅い実装をサポートしたいと考えています。これは次の理由によるものです 基礎となるコンセンサスアーキテクチャ: 状態遷移メカニズム、または当事者が照合する手段 トランザクションを実行し、そのロジックは基本的に結合されています コンセンサス「正規化」メカニズム、または 当事者がいくつかの事項のうちの 1 つに同意する手段 可能性のある、有効な、履歴。 これは、Bitcoin [15] や Ethereum [5,23] などの proof-of-work (PoW) システムと、NXT [8] や Bitshares [12] などのプルーフオブステーク (PoS) システムの両方に同様に当てはまります。 最終的には全員が同じハンディキャップを負うことになります。シンプルです blockchain の成功に貢献した戦略。ただし、 これら 2 つの機構を 1 つのユニットに緊密に結合することにより、 プロトコルの複数の異なるプロトコルもバンドルします さまざまなリスク プロファイル、さまざまなスケーラビリティ要件、さまざまなプライバシー ニーズを持つアクターとアプリケーション。 1 つのサイズがすべてに適合するわけではありません。次のようなケースが非常に頻繁にあります。 広くアピールしたいという願望があるため、ネットワークはある程度の保守主義を採用し、その結果最小公倍数が低くなります 少数の人々に最適にサービスを提供し、最終的には失敗につながる 時には、革新し、実行し、適応する能力において 劇的にそうです。 いくつかのシステム、例えばFactom [21] は状態遷移メカニズムを完全に削除します。ただし、その多くは、 私たちが望む実用性には状態を遷移する能力が必要です 共有ステートマシンに従って。落とせば解決する 別の問題。代替手段は提供されません 解決策。 したがって、合理的な方向性の 1 つは明らかであるように思われます。 スケーラブルな分散コンピューティングへのルートとして探索する プラットフォームはコンセンサスアーキテクチャを分離することを目的としています。 状態遷移メカニズム。そして、おそらく驚くことではないでしょうが、これは Polkadot がスケーラビリティの解決策として採用している戦略です。 2.1.プロトコル、実装、およびネットワーク。いいね Bitcoin および Ethereum、Polkadot は、ネットワーク プロトコルと (これまで想定されていた) プライマリを同時に指します このプロトコルを実行するパブリック ネットワーク。 Polkadot は無料でオープンなプロジェクトであることを目的としており、プロトコル仕様はクリエイティブ コモンズ ライセンスに基づいており、 コードは FLOSS ライセンスの下に配置されます。プロジェクトは オープンな方法で開発され、貢献を受け入れます 役に立つ場所ならどこでも。 RFC のシステムと似ています Python 拡張提案により、次の手段が可能になります。 プロトコルの変更とアップグレードに関して公的に協力しています。 Polkadot プロトコルの初期実装 はパリティ Polkadot プラットフォームとして知られ、 API とともに完全なプロトコル実装を含める バインディング。他のパリティ blockchain 実装と同様に、 PPP は、パブリック ネットワークやネットワークに固有のものではなく、汎用の blockchain テクノロジー スタックとして設計されています。 民間/コンソーシアム運営。こうして発展したのが、 これまで、以下を含むいくつかの団体から資金提供を受けてきました。 英国政府からの補助金。 それにも関わらず、この文書では Polkadot について次のように説明しています。 パブリックネットワークのコンテキスト。私たちがパブリック ネットワークで想定している機能は、ネットワークで必要とされる機能のスーパーセットです。 代替設定(プライベートおよび/またはコンソーシアムなど)。さらに、この文脈では、Polkadot の全範囲は次のようになります。 より明確に説明され、議論されるべきです。これはつまり、 読者は、特定のメカニズムが Polkadot に直接関係のない説明 (他のパブリック ネットワークとの相互運用など) 非公開(「許可」)状況で展開される場合。 2.2.以前の作品。基礎となるコンセンサスを状態遷移から切り離すことが非公式に提案されている 少なくとも 2 年間はプライベートで活動していた――マックス・ケイは、社会の非常に初期の頃、そのような戦略の支持者であった。 Ethereum。 チェーンとして知られる、より複雑でスケーラブルなソリューション ファイバーは 2014 年 6 月に遡り、その後初めて公開されました 同年1、透過的なチェーン間実行メカニズムを提供する単一のリレーチェーンと複数の同種チェーンの主張を行いました。 デコヒーレンスには代償が支払われた トランザクション レイテンシによる - トランザクションを必要とする システムの異なる部分を調整することで、 処理に時間がかかります。 Polkadot は、そのアーキテクチャの多くを、それとその後の会話から取り入れています。 ただし、その設計と規定の多くは大きく異なります。 Polkadot に匹敵するシステムはありませんが、 実際に実稼働中であり、何らかの関連性を持ついくつかのシステム 提案されているが、実質的なレベルではほとんどない 詳細。これらの提案は、システムに分解される グローバルに一貫性のある概念を削除または削減します。 ステート マシン、グローバルに提供しようとするもの 均質なシャードによるコヒーレントなシングルトン マシン 異質性のみを対象とするものもあります。 2.2.1.グローバル状態のないシステム。 Factom [21] は、対応するものなしで正規性を実証するシステムです。 有効性を高め、データの記録を効果的に可能にします。グローバルな状態と困難を回避するため これによってもたらされるスケーリングを考慮すると、スケーラブルなソリューションと考えることができます。ただし、前述したように、このセットは それによって解決される問題の割合は厳密かつ実質的に小さくなります。 Tangle [18] は、コンセンサス システムへの新しいアプローチです。 トランザクションをブロックに配置し、厳密にリンクされたリストに基づいて合意を形成して、状態変化の世界的に標準的な順序付けを行うのではなく、高度に構造化された順序付けの概念を大幅に放棄し、代わりに 初期の項目を正規化するのに役立つ、後の項目を持つ依存トランザクションの有向非巡回グラフを推進します。 明示的な参照を通じて。任意の状態変化の場合、 この依存関係グラフはすぐに手に負えなくなるでしょう。 ただし、より単純な UTXO モデル 2 の場合、これは次のようになります。 かなり合理的です。システムの一貫性は緩やかであり、トランザクションは通常、それぞれから独立しているためです。 その他、大量のグローバル並列処理が非常に多くなります。 自然な。 UTXO モデルを使用すると効果があります タングルを純粋に価値移転「通貨」に限定すること より一般的または拡張可能なものではなく、システムです。 さらに、厳密なグローバル一貫性がなければ、他のシステムとの相互作用は、絶対的なシステムを必要とする傾向があります。 システム状態に関するある程度の知識は非現実的になります。 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2 未使用のトランザクション出力。Bitcoin が使用するモデル。これにより、状態は事実上、ある値に関連付けられたアドレスのセットになります。 トランザクションはそのようなアドレスを照合し、合計が等しい新しいアドレスのセットに再構成します。
POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 3 2.2.2.異種チェーン システム。サイドチェーン [3] は メインの Bitcoin チェーン間のトラストレスな対話を可能にする Bitcoin プロトコルへの追加を提案 そして追加のサイドチェーン。何の規定もありません 側鎖間の「豊富な」相互作用の程度: 相互作用は、側鎖の相互作用を可能にするものに限定されます。 お互いの資産を管理し、地域内で影響を与える 専門用語—双方向ペッグ 3. 最終的なビジョンは、Bitcoin 通貨を提供できるフレームワークです。 ペギングによる追加機能 (周辺機能である場合) よりエキゾチックな状態遷移を伴う他のチェーンへ Bitcoin プロトコルで許可されているシステムを超えています。この意味で、 サイドチェーンは、スケーラビリティではなく拡張性に対処します。 実際、サイドチェーンの有効性に関する規定は基本的にありません。 1 つのチェーンからの token 個 (例: Bitcoin) サイドチェーンに代わって保持されるのは、 マイナーに正規化を促すサイドチェーンの機能 有効な遷移。 Bitcoin ネットワークのセキュリティ 他の人に代わって仕事に簡単に移行できない blockchain秒。さらに、Bitcoin を保証するためのプロトコル マイナーはマージマイニング (つまり、正規化権限をサイドチェーンの権限に複製します) し、さらに重要なことに、サイドチェーンの遷移が外部にあることを検証します。 この提案の範囲。 Cosmos [10] は、 サイドチェーンと同じ流れで、ナカモトのPoWを交換します Jae Kwon の Tendermint アルゴリズムのコンセンサス手法。 基本的に、それは複数のチェーン(で動作する)を記述します。 ゾーン) それぞれが Tendermint の個別のインスタンスを使用し、 マスターハブチェーン。このチェーン間通信は、任意の情報ではなく、デジタル資産 (「具体的には tokens について」) の転送に限定されていますが、このようなチェーン間通信にはデータのリターン パスがあり、 例:転送のステータスを送信者に報告するため。 ゾーンチェーンのバリデーターセット、特に 彼らを奨励する手段は、サイドチェーンと同様に、左にあります。 未解決の問題として。一般的な仮定は次のとおりです 各ゾーンチェーン自体は、validator の支払いに使用される値の token を保持します。まだ初期段階にある 設計の点で、現時点ではこの提案には、スケーラブルな設計を達成するための経済的手段に関する包括的な詳細が欠けています。 グローバルな妥当性に対する確実性。ただし、ゾーンとハブの間に必要な緩やかな一貫性により、 ゾーンのパラメータに対する柔軟性をさらに高めるため より強力なチェーンを適用するシステムのチェーンと比較して、 一貫性。 2.2.3.キャスパー。 Casper [6] と Polkadot の包括的なレビューや比較はまだ行われていません かなり広範囲に作成することもできますが、 (したがって不正確な) 2 つの特徴付け。 Casper は、PoS コンセンサス アルゴリズムの仕組みを再考したものです 参加者がどのフォークに賭けるかに基づいている可能性があります 最終的には正規化されるでしょう。ネットワークに対する堅牢性を確保するために十分な考慮が払われました 延長された場合でもフォークを使用し、基本的な Ethereum モデルに加えてある程度の追加のスケーラビリティを備えています。として このように、Casper はこれまでのところ、実質的に Polkadot やその前身よりも複雑なプロトコル、 基本的な blockchain 形式から大幅に逸脱しています。それ Casper が将来どのように反復するかはまだわかりません そして、それが最終的に展開された場合にどのようになるか。 Casper と Polkadot はどちらも興味深い新しいプロトコルであり、ある意味では、 Ethereum、両者の間には大きな違いがあります。 最終的な目標と導入までの道筋。 キャスパーは、 Ethereum 当初設計された財団中心のプロジェクト 意図せずにプロトコルの PoS 変更を行うこと 基本的にスケーラブルな blockchain を作成します。重要なことは、それは、 これ以上拡張的なものではなく、ハードフォークとして設計されているため、すべての Ethereum クライアントとユーザーは アップグレードするか、採用が不確実な分岐点に留まる必要があります。そのため、緊密な分散プロジェクトに特有のこととして、デプロイメントは大幅に困難になります。 調整が必要です。 Polkadot はいくつかの点で異なります。何よりもまず、 Polkadot は、完全に拡張可能でスケーラブルになるように設計されています。 blockchain 開発、展開、および対話テスト ベッド。これは、ほぼ将来性のあるハーネスとして構築されており、 新しいblockchainを同化する過度に複雑な分散型調整なしで利用できるテクノロジー またはハードフォーク。私たちはすでに次のようないくつかのユースケースを想定しています 暗号化されたコンソーシアムチェーンおよび高周波チェーンとして ブロック時間が非常に短いため、実行するのは非現実的です。 現在想定されている Ethereum の将来のバージョン。最後に、それと Ethereum との結合は非常に強力です。 緩い; Ethereum 側でのアクションは必要ありません。 2 つの間のトラストレスなトランザクション転送を有効にする ネットワーク。 つまり、Casper/Ethereum 2.0 および Polkadot いくつかのつかの間の類似点を共有しますが、私たちは彼らの最終目標を信じています 実質的に異なっており、競合するのではなく、 2 つのプロトコルは最終的には共存する可能性があります。 予見可能な将来にわたって相互に有益な関係を維持します。
소개
블록체인은 "사물 인터넷"을 포함한 여러 분야에서 큰 유용성을 보여주었습니다. (IoT), 금융, 거버넌스, ID 관리, 웹 분산화 및 자산 추적. 그러나 그럼에도 불구하고 기술적 약속과 거창한 이야기, 우리는 아직 보지 못했습니다 현재 기술의 중요한 실제 배포. 우리는 이것이 현재의 다섯 가지 주요 실패로 귀결된다고 믿습니다. 기술 스택: 확장성: 전 세계적으로 얼마나 많은 리소스가 소비되는지 단일 트랜잭션을 처리하는 시스템의 처리, 대역폭 및 저장 공간과 트랜잭션 수 거래는 다음과 같이 합리적으로 처리될 수 있습니다. 최고 조건? 격리성: 여러 회사의 다양한 요구 사항을 충족할 수 있습니까? 당사자와 신청서가 동일한 프레임워크에서 거의 최적의 수준으로 처리됩니까? 개발 가능성: 도구가 얼마나 잘 작동합니까? 마 API가 개발자의 요구 사항을 해결합니까? 교육자료가 있나요? 올바른 통합이 있습니까? 거버넌스: 네트워크가 유연하게 유지될 수 있습니까? 시간이 지남에 따라 진화하고 적응합니까? 결정이 가능할까요? 충분한 포용성, 정당성 및 투명성을 통해 효과적인 리더십을 제공합니다. 분산 시스템? 적용 가능성: 기술이 실제로 자체적으로 긴급한 요구 사항을 해결합니까? 격차를 해소하기 위해 다른 "미들웨어"가 필요합니까? 실제 응용? 현재 작업에서 우리는 처음 두 가지 문제를 해결하는 것을 목표로 합니다. 문제: 확장성 및 격리성. 즉, 우리는 믿습니다 Polkadot 프레임워크는 이러한 각 문제 클래스에서 의미 있는 개선을 제공할 수 있습니다. 다음과 같은 현대적이고 효율적인 blockchain 구현 패리티 Ethereum 클라이언트 [17]은 다음을 초과하여 처리할 수 있습니다. 고성능 소비자 하드웨어에서 실행 시 초당 3,000건의 트랜잭션. 그러나 현재 현실 세계에서는 blockchain 네트워크는 실질적으로 약 30개로 제한됩니다. 초당 트랜잭션. 이러한 제한은 주로 현재의 동기식 합의 메커니즘이 광범위한 타이밍 안전 마진을 요구한다는 사실에서 비롯됩니다. 예상되는 처리 시간으로 인해 악화됩니다.POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 2 더 느린 구현을 지원하려는 욕구. 이는 다음으로 인해 발생합니다. 기본 합의 아키텍처: 상태 전환 메커니즘 또는 당사자가 대조하는 수단 트랜잭션을 실행하고 논리가 근본적으로 묶여 있습니다. 합의된 "정규화" 메커니즘, 또는 당사자들이 다음 중 하나에 동의하는 것을 의미합니다. 가능한, 유효한, 역사. 이는 Bitcoin [15] 및 Ethereum[5,23]과 같은 proof-of-work(PoW) 시스템과 NXT [8] 및 Bitshares [12]과 같은 지분 증명(PoS) 시스템 모두에 동일하게 적용됩니다. 결국 모두 같은 핸디캡을 겪게 됩니다. 그것은 간단하다 blockchains의 성공을 도운 전략입니다. 그러나, 이 두 가지 메커니즘을 하나의 장치로 긴밀하게 결합함으로써 프로토콜의 여러 다른 프로토콜도 함께 번들로 묶습니다. 서로 다른 위험 프로필, 서로 다른 확장성 요구 사항, 서로 다른 개인 정보 보호 요구 사항을 가진 행위자와 애플리케이션. 하나의 크기가 모든 것에 적합하지는 않습니다. 너무 자주 그런 경우가 있습니다. 광범위한 호소력을 원하는 네트워크는 최소 공통 분모를 초래하는 어느 정도 보수주의를 채택합니다. 최적으로 소수에게만 서비스를 제공하고 궁극적으로 실패로 이어지는 경우 때로는 혁신하고, 수행하고, 적응하는 능력 극적으로 그렇습니다. 예를 들어 일부 시스템. 사실 [21] 상태 전환 메커니즘을 완전히 삭제했습니다. 그러나 대부분의 우리가 원하는 유용성을 위해서는 상태를 전환하는 능력이 필요합니다. 공유 상태 머신에 따르면. 놓으면 해결됨 대안적인 문제; 대안을 제공하지 않습니다 솔루션. 그러므로 하나의 합리적인 방향은 분명한 것 같습니다. 확장 가능한 분산 컴퓨팅에 대한 경로를 탐색합니다. 플랫폼은 합의 아키텍처를 분리하는 것입니다. 상태 전환 메커니즘. 그리고 아마도 이는 Polkadot이 확장성에 대한 솔루션으로 채택하는 전략입니다. 2.1. 프로토콜, 구현 및 네트워크. 좋아요 Bitcoin 및 Ethereum, Polkadot은 네트워크 프로토콜과 (지금까지 가정된) 기본 프로토콜을 동시에 나타냅니다. 이 프로토콜을 실행하는 공용 네트워크. Polkadot은 무료 개방형 프로젝트로 만들어졌으며 프로토콜 사양은 크리에이티브 커먼즈 라이센스에 따릅니다. 코드는 FLOSS 라이센스에 따라 배치됩니다. 프로젝트는 공개적으로 개발되었으며 기여를 받아들입니다. 어디에서나 유용합니다. 다르지 않은 RFC 시스템 Python Enhancement Proposals는 다음과 같은 수단을 허용합니다. 프로토콜 변경 및 업그레이드에 대해 공개적으로 협력합니다. Polkadot 프로토콜의 초기 구현 Parity Polkadot 플랫폼으로 알려지며 API와 함께 전체 프로토콜 구현을 포함합니다. 바인딩. 다른 Parity blockchain 구현과 마찬가지로, PPP는 공용 네트워크나 공용 네트워크를 위한 것이 아닌 범용 blockchain 기술 스택으로 설계되었습니다. 민간/컨소시엄 운영. 이에 따른 발전 지금까지 여러 당사자로부터 자금을 지원받았습니다. 영국 정부로부터 보조금을 받았습니다. 그럼에도 불구하고 이 문서에서는 Polkadot에 대해 설명합니다. 공용 네트워크의 컨텍스트. 우리가 공용 네트워크에서 구상하는 기능은 네트워크에서 요구되는 기능의 상위 집합입니다. 대체(예: 개인 및/또는 컨소시엄) 설정. 또한 이 맥락에서 Polkadot의 전체 범위는 다음과 같습니다. 더 명확하게 설명하고 논의할 수 있습니다. 이것은 의미합니다 독자는 특정 메커니즘이 Polkadot과 직접적으로 관련되지 않은 설명(예: 다른 공용 네트워크와의 상호 운용) 비공개("허가된") 상황에서 배포되는 경우. 2.2. 이전 작업. 국가 전환에서 기본 합의를 분리하는 것이 비공식적으로 제안되었습니다. 최소 2년 동안 개인적으로 —Max Kaye는 초기에 그러한 전략을 지지한 사람이었습니다. Ethereum. 체인(Chain)으로 알려진 더 복잡하고 확장 가능한 솔루션 섬유, 2014년 6월로 거슬러 올라가 나중에 처음 출판됨 그 해1, 투명한 체인 간 실행 메커니즘을 제공하는 단일 릴레이 체인과 여러 개의 동종 체인에 대한 사례가 만들어졌습니다. 결맞음이 지불되었습니다 트랜잭션 대기 시간을 통해—다음을 요구하는 트랜잭션 시스템의 서로 다른 부분을 조정하면 처리하는 데 시간이 더 걸립니다. Polkadot는 아키텍처의 대부분을 해당 아키텍처와 후속 대화에서 가져옵니다. 사람마다 다르지만 디자인과 조항의 상당 부분이 크게 다릅니다. Polkadot에 필적하는 시스템은 없지만 실제로 생산 중에는 어느 정도 관련성이 있는 여러 시스템이 있습니다. 제안되었지만 실질적인 수준은 거의 없습니다. 세부 사항. 이러한 제안은 다음과 같습니다.시스템으로 세분화 이는 전 세계적으로 일관성이 있다는 개념을 떨어뜨리거나 감소시킵니다. 상태 머신, 전역적으로 제공하려고 시도하는 머신 동종 샤드를 통한 일관된 싱글톤 머신 그리고 이질성만을 목표로 하는 것. 2.2.1. 전역 상태가 없는 시스템. Factom [21]은 다음 사항 없이 정규성을 입증하는 시스템입니다. 유효성을 확보하여 효과적으로 데이터를 기록할 수 있습니다. 글로벌 상태와 어려움을 회피하기 때문에 이것이 가져오는 확장성을 통해 확장 가능한 솔루션으로 간주될 수 있습니다. 그러나 앞서 언급한 바와 같이 세트는 그것이 해결하는 문제의 비율은 엄격하고 실질적으로 더 적습니다. Tangle [18]은 합의 시스템에 대한 새로운 접근 방식입니다. 트랜잭션을 블록으로 배열하고 엄격하게 연결된 목록을 통해 합의를 형성하여 상태 변경에 대한 전 세계적으로 표준적인 순서를 제공하는 대신 크게 구조화된 순서에 대한 아이디어를 포기하고 대신 이전 항목을 정규화하는 데 도움이 되는 이후 항목과 종속 트랜잭션의 방향성 비순환 그래프를 추진합니다. 명시적인 참조를 통해 임의의 상태 변경의 경우 이 종속성 그래프는 금방 다루기 어려워집니다. 그러나 훨씬 더 간단한 UTXO model2의 경우 이는 다음과 같습니다. 꽤 합리적이다. 시스템은 느슨하게 일관성이 있고 트랜잭션은 일반적으로 각 시스템과 독립적이기 때문입니다. 다른 한편으로, 많은 양의 전역 병렬성이 상당히 커집니다. 자연스러운. UTXO 모델을 사용하면 효과가 있습니다. Tangle을 순수한 가치 전달 "통화"로 제한하는 것 더 일반적이거나 확장 가능한 시스템이 아닙니다. 더욱이, 엄격한 글로벌 일관성이 없으면 절대적인 일관성이 필요한 경향이 있는 다른 시스템과의 상호 작용이 필요합니다. 시스템 상태에 대한 정도의 지식은 비실용적이 됩니다. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2미사용 트랜잭션 출력, Bitcoin이 사용하는 모델로 상태는 사실상 일부 값과 연관된 주소 세트입니다. 트랜잭션은 그러한 주소를 대조하여 총합이 동일한 새로운 주소 세트로 재구성합니다.
POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 3 2.2.2. 이종 체인 시스템. 사이드 체인 [3]은 메인 Bitcoin 체인 간의 무신뢰 상호 작용을 허용하는 Bitcoin 프로토콜에 대한 추가 제안 그리고 추가적인 사이드체인. 어떠한 조항도 없습니다 사이드체인 간의 '풍부한' 상호작용 정도: 상호작용은 사이드체인이 활성화될 수 있도록 제한됩니다. 지역에서 서로의 자산을 관리하는 관리자 전문 용어 - 양방향 페그 3. 최종 비전은 Bitcoin 통화가 제공될 수 있는 프레임워크에 대한 것입니다. 주변 장치인 경우 페깅을 통해 추가 기능 제공 좀 더 이국적인 상태 전환을 통해 다른 체인으로 Bitcoin 프로토콜이 허용하는 것보다 시스템. 이런 의미에서, 사이드체인은 확장성보다는 확장성을 다룹니다. 실제로 사이드체인의 유효성에 대한 규정은 근본적으로 없습니다. 한 체인의 token(예: Bitcoin) 사이드체인을 대신하여 보유하는 것은 오직 사이드체인에 의해서만 보호됩니다. 채굴자들이 정규화하도록 장려하는 사이드체인의 능력 유효한 전환. Bitcoin 네트워크의 보안 다른 사람을 대신하여 업무를 쉽게 전환할 수 없습니다. blockchains. 또한 Bitcoin을 보장하기 위한 프로토콜 채굴자는 병합 채굴(사이드 체인의 정규화 권한을 복제)하고 더 중요한 것은 사이드 체인의 전환이 외부에 있는지 확인하는 것입니다. 이 제안의 범위. Cosmos [10]는 제안된 다중 체인 시스템입니다. 사이드 체인과 동일한 맥락, Nakamoto PoW 교체 Jae Kwon의 Tendermint 알고리즘에 대한 합의 방법. 기본적으로 이는 여러 체인(운영 방식)을 설명합니다. 영역) 각각은 Tendermint의 개별 인스턴스를 사용하고 다음을 통한 무신뢰 통신 수단을 사용합니다. 마스터 허브 체인. 이 인터체인 통신은 임의의 정보가 아닌 디지털 자산("구체적으로 tokens")의 전송으로 제한되지만 이러한 인터체인 통신에는 데이터에 대한 반환 경로가 있습니다. 예를 들어 전송 상태를 발송인에게 보고합니다. 구역화된 체인에 대한 검증자 세트, 특히 그들에게 인센티브를 부여하는 수단은 사이드체인처럼 왼쪽에 있습니다. 해결되지 않은 문제로. 일반적인 가정은 다음과 같습니다. 각 존 체인은 자체적으로 validators에 대한 비용을 지불하는 데 인플레이션이 사용되는 token 가치를 보유합니다. 아직 초기 단계 디자인 측면에서 현재 제안에는 확장성을 달성하기 위한 경제적 수단에 대한 포괄적인 세부 정보가 부족합니다. 글로벌 타당성에 대한 확실성. 그러나 영역과 허브 사이에 필요한 느슨한 일관성으로 인해 구역화 매개변수에 대한 추가적인 유연성을 위해 더 강력하게 시행하는 시스템과 비교하여 체인 일관성. 2.2.3. 캐스퍼. 아직까지 Casper [6]과 Polkadot에 대한 포괄적인 검토나 병렬 비교는 없습니다. 꽤 대대적인 작품을 만들 수는 있지만 (따라서 부정확한) 둘의 특성화. Casper는 PoS 합의 알고리즘을 재구성한 것입니다. 어떤 포크에 베팅하는 참가자를 기반으로 할 수 있습니다. 궁극적으로 표준이 될 것입니다. 네트워크에 대한 견고성을 보장하기 위해 상당한 고려가 이루어졌습니다. 포크는 장기간에도 사용할 수 있으며 기본 Ethereum 모델 위에 어느 정도 추가 확장성을 제공합니다. 다음과 같이 따라서 캐스퍼는 현재까지 훨씬 더 많은 경향이 있습니다. Polkadot 및 그 조상보다 복잡한 프로토콜, 그리고 기본 blockchain 형식과 상당한 차이가 있습니다. 그것 캐스퍼가 미래에 어떻게 반복할지는 아직 알 수 없습니다 최종적으로 배포되면 어떤 모습일지. Casper와 Polkadot은 모두 흥미로운 새로운 프로토콜을 나타내며 어떤 의미에서는 Ethereum, 둘 사이에는 상당한 차이가 있습니다. 궁극적인 목표와 배포 경로. 캐스퍼는 Ethereum 원래 설계된 재단 중심 프로젝트 원하지 않는 프로토콜에 대한 PoS 변경이 되는 것입니다. 근본적으로 확장 가능한 blockchain을 만듭니다. 결정적으로는 더 광범위한 것이 아닌 하드 포크로 설계되었으므로 모든 Ethereum 클라이언트와 사용자는 업그레이드하거나 불확실한 채택을 유지해야 합니다. 따라서 배포가 빡빡한 분산형 프로젝트에 내재된 것처럼 배포가 훨씬 더 어려워집니다. 조정이 필요합니다. Polkadot는 여러 면에서 다릅니다. 무엇보다도, Polkadot은 완전히 확장 가능하고 확장 가능하도록 설계되었습니다. blockchain 개발, 배포 및 상호 작용 테스트 침대. 이는 미래에 대비할 수 있는 하네스로 제작되었습니다. 새로운 blockchain에 동화되다지나치게 복잡한 분산 조정 없이 사용 가능한 기술 또는 하드포크. 우리는 이미 다음과 같은 몇 가지 사용 사례를 구상하고 있습니다. 암호화된 컨소시엄 체인 및 고주파 체인 매우 낮은 블록 시간으로 인해 비현실적입니다. 현재 구상 중인 Ethereum의 향후 버전. 마지막으로, 그것과 Ethereum 사이의 결합은 매우 느슨하다; Ethereum 측의 조치는 필요하지 않습니다. 둘 사이의 무신뢰 트랜잭션 전달을 활성화합니다. 네트워크. 즉, Casper/Ethereum 2.0 및 Polkadot 우리가 그들의 최종 목표라고 생각하는 몇 가지 덧없는 유사성을 공유합니다. 실질적으로 다르며 경쟁하기보다는 두 프로토콜은 궁극적으로 하나의 환경 하에서 공존할 가능성이 높습니다. 가까운 미래에 상호 이익이 되는 관계.
まとめ
Polkadot は、スケーラブルな異種マルチチェーンです。これ 以前の blockchain 実装とは異なることを意味します さまざまなチェーンを単一チェーンで提供することに重点を置いています。 潜在的なアプリケーションに対する一般性の度合い、Polkadot それ自体は、アプリケーション固有の機能をまったく提供しないように設計されています。 むしろ、Polkadot が基盤を提供します 多数の検証可能な「リレーチェーン」、 グローバルに一貫性のある動的データ構造をホストできる 並んで。これらのデータ構造を「並列化」と呼びます。 チェーンまたはパラチェーン。ただし、特に必要なわけではありません。 それらは本質的にblockchainであると考えられます。 言い換えれば、Polkadot は独立したチェーンのセット (例: Ethereum、Ethereum Classic、Namecoin、および Bitcoin)、2 つの非常に重要な点を除きます。 • プールされたセキュリティ。 • トラストフリーのチェーン間取引可能性。 これらの点が、Polkadot が「スケーラブル」であると考える理由です。原則として、Polkadot にデプロイされる問題は、実質的に並列化、スケールアウトすることができます。 多数のパラチェーン。それぞれのあらゆる側面から、 パラチェーンは Polkadot ネットワークの異なるセグメントによって並行して実行される可能性があり、システムには何らかの機能があります スケールするために。 Polkadot は、かなり必要最低限の部分を提供します。 3一方向ペグとは対照的に、基本的に 1 つのチェーン内の token を破棄して、別のチェーンに token を作成します。 元の token を回復するために逆の処理を行うメカニズムPOLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 4 インフラストラクチャの複雑さの多くはミドルウェア レベルで解決される必要があります。これは開発リスクを軽減することを目的とした意識的な決定であり、 必要なソフトウェアを短期間で開発する必要がある そしてそのセキュリティには十分な自信があり、 堅牢性。 3.1. Polkadot の哲学。 Polkadot すべきです 絶対的な強固な基盤を提供します。 コンセンサス システムの次の波を即座に構築する 生産可能な成熟した設計からのリスクスペクトル 初期のアイデアに。 Polkadot は、セキュリティ、分離、通信に対する強力な保証を提供することで、 パラチェーン自体をさまざまなプロパティから選択します。 実際、私たちは、賢明であると考えられるものの特性を押し上げるさまざまな実験的な blockchain を予見しています。 今日。 私たちは保守的だと考えていますが、 ~に似た高価値チェーン Bitcoin または Z-cash [20] が低額と共存 「テーマチェーン」(このようなマーケティング、非常に楽しい)とテストネット 手数料はゼロ、またはほぼゼロです。 完全に暗号化されていることがわかります。 「ダーク」、コンソーシアム チェーンが並行して運営され、さらには 高機能でオープンなチェーンへのサービスの提供 Ethereum など。実験的な新しいものを見る 主観的な時間課金型の Wasm などの VM ベースのチェーン チェーンは、より成熟したEthereumのようなチェーンから難しい計算問題をアウトソーシングする手段として使用されています または、より制限された Bitcoin のようなチェーン。 チェーン アップグレードを管理するために、Polkadot は本質的に 何らかのガバナンス構造をサポートしている可能性が高い 既存の安定した政治制度と、イエローペーパー評議会[24]と同様の二院制の側面を持っています。として 最終的な権威である、根底にあるステーカブルtoken保有者が「国民投票」のコントロールを有することになる。ユーザーの意見を反映するため 開発の必要性はあるが、開発者の正当性の必要性も考慮すると、合理的な方向性は、 両院の「ユーザー」委員会(以下で構成) validators) と「技術」委員会が設立されました 主要なクライアント開発者とエコシステムプレーヤーの数。 の token 保有者の集団は究極の正当性を維持し、この構造を強化、再パラメータ化、置き換え、または解体する超多数派を形成するでしょう。 トウェインの言葉を借りれば、最終的には次のことが必要になることを疑ってはなりません。 「おむつもおむつも頻繁に交換しなければなりませんし、 同じ理由です。」 通常、再パラメータ化は大規模なコンセンサスメカニズム内で調整するのは簡単ですが、置き換えや増強などのより質的な変更は、 おそらく、自動化されていない「軟令」(例: ブロック番号の正規化と 新しいプロトコルを正式に指定する文書の hash) あるいは、核となるコンセンサスメカニズムに、 それ自体のあらゆる側面を説明するのに十分な豊かな言語 変更する必要があるかもしれません。後者は最終的な目標ですが、 ただし、次の目的では前者が選択される可能性が高くなります。 合理的な開発スケジュールを促進します。 Polkadot の主な信条とその中のルール 私たちはすべての設計上の決定事項を次のように評価します。 最小限: Polkadot にはできる限り機能を少なくする必要があります。 シンプル: 追加の複雑さは存在すべきではありません 基本プロトコルでは合理的に考えられる以上の ミドルウェアにオフロードされ、 を通して置かれる パラチェーン、または後の最適化で導入されました。 一般: 不必要な要件や制約はありません またはパラチェーンに制限を設ける必要があります。 Polkadot は、次の方法で最適化できるコンセンサス システム開発のテスト ベッドである必要があります。 拡張機能が適合するモデルを可能な限り抽象化します。 堅牢: Polkadot は基本的に 安定したベースレイヤー。これは、経済の健全性に加えて、最小限に抑えるための分散化も意味します。 高額な報酬をもたらす攻撃のベクトル。
요약
Polkadot은 확장 가능한 이종 다중 체인입니다. 이 이는 이전 blockchain 구현과 달리 다양한 단일 체인을 제공하는 데 중점을 두었습니다. 잠재적인 응용 프로그램에 대한 일반성 정도, Polkadot 자체적으로는 고유한 애플리케이션 기능을 전혀 제공하지 않도록 설계되었습니다. 오히려 Polkadot는 기반을 제공합니다. 다수의 검증 가능한 "릴레이 체인" 전 세계적으로 일관된 동적 데이터 구조가 호스팅될 수 있습니다. 나란히. 우리는 이러한 데이터 구조를 "병렬화"라고 부릅니다. 체인이나 파라체인이 특별히 필요하지는 않지만 본질적으로 blockchain입니다. 즉, Polkadot은 독립적인 체인 집합(예: 다음을 포함하는 집합)과 동일한 것으로 간주될 수 있습니다. Ethereum, Ethereum Classic, Namecoin 및 Bitcoin) 매우 중요한 두 가지 사항을 제외하고는 다음과 같습니다. • 공동 보안; • 신뢰할 수 없는 체인 간 거래 가능성. 이러한 점 때문에 우리는 Polkadot을 "확장 가능"하다고 간주합니다. 원칙적으로 Polkadot에 배포될 문제는 실질적으로 병렬화(규모 확장)될 수 있습니다. 다수의 파라체인. 각각의 모든 면에서 파라체인은 Polkadot 네트워크의 다른 세그먼트에 의해 병렬로 수행될 수 있습니다. 규모를 조정합니다. Polkadot은 다소 기본적인 부분을 제공합니다. 3한 체인의 token을 파괴하여 다른 체인의 token을 생성하는 단방향 페그와는 대조적입니다. 원래 tokens를 복구하기 위해 대화를 수행하는 메커니즘POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 4 미들웨어 수준에서 해결해야 할 복잡성이 상당 부분 남아 있습니다. 이는 개발 위험을 줄이기 위한 의식적인 결정입니다. 단기간 내에 개발해야 하는 필수 소프트웨어 그리고 보안에 대해 상당한 수준의 확신을 가지고 있으며, 견고성. 3.1. Polkadot의 철학. Polkadot 해야 합니다 절대적으로 견고한 기초를 제공합니다. 다음 단계의 합의 시스템을 구축하세요. 생산 가능한 성숙한 설계의 위험 스펙트럼 초기 아이디어에. 보안, 격리 및 통신에 대한 강력한 보장을 제공함으로써 Polkadot은(는) 다음을 허용할 수 있습니다. 다양한 속성 자체 중에서 선택할 수 있는 파라체인. 실제로 우리는 합리적인 것으로 간주될 수 있는 속성을 강화하는 다양한 실험적 blockchain을 예상합니다. 오늘. 보수적으로 보면, 유사한 고부가가치 체인 Bitcoin 또는 Z-cash [20] 저가치와 공존 "테마체인"(이런 마케팅, 너무 재밌음) 및 테스트넷 수수료가 0이거나 거의 0에 가깝습니다. 완전히 암호화된 것을 볼 수 있습니다. "어두운" 컨소시엄 체인이 함께 작동하며 심지어 기능이 뛰어난 개방형 체인에 서비스 제공 Ethereum 같은 것 말이죠. 우리는 실험적인 새로운 것을 본다 주관적인 시간 청구 wasm과 같은 VM 기반 체인 더 성숙한 Ethereum와 유사한 체인에서 어려운 컴퓨팅 문제를 아웃소싱하는 수단으로 체인이 사용됩니다. 또는 더 제한된 Bitcoin과 같은 체인입니다. 체인 업그레이드를 관리하기 위해 Polkadot은 본질적으로 일종의 거버넌스 구조를 지원합니다. 기존의 안정적인 정치 시스템에 기반을 두고 있으며 Yellow Paper Council [24]과 유사한 양원제 측면을 갖고 있습니다. 다음과 같이 궁극적인 권한인 기본 스테이킹 가능한 token 보유자는 "국민투표" 통제권을 갖게 됩니다. 사용자의 의견을 반영하기 위해 개발이 필요하지만 개발자의 정당성이 필요하므로 합리적인 방향이 형성될 것으로 기대합니다. "사용자" 위원회의 두 개의 방(으로 구성됨) 결속된 validators) 및 "기술" 위원회가 구성되었습니다. 주요 클라이언트 개발자 및 생태계 플레이어. 는 token 보유자 집단은 궁극적인 정당성을 유지하고 이 구조를 확장, 재매개변수화, 교체 또는 해체하기 위해 절대다수를 형성할 것입니다. 궁극적인 필요성을 의심하지 마십시오: Twain의 말에 따르면 “거즈와 기저귀는 자주 갈아줘야 합니다. 같은 이유”. 재매개변수화는 일반적으로 더 큰 합의 메커니즘 내에서 조정하기가 쉽지 않은 반면, 대체 및 확대와 같은 보다 질적인 변화는 자동화되지 않은 "소프트 법령"(예: 블록 번호의 표준화를 통해 새로운 프로토콜을 공식적으로 지정하는 문서의 hash) 또는 핵심 합의 메커니즘이 필요합니다. 자신의 모든 측면을 설명할 수 있을 만큼 풍부한 언어 변경해야 할 수도 있습니다. 후자는 최종 목표이고, 그러나 전자가 선택될 가능성이 더 높습니다. 합리적인 개발 일정을 촉진합니다. Polkadot의 기본 신조와 규칙 우리는 모든 디자인 결정을 다음과 같이 평가합니다. 최소: Polkadot에는 가능한 한 적은 기능이 있어야 합니다. 단순함: 추가적인 복잡성이 없어야 합니다. 합리적으로 가능한 것보다 기본 프로토콜에서 ffl미들웨어로 오프로드되고, 를 통해 배치 파라체인 또는 이후 최적화에서 도입되었습니다. 일반: 불필요한 요구 사항, 제약 없음 또는 파라체인에 제한을 가해야 합니다. Polkadot는 다음을 통해 최적화될 수 있는 합의 시스템 개발을 위한 테스트베드가 되어야 합니다. 확장이 가능한 한 추상적으로 적합한 모델을 만듭니다. 견고함: Polkadot은 근본적으로 안정적인 베이스 레이어. 경제적 건전성 외에도 이는 분권화를 의미합니다. 높은 보상을 받는 공격을 위한 벡터.
Polkadot への参加
Polkadot の維持には 4 つの基本的な役割があります。 ネットワーク: 照合者、漁師、指名者、validator。で Polkadot の実装可能な 1 つ、後者の役割 実際には、基本的な validator と可用性の保証という 2 つの役割に分類できます。これについてはセクションで説明します 6.5.3. コレーター 漁師 バリデーター (このグループ) バリデーター (他のグループ) 承認する になる モニター レポート 悪い に対する行動 ブロックを提供します 候補者 のために 推薦者 図 1. 間の相互作用 Polkadot の 4 つの役割。 4.1.バリデーター。 validator は最高料金であり、 Polkadot ネットワーク上の新しいブロックを封印するのに役立ちます。 validator の役割は、十分に高い結合力に依存します ただし、他の保税当事者に預けられることは許可されています。 彼らのために行動する 1 人以上の validator を指名し、 validator の債券のそのような一部は、必ずしも validator 自体が所有しているわけではなく、これらの者が所有している可能性があります。 推薦者。 validator は、高可用性と帯域幅を備えたリレー チェーン クライアント実装を実行する必要があります。各ブロックで ノードは批准の役割を受け入れる準備ができていなければなりません 指定されたパラチェーン上の新しいブロック。 このプロセス 候補者の受信、検証、再公開が含まれます ブロック。指名は決定的ですが、事前に予測することは事実上不可能です。 validator はできないため、 完全な同期を維持することが合理的に期待される すべてのパラチェーンのデータベースを作成するには、validator が提案された新しいパラチェーンを考案するタスクを指名することが期待されます。 コレーターとして知られるサードパーティへのパラチェーン ブロック。 すべての新しいパラチェーン ブロックが、指定された validator サブグループ、validator によって適切に承認されると、 その後、リレーチェーンブロック自体を承認する必要があります。これには、 トランザクションキューの状態を更新する(本質的には パラチェーンの出力キューから別の出力キューにデータを移動する パラチェーンの入力キュー)、トランザクションを処理します。 承認されたリレーチェーントランザクションセットと承認 最終ブロック(最後のパラチェーン変更を含む)。POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 5 validator は合意を見つける義務を果たしていない 私たちが選択したコンセンサスアルゴリズムのルールの下では罰せられます。初期の意図しない障害の場合、これは次のとおりです。 validator の報酬を保留します。失敗が繰り返されると、セキュリティ保証金が (焼き付けによって) 減少します。二重署名や 共謀して無効なブロックを提供すると、 債券全体(部分的には燃えていますが、ほとんどが残っています) 情報提供者と誠実な関係者に)。 ある意味、validator はマイニング プールに似ています。 現在の PoW blockchain 件。 4.2.推薦者。指名者は利害関係者です validator の保証金に貢献した人。彼らは リスク資本を投入する以外に追加の役割はありません。 特定の validator (または のメンテナンスにおいて責任を持って行動すること。 ネットワーク。 比例配分された増額または減額が受けられます 債券の成長に応じて預金に入金されます。 彼らは貢献します。 照合者と合わせて、次に、推薦者もいくつかいます。 現在のPoWネットワークのマイナーと同じ感覚です。 4.3.照合者。取引照合者(略して照合者) validator が有効なものを作成するのを支援する当事者です。 パラチェーンブロック。彼らは特定のパラチェーンの「フルノード」を維持します。つまり、必要なものはすべて保持されます 新しいブロックを作成して実行できるようにするための情報 現在の PoW blockchain に対してマイナーが行うのとほぼ同じ方法でトランザクションを実行できます。通常の状況では、彼らは、 トランザクションを照合して実行し、封印されていないものを作成します をブロックし、ゼロ知識とともに提供する 現在責任を負っている 1 人以上の validator に証拠を提出します。 パラチェーンブロックを提案しています。 照合者、推薦者、validator 間の関係の正確な性質は変わる可能性があります。 時間。当初は、照合者が非常に緊密に連携することが期待されます validators は数が少ないため (おそらく 1 つだけ)トランザクション量が少ないパラチェーン。の 初期のクライアント実装には、 パラチェーン コレーター ノードは、(リレーチェーン) validator ノードに有効なパラチェーンを無条件に提供します ブロック。 同期バージョンを維持するコストとして このようなパラチェーンがすべて増加すると、さらに多くのパラチェーンが発生すると予想されます。 インフラを整備することで、 独立した経済的動機を持つ当事者に対する義務。 最終的には、 最も多くの取引手数料を徴収します。このような照合者は、報酬収益の継続的な分配のために、一定期間にわたって特定の validator を提供する契約を結ぶ可能性があります。 あるいは、「フリーランス」の照合者が単純に すぐに支払われる報酬の競争力のあるシェアと引き換えに、有効なパラチェーンブロックを提供する市場。同様に、分散型の推薦者プールでは、複数の推薦者プールが許可されます。 結束した参加者が調整し、責任を共有する validator。このプール機能により、オープンな参加が保証されます より分散化されたシステムにつながります。 4.4.漁師さんたち。他の2つのアクティブなパーティーとは異なり、 漁師はブロックオーサリングに直接関係していない プロセス。むしろ彼らは独立した「賞金稼ぎ」です。 高額な 1 回限りの報酬が動機です。 まさに、 漁師の存在を考えると、不正行為が起こることはめったになく、不正行為が起こるのは次のような場合のみであると予想されます。 結合した当事者が秘密鍵のセキュリティに不注意である、 悪意によるものではなく。名前が来る 予想される報酬の頻度、参加するための最小要件、および最終的な報酬のサイズから構成されます。 漁師は、タイムリーに次のことを証明することで報酬を得ることができます。 少なくとも一方の保税当事者が違法行為を行った。違法行為 それぞれ同じ承認された親を持つ 2 つのブロックに署名すること、またはパラチェーンの場合は無効なブロックの承認を支援することが含まれます。 ブロック。過剰な報酬や妥協を防ぐため、 セッションの秘密鍵の不正使用、基本報酬 単一の validator の違法に署名されたメッセージを提供することは、 最小限。この報酬は、増加するにつれて漸近的に増加します 他のvalidatorからの違法な署名を裏付けるものは、 本物の攻撃を暗示するもの。漸近線が設定されています 少なくとも次の基本的なセキュリティ主張に従って 66% validator の 3 分の 2 は慈善的に行動します。 フィッシャーマンは、以下の「フルノード」に似ています。 リソースが必要とする現在の blockchain システム 比較的小規模であり、安定した稼働時間を約束します 帯域幅も必要ありません。漁師の違いはこうだ 少額の保証金を支払わなければならないのと同じくらい。この絆は、 validator秒の時間と計算を無駄にするシビル攻撃 リソース。すぐに撤回可能ですが、おそらくそうではありません 数ドル相当以上の金額がかかる可能性があります 不正行為を発見することで多額の報酬を得る validator。
Polkadot에 참여
Polkadot 유지에는 네 가지 기본 역할이 있습니다. 네트워크: 대조자, 어부, 지명자 및 validator. 에서 Polkadot의 가능한 구현 중 하나, 후자의 역할 실제로 기본 validator 및 가용성 보증인이라는 두 가지 역할로 분류될 수 있습니다. 이에 대해서는 섹션에서 논의됩니다. 6.5.3. 대조자 어부 검증인 (이 그룹) 검증인 (다른 그룹) 승인하다 된다 모니터 보고서 나쁜 행동 블록을 제공합니다 후보자 에 대한 지명자 그림 1. Polkadot의 네 가지 역할. 4.1. 검증인. validator은 가장 높은 요금이며 Polkadot 네트워크에서 새로운 블록을 봉인하는 데 도움이 됩니다. validator의 역할은 충분히 높은 유대 관계에 달려 있습니다. 하지만 다른 보세 당사자는 이를 허용합니다. 그들을 대신하여 행동할 한 명 이상의 validator을 지명합니다. validator 채권의 일부는 반드시 validator 자체가 소유할 필요는 없고 오히려 이들 소유일 수 있습니다. 지명자. validator은 고가용성과 대역폭을 갖춘 릴레이 체인 클라이언트 구현을 실행해야 합니다. 각 블록에서 노드는 비준 역할을 수락할 준비가 되어 있어야 합니다. 지명된 파라체인의 새로운 블록. 이 과정 후보자 수신, 검증 및 재출판이 포함됩니다. 블록. 지명은 결정적이지만 사전에 사실상 예측할 수 없습니다. validator은(는) 할 수 없기 때문에 합리적으로 완전히 동기화된 상태를 유지할 것으로 예상됩니다. 모든 파라체인의 데이터베이스를 기반으로 validator이 새로운 제안을 고안하는 작업을 지명할 것으로 예상됩니다. parachain 블록을 collator라고 알려진 제3자에게 전달합니다. 모든 새로운 파라체인 블록이 지정된 validator 하위 그룹에 의해 적절하게 비준되면 validators 그런 다음 릴레이 체인 블록 자체를 비준해야 합니다. 여기에는 다음이 포함됩니다. 트랜잭션 대기열의 상태 업데이트(기본적으로 파라체인의 출력 대기열에서 다른 출력 대기열로 데이터 이동 파라체인의 입력 큐), 트랜잭션 처리 승인된 릴레이 체인 트랜잭션 세트를 승인하고 최종 파라체인 변경을 포함한 최종 블록.POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 5 validator 합의점을 찾는 의무를 이행하지 않음 우리가 선택한 합의 알고리즘의 규칙에 따라 처벌됩니다. 초기에 의도하지 않은 오류가 발생하는 경우 이를 통해 validator의 보상을 보류합니다. 반복적인 실패로 인해 담보 채권이 감소합니다(소각을 통해). 이중 서명 또는 유효하지 않은 블록을 제공하려고 공모하면 다음과 같은 손실이 발생합니다. 전체 채권(부분적으로 소각되었으나 대부분이 제공됨) 제보자와 정직한 행위자에게). 어떤 의미에서 validator은 채굴 풀과 유사합니다. 현재 PoW blockchains. 4.2. 지명자. 지명자는 지분을 보유한 당사자입니다. validator의 담보 채권에 기여하는 사람입니다. 그들은 위험 자본을 배치하는 것 외에는 추가 역할이 없습니다. 특정 validator(또는 그에 따라 설정됨) 유지 관리에 책임감 있게 행동합니다. 네트워크. 비례적으로 증가하거나 감소합니다. 채권의 성장에 따라 예금에 그들은 기여합니다. collator와 함께 다음으로 nominator가 일부에 있습니다. 현재 PoW 네트워크의 채굴자와 유사한 의미입니다. 4.3. 대조자. 트랜잭션 대조자(줄여서 대조자) validators가 유효한 문서를 작성하는 데 도움을 주는 당사자입니다. 파라체인 블록. 그들은 특정 파라체인에 대해 "풀 노드"를 유지합니다. 필요한 모든 것을 유지한다는 의미입니다. 새로운 블록을 작성하고 실행할 수 있는 정보 현재 PoW blockchains에서 채굴자가 수행하는 것과 거의 동일한 방식으로 거래합니다. 정상적인 상황에서 그들은 봉인되지 않은 거래를 생성하기 위해 거래를 대조하고 실행합니다. 영지식과 함께 차단하고 제공합니다. 현재 책임이 있는 한 명 이상의 validator에 대한 증거 파라체인 블록을 제안합니다. 대조자, 지명자 및 validator 사이의 관계의 정확한 성격은 바뀔 가능성이 높습니다. 시간. 처음에는 대조자가 매우 긴밀하게 작업할 것으로 기대합니다. validators를 사용하면 몇 개만 있을 것이기 때문에(아마도 단 하나)의 거래량이 적은 파라체인. 는 초기 클라이언트 구현에는 RPC가 포함됩니다. 검증 가능한 유효한 파라체인이 있는 (릴레이체인) validator 노드를 무조건 공급하는 파라체인 대조자 노드 블록. 동기화된 버전을 유지하는 데 드는 비용 이러한 모든 파라체인이 증가하면 추가로 분리하는 데 도움이 되는 인프라가 마련되어 있습니다. 독립적이고 경제적 동기를 지닌 당사자에 대한 의무. 결국 우리는 경쟁하는 대조자 풀을 보게 될 것으로 예상합니다. 가장 많은 거래 수수료를 징수합니다. 이러한 대조자는 보상 수익금의 지속적인 공유를 위해 일정 기간 동안 특정 validator을 서비스하도록 계약을 맺을 수 있습니다. 또는 "프리랜스" 대조자가 간단히 즉시 지불할 수 있는 보상의 경쟁력 있는 공유에 대한 대가로 유효한 파라체인 블록을 제공하는 시장입니다. 마찬가지로, 분산형 지명자 풀은 여러 가지를 허용합니다. 결속된 참가자는 의무를 조정하고 공유합니다. validator. 이러한 풀링 기능은 공개 참여를 보장합니다. 보다 분산된 시스템으로 이어집니다. 4.4. 어민. 다른 두 활성 파티와는 달리, 어부는 블록 저작과 직접적인 관련이 없습니다. 프로세스. 오히려 그들은 독립적인 "현상금 사냥꾼"입니다. 큰 일회성 보상에 의해 동기가 부여됩니다. 바로 그 이유는 어부의 존재로 인해 우리는 잘못된 행동이 거의 발생하지 않을 것이라고 예상합니다. 보세 당사자가 비밀 키 보안에 부주의하고, 악의적인 의도보다는. 이름이 온다 예상되는 보상 빈도, 참여에 필요한 최소 요구 사항 및 최종 보상 크기를 고려합니다. 어부들은 적시에 다음과 같은 증거를 통해 보상을 받습니다. 적어도 한 명의 보세 당사자가 불법적으로 행동했습니다. 불법 행위 동일한 비준된 상위 블록으로 각각 두 개의 블록에 서명하거나 파라체인의 경우 유효하지 않은 블록을 비준하는 데 도움이 됩니다. 블록. 과도한 보상이나 타협을 방지하기 위해 세션 비밀 키의 불법 사용, 기본 보상 단일 validator의 불법적으로 서명된 메시지를 제공하는 것은 최소한. 이 보상은 더 많아질수록 점근적으로 증가합니다. 다른 validator의 불법 서명을 확증하는 것은 실제 공격을 암시하는 것으로 제공됩니다. 점근선이 설정되었습니다. 최소한 우리의 기본 보안 주장에 따르면 66%입니다. validator의 2/3는 자비롭게 행동합니다. 어부들은 "풀 노드"와 다소 유사합니다. 자원이 필요한 현재의 blockchain 시스템 상대적으로 작고 안정적인 가동 시간을 약속합니다. 대역폭은 필요하지 않습니다. 어부들은 다르다 소액의 보증금을 내야 하는 만큼.이 채권은 방지 validators의 시간과 컴퓨팅 낭비로 인한 시빌 공격 자원. 즉시 철회가 가능합니다. 아마도 그렇지 않을 것입니다. 몇 달러에 해당하는 금액보다 더 많은 금액이 소요될 수 있습니다. 잘못된 행동을 발견하여 막대한 보상을 받는 것 validator.
設計の概要
このセクションは、概要を簡単に説明することを目的としています。 システム全体として。をさらに徹底的に調査すると、 システムについては、それに続くセクションで説明します。 5.1.コンセンサス。リレーチェーン上で、Polkadot は次のことを達成します。 相互に合意された有効なセットに関する低レベルの合意 最新の非同期ビザンチン フォールトトレラント (BFT) アルゴリズムを通じてブロックします。アルゴリズムがインスピレーションを受けます シンプルな Tendermint [11] とそれ以上の機能による HoneyBadgerBFT [14] が関与しています。後者は、 恣意的なものに対する効率的でフォールトトレラントな合意 ネットワーク インフラストラクチャに欠陥があり、ほとんど無害な一連の権限または validator が指定されています。 Proof-of-Authority (PoA) スタイルのネットワークの場合、これだけで で十分ですが、Polkadot は次のようになると考えられます。 完全にオープンでパブリックなネットワークとして展開することも可能 特定の組織や信頼できる組織がない状況 それを維持するために必要な権限。 したがって、 validator のセットを決定し、奨励する手段 正直に言うと彼らは。このために、PoS ベースの選択を利用します 基準。 5.2.賭け金を証明する。ネットワークが どれくらいの「賭け金」を計測する何らかの手段を持つだろう 特定のアカウントにはあります。 比較しやすいように、 既存のシステムでは、測定単位と呼びます。 「tokens」。残念ながら、この用語は理想的なものではありません。 理由はたくさんありますが、特に単にスカラーであるということは重要です アカウントに関連付けられた値、という概念はありません。 個性。 私たちは、validator 人が選出されるのはまれであると想像しています (せいぜい 1 日に 1 回ですが、おそらく四半期に 1 回ほどの頻度で行われます)、 指名プルーフ・オブ・ステーク (NPoS) スキームを通じて。インセンティブは、比例配分によって発生します。POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 6 リレー チェーン バリデーターの群れ (それぞれの色で色分けされています) 指定されたパラチェーン) トランザクション (提出者 外部俳優) パラチェーン 橋 仮想パラチェーン (例: Ethereum) パラチェーン パラチェーン キューと I/O 伝播されたトランザクション 候補者の提出をブロックする 2次注文 リレーチェーン パラチェーンコミュニティ アカウント インバウンドトランザクション アウトバウンドトランザクション インターチェーントランザクション (validators が管理) コレーター 伝播されたブロック 漁師 図 2. Polkadot システムの概要図。これは、照合者がユーザー トランザクションを収集して伝播すること、およびブロック候補を漁師と validator に伝播することを示しています。それも アカウントがリレーチェーンを介してパラチェーンから実行されるトランザクションを投稿する方法を示します そして、別のパラチェーンに移行し、そこのアカウントへのトランザクションとして解釈できます。 token のベース拡張からの資金 (最大 100%) 年間、ただし可能性としては約 10%) 徴収される取引手数料。マネタリーベースの拡大は通常インフレにつながりますが、token の所有者全員が 参加する際には公平な機会が与えられ、token所有者は、その価値の減少に苦しむ必要はありません。 彼らが喜んで取得した場合に限り、長期にわたる保有量 コンセンサスメカニズムにおける役割。特定の割合 token 個が staking プロセスの対象となります。の 実質的なtokenベースの拡張は、次のように調整されます。 この目標を達成するための市場ベースのメカニズム。 バリデーターは、その利害関係によって強い絆で結ばれています。終了します validator の保証は、validator の職務が終了した後も長期間 (おそらく約 3 か月) 維持されます。こんなに長い 債券清算期間により、将来の不正行為が可能になる チェーンの定期的なチェックポイントまで罰せられます。 不正行為があった場合には減給などの懲罰が科せられます。 報酬を与える場合、または意図的に侵害する場合 ネットワークの整合性が失われ、validator はその一部またはすべてを失います。 他のvalidator、情報提供者、または利害関係者への利害関係 全体として(燃焼を通じて)。たとえば、validator フォークの両方のブランチを承認しようとする人 (場合によっては 「短距離」攻撃として知られる)が特定される可能性があり、 後者の方法で処罰されます。 長距離の「何も関係のない」攻撃4は、単純な「チェックポイント」ラッチによって回避され、複数の危険なチェーンの再編成を防ぎます。 特定のチェーンの深さ。 新しく同期するクライアントを確実にするには 間違ったチェーンにだまされることはありません。 「ハードフォーク」は(せいぜい同時期に)発生するだろう。 validators の債券清算)、最近のチェックポイント ブロック hashes をクライアントにハードコーディングします。これは、「有限チェーン長」または「有限チェーン長」というさらなるフットプリント削減策とうまく機能します。 ジェネシスブロックの定期的なリセット。 5.3.パラチェーンとコレーター。各パラチェーンが取得するのは、 リレーチェーンに対する同様のセキュリティ アフォーダンス: の パラチェーンのヘッダーはリレーチェーンブロック内に密封されています 確認後は、組織再編や「二重支出」が不可能であることを保証します。これは、Bitcoin のサイドチェーンとマージマイニングによって提供されるものと同様のセキュリティ保証です。ただし、Polkadot は、パラチェーンの状態遷移が有効であるという強力な保証も提供します。これ validator のセットが暗号的にランダムにサブセットに分割されることによって発生します。 1 つあたり 1 つのサブセット パラチェーンでは、サブセットはブロックごとに異なる可能性があります。これ セットアップは通常、パラチェーンのブロック時間が 少なくともリレーチェーンの長さと同じ長さにしてください。具体的な 分割を決定する手段は範囲外です 4 このような攻撃では、敵はジェネシス ブロック以降、全く新しい歴史の連鎖を作り上げます。をコントロールすることで、 オフセットでの賭け金の割合は比較的微々たるものですが、他のすべての賭け金と比べて徐々に自分の賭け金の割合を増やすことができます。 利害関係者は、彼らの代替歴史の唯一の積極的な参加者であるためです。創造物には本質的な物理的制限が存在しないため、 (実際の計算エネルギーを費やす必要がある PoW とは異なり) のブロックで、実際のチェーンよりも長いチェーンを作成できます。 比較的短い期間であり、ネットワークの正規の状態を引き継ぎ、最長かつ最良となる可能性があります。POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 7 この文書の内容は次のいずれかに基づいている可能性がありますが、 RanDAO [19] に似た commit-reveal フレームワーク、または 各パラチェーンの前のブロックから結合されたデータを使用する 暗号的に安全な hash の下で。 validator のこのようなサブセットは、 有効性が保証されているパラチェーンブロック候補( 債券没収の痛み)。有効性は 2 を中心に展開します 重要な点。第一に、それは本質的に有効であるということ、 すべての状態遷移が忠実に実行され、すべてが 参照される外部データ (トランザクションなど) は含めることができます。第二に、外部データはすべて、 外部トランザクションなどの候補は十分に高い可用性を備えているため、参加者は次のことを行うことができます。 それをダウンロードし、ブロックを手動で実行します。5 バリデーターは、外部の「トランザクション」データを含まない「null」ブロックのみを提供する場合がありますが、提供すると報酬が減額されるリスクが生じる可能性があります。彼らは一緒に働きます 照合者 (個人) とのパラチェーン ゴシップ プロトコル トランザクションをブロックに照合し、そのブロックが親の有効な子を構成することを示す非対話型のゼロ知識証明を提供します (トランザクションを取得する) 彼らのトラブルに対する料金)。 独自の指定はパラチェーン プロトコルに委ねられます。 スパム防止手段: 「コンピューティング リソースの測定」または「トランザクション料金」という基本的な概念はありません。 リレーチェーンによって課せられます。また、リレーチェーンプロトコルによってこれを直接強制することはありません(ただし、 利害関係者が採用を選択する可能性は低い まともなメカニズムを提供していないパラチェーン)。 これは、これまでとは異なるチェーンの可能性に対する明確なうなずきです。 Ethereum、例: Bitcoin のようなチェーンは、はるかに単純な料金モデル、またはその他のまだ提案されていないスパム防止モデルを備えています。 Polkadot のリレー チェーン自体はおそらく Ethereum のようなアカウントと状態チェーン (おそらく EVM__ 派生)。リレーチェーンノードは次のことを行う必要があるため、 他の重要な処理、トランザクション スループットを実行する 多額の取引手数料により部分的に最小限に抑えられる また、研究モデルでブロック サイズの制限が必要な場合もあります。 5.4.チェーン間通信。 Polkadot の重要な最終要素はチェーン間通信です。以来 パラチェーン間には何らかの情報チャネルが存在する可能性があるため、Polkadot をパラチェーンとみなすことができます。 スケーラブルなマルチチェーン。 Polkadot の場合、通信は可能な限り単純です。トランザクションは、 パラチェーンは(そのチェーンのロジックに従って)次のことができます。 トランザクションを 2 番目のパラチェーンにディスパッチします。 またはリレーチェーンの可能性もあります。外部トランザクションと同様 本番環境 blockchain では完全に非同期です そして、それらには何かを返す本質的な能力はありません。 情報の原点に戻ること。 宛先: 取得 以前のデータ ブロックのvalidator。 アカウントが投稿を受信します: エントリが削除されました イングレス Merkle tree アカウントが投稿を送信します: に置かれたエントリ 出口 Merkle tree 目的地に向けて パラチェーン 出口 出典:株式 次のブロックのデータ validators に保存されている投稿証明 パラチェーン出口マークル 木 配線された参照が配置されました 宛先パラチェーン内 イングレス Merkle tree 進入 図 3. を示す基本的な回路図 投稿のルーティングの主要部分 トランザクション (「投稿」)。 実装の複雑さを最小限に抑えるために、最小限の リスク そして 最小限の ストレートジャケット の 未来 パラチェーン アーキテクチャでは、これらのインターチェーン トランザクションは 標準の外部署名トランザクションと実質的に区別できません。 トランザクションにはオリジンセグメントがあり、パラチェーンを識別する機能を提供します。 任意のサイズのアドレス。 Bitcoin や Ethereum などの一般的な現在のシステムとは異なり、チェーン間トランザクションにはいかなる種類の手数料の「支払い」も伴いません。このような支払いは、ソースおよび宛先のパラチェーン上のネゴシエーション ロジックを通じて管理する必要があります。のために提案されているようなシステム Ethereum の Serenity リリース [7] は簡単な手段です ただし、そのようなクロスチェーンリソースの支払いを管理することは困難です やがて他の人たちが前面に出てくるかもしれないと私たちは考えています。 チェーン間トランザクションはシンプルな方法で解決されます。 Merkle tree に基づいたキューイング メカニズムにより、 忠実さ。リレーチェーンのメンテナの仕事は次のとおりです。 1 つのパラチェーンの出力キューでトランザクションを移動する 宛先パラチェーンの入力キューに追加されます。の 渡されたトランザクションはリレーチェーン上で参照されますが、相対ではありませんay-chain トランザクション自体。パラチェーンが別のパラチェーンにスパム送信するのを防ぐには トランザクション、トランザクションを送信するには、これが必要です 宛先の入力キューが大きすぎないこと 前のブロックの終了時刻。入力の場合 ブロック処理後のキューが大きすぎる場合、キューは「飽和」とみなされ、トランザクションはルーティングされません。 それは後続のブロック内で、以下に戻されるまで続きます。 限界。これらのキューはリレーチェーン上で管理されます パラチェーンが互いの飽和度を決定できるようにする ステータス。この方法では、トランザクションを投稿しようとして失敗しました 停止した宛先へのメッセージは同期的に報告される場合があります。 (ただし、リターンパスが存在しないため、その理由でセカンダリトランザクションが失敗した場合、それを報告することはできません) 元の呼び出し元とその他の回復手段に送信します。 開催しなければならないだろう。) 5.5. Polkadot と Ethereum。 Ethereum のチューリング完全性により、Polkadot と Ethereum が相互運用できる可能性が十分にあると予想されます。 少なくとも、容易に推測できるセキュリティの範囲内では、相互に影響を及ぼします。つまり、私たちは次のようなトランザクションを想定しています。 Polkadot は validators によって署名され、 5このようなタスクは、validator 間で共有される場合もあれば、強く結合された validator のセットの指定タスクになる場合もあります。 可用性の保証人。
POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 8 Ethereum によって解釈および実行できます。 トランザクション転送契約。反対方向では、 特別にフォーマットされたログ (イベント) の使用が予想されます。 これは、特定のメッセージを転送する必要があるかどうかを迅速に検証できるようにするための「ブレークアウト コントラクト」に由来しています。 5.5.1. Polkadot から Ethereum まで。の選択を通じて、 BFT コンセンサス メカニズムと validator から形成された 承認投票を通じて決定された一連の利害関係者 このメカニズムにより、安全な合意を得ることができます。 変更頻度は低く、validator の数は控えめです。 合計 144 validator のシステムでは、ブロック時間は 4 秒、900 ブロックのフィナリティ (悪意のある攻撃を許可) 二重投票などの行為は通報され処罰される および修復される)、ブロックの有効性は合理的に判断できます。 わずか 97 件の署名 (144 件の 3 分の 2 に 1 件を加えたもの) と、異議申し立てが提出されないその後の 60 分間の検証期間を通じて証明されたとみなされます。 Ethereum は「不法侵入契約」をホストできます。 144 の署名者を維持し、次の者によって制御されることができます。 彼ら。 EVM では、楕円曲線デジタル署名 (ECDSA) の回復に必要なガスは 3,000 ガスのみであるため、 おそらく検証は、 validator の超過半数 (完全な全会一致ではなく)、 Ethereum の基本コスト、命令が実行されたことを確認 Polkadot ネットワークからのガスは 300,000 ガス以下であることが適切に検証されており、その割合はわずか 6% です。 総ブロックガス制限は5.5Mです。 validator の数を増やす (問題に対処するために必要なため) 数十のチェーン) は必然的にこのコストを増加させますが、 技術が成熟するにつれて、Ethereum のトランザクション帯域幅は時間の経過とともに増加すると広く予想されています。 インフラが改善されます。そうではないという事実とともに、 すべての validator が関与する必要があります (例: 最高の validator のみ) ステークされた validator は、そのようなタスクのために呼び出される可能性があります) このメカニズムの限界はかなり拡張されます。 このような validator が毎日ローテーションすると仮定します (これは かなり保守的であり、毎週または毎月でも許容される場合があります)、その後、ネットワークの維持コストがかかります。 このEthereum-転送ブリッジは約540,000になります 1 日あたりのガソリン、または現在のガス価格では年間 45 ドルです。基本的なトランザクションを単独でブリッジ経由で転送するとコストがかかります 約0.11ドル。追加の契約計算には費用がかかります もちろんもっとです。トランザクションのバッファリングとバンドルによる 合わせて、侵入許可コストは簡単に計算できます。 共有され、トランザクションごとのコストが大幅に削減されます。 転送する前に 20 個のトランザクションが必要な場合、 基本的なトランザクションの転送コストは次のようになります。 約0.01ドル。 この複数署名契約モデルに代わる、興味深い、より安価な代替手段の 1 つは、多国間所有権のセマンティクスを実現するためにしきい値署名を使用することです。 ECDSA のしきい値署名スキーム 他のスキームの場合は計算コストが高くなります Schnorr 署名などは非常に合理的です。 Ethereum そのようなものを作るプリミティブを導入する予定です 今後の Metropolis ハードフォークで安価に使用できるスキーム。このような手段が利用できれば、ガス代は Polkadot トランザクションを Ethereum に転送するため ネットワークは大幅にゼロ近くまで削減されるでしょう 検証のための基本コストを超えるオーバーヘッド 署名し、基礎となるトランザクションを実行します。 このモデルでは、Polkadot の validator ノードは次のようになります。 メッセージに署名する以外に何もすることはありません。トランザクションを実際に Ethereum ネットワークにルーティングするには、次のようにします。 どちらかの validator 自体も存在すると仮定します。 Ethereum ネットワーク、またはおそらくその少額の報奨金 メッセージを転送した最初のアクターにオファーされます ネットワークに送信します(報奨金は簡単に支払われる可能性があります) トランザクションの発信者)。 5.5.2. Ethereum から Polkadot まで。トランザクションを取得する Ethereum から Polkadot への転送では、ログという単純な概念が使用されます。 Ethereum コントラクトが Polkadot の特定のパラチェーンにトランザクションをディスパッチしたい場合、 特別な「ブレイクアウト契約」を結ぶだけで済みます。 ブレイクアウト契約では、以下のような支払いが発生します。 マークル証明と対応するブロックのヘッダーが有効であるというアサーションによってその存在が証明されるように、ロギング命令を発行します。 正規の。 後の 2 つの条件のうち、おそらく有効性が最も重要です。 証明するのが最も簡単です。原則として、唯一の要件は、証明が必要な各 Polkadot ノードに対して (つまり、指定された validator ノード) は、標準の Ethereum ノードの完全に同期されたインスタンスを実行します。残念ながら、これ自体はかなり重い依存関係です。さらに 軽量な方法は、次のような単純な証明を使用することです。 ヘッダーは、 適切に実行するために必要な Ethereum の状態トライの一部 ブロック内のトランザクションを確認し、ログ (ブロック レシートに含まれる) が有効であることを確認します。そんな「SPVらしさ」6 証明にはまだかなりの量の情報が必要になる場合があります。都合の良いことに、通常は必要ありません。 all: Polkadot 内の結合システムにより結合が可能になります。 サードパーティは、ヘッダーを失う危険を冒してヘッダーを送信する必要があります。 債券は、他の第三者 (「漁師」など、6.2.3 を参照) がヘッダーが無効であるという証拠を提供した場合に限ります。 (具体的には、状態ルートまたは領収書のルートが偽者であったこと)。 Ethereum のようなファイナライズされていない PoW ネットワークでは、 正規性を決定的に証明することは不可能です。 これに対処するために、あらゆる種類のものに依存しようとするアプリケーションは、 チェーン依存の因果関係は、多数の「確認」を待つか、依存するトランザクションが一定のレベルに達するまで待ちます。 チェーン内の特定の深さ。 Ethereum に、これは 深さは、既知のネットワーク問題がない最も価値の低いトランザクションの 1 ブロックから、従来の 1200 ブロックまで変化します。 交換用の最初のフロンティアリリース時のケース。 安定した「Homestead」ネットワークでは、この数字は次の位置にあります。 ほとんどの取引所では 120 ブロックかかりますが、おそらくかかるでしょう。 同様のパラメータ。 それで 私たち できる 想像してください 私たちの Polkadot側 Ethereumインターフェイスにはいくつかの簡単な機能があります: Ethereum ネットワークから新しいヘッダーを受け入れ、PoW を検証して、何らかの証拠を受け入れることができるようにします。 特定のログは、十分な深さのヘッダー (および前方) の Ethereum 側のブレークアウト コントラクトによって発行されました。 Polkadot 内の対応するメッセージ)、そして最後に 以前に受け入れられた証拠を受け入れることができるようになりますが、 まだ制定されていないヘッダーには無効なレシート ルートが含まれています。 実際に Ethereum ヘッダー データ自体を取得するには (そして SPV の証明または有効性/正規性の反駁) Polkadot ネットワーク、転送の奨励 6SPV は、Bitcoin の簡易支払検証を指し、クライアントがトランザクションのみを保持しながら検証する方法を説明します。 最長の PoW チェーンのすべてのブロック ヘッダーのコピー。POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 9 データが必要です。 これは支払いと同じくらい簡単です (Ethereum 側で徴収された料金から賄われます) 支払われました ヘッダーが次のような有用なブロックを転送できる人 有効です。検証者は、次の目的で最後の数千ブロックに関する情報を保持することが求められます。 何らかのプロトコル固有の手段または上で維持されるコントラクトを通じて、フォークを管理できる。 リレーチェーン。 5.6. Polkadot そして Bitcoin。 Bitcoin 相互運用 Polkadot には興味深い課題が提示されています。 「双方向ペグ」は便利なインフラになる 両方のネットワーク側に置く必要があります。ただし、理由により、 Bitcoin の制限により、そのようなペグを安全に提供するには、 簡単ではない仕事。からのトランザクションの配信 Bitcoin から Polkadot までは、原則として Ethereum と同様のプロセスで実行できます。 「ブレークアウトアドレス」 Polkadot validator によって何らかの方法で制御される可能性があります 転送された token (およびそれらと一緒に送信されたデータ) を受信します。 SPV 証明は、インセンティブ付きの oracle によって提供できます。 確認期間とともに、報奨金が与えられます。 トランザクションを暗示する非正規ブロックを特定する 「二重支出」されている。 token はすべて 「ブレークアウト アドレス」は、原則として、後の分散のために同じ validator によって制御されます。 しかし、問題は、回転する validator セットから堆積物をどのように安全に制御できるかということです。 とは異なります Ethereum に基づいて任意の決定を下すことができます 署名の組み合わせにより、Bitcoin は実質的に さらに制限があり、ほとんどのクライアントは最大 3 者とのマルチシグネチャ トランザクションのみを受け入れます。これを 36、実際には最終的に望まれる数千まで拡張することは、現在のプロトコルでは不可能です。 1 つのオプションは、Bitcoin プロトコルを変更して有効にすることです。 このような機能は、いわゆる「ハードフォーク」と呼ばれるものですが、 Bitcoin 最近の試みから判断すると、世界を調整するのは困難です。可能性の 1 つは、しきい値署名の使用です。 単一識別可能な公衆を許可する暗号化スキーム 鍵は複数の秘密「部分」によって効果的に制御されます。 有効な署名を作成するには、その一部またはすべてを利用する必要があります。 残念ながら、しきい値署名と互換性があります Bitcoin の ECDSA は計算コストが高くつきます 多項式の複雑さを作成します。その他のスキームとしては、 Schnorr 署名はコストがはるかに低くなりますが、 Bitcoin に導入される可能性のあるタイムライン プロトコルは不明です。 預金の最終的な安全性は次のとおりです。 多数の validator を結合する、もう 1 つのオプションは、 マルチサインキーホルダーを大幅に削減 合計 validator の結合されたサブセット (しきい値など) 署名が実行可能になります (または、最悪の場合、Bitcoin のネイティブ マルチ署名も可能です)。 これにより、当然のことながら、 validator が違法行為を行った場合に賠償金として差し引かれる可能性がある保証金の総額ですが、これは はグレースフル デグラデーションであり、単に上限を設定するだけです 間で安全に運用できる資金の量。 2 つのネットワーク (実際、攻撃による損失の割合) validator からは成功します)。 そのため、合理的に安全な Bitcoin 相互運用性の「仮想パラチェーン」を配置することは非現実的ではないと考えています。 2 つのネットワーク間での作業はかなりの努力が必要ですが、スケジュールは不確実であり、可能性は十分にあります。 その中で利害関係者の協力を必要とする ネットワーク。
디자인 개요
이 섹션에서는 다음과 같은 간략한 개요를 제공합니다. 시스템 전체. 좀 더 철저한 탐구를 통해 시스템은 다음 섹션에 나와 있습니다. 5.1. 의견 일치. 릴레이 체인에서 Polkadot은(는) 달성합니다. 상호 합의된 유효한 집합에 대한 낮은 수준의 합의 최신 비동기식 비잔틴 내결함성(BFT) 알고리즘을 통해 차단합니다. 알고리즘은 영감을 받을 것입니다 간단한 Tendermint [11] 및 훨씬 더 많은 기능을 통해 관련 HoneyBadgerBFT [14]. 후자는 임의적인 것에 대한 효율적이고 내결함성 합의 대부분 온화한 권한 또는 validator 집합을 고려하면 결함이 있는 네트워크 인프라입니다. PoA(권한 증명) 스타일 네트워크의 경우 이것만으로도 충분할 것입니다. 그러나 Polkadot은(는) 그럴 것으로 예상됩니다. 완전 개방형 및 공개 환경에서 네트워크로 배포 가능 특정 조직이 없거나 신뢰할 수 없는 상황 유지하기 위해 필요한 권한입니다. 따라서 우리는 validator 세트를 결정하고 인센티브를 제공하는 수단 솔직히 말해서. 이를 위해 우리는 PoS 기반 선택을 활용합니다. 기준. 5.2. 지분을 증명합니다. 우리는 네트워크가 "지분"이 얼마나 되는지 측정할 수 있는 수단이 있을 것입니다. 특정 계정이 있습니다. 비교의 편의를 위해 기존 시스템에서는 측정 단위를 호출합니다. “tokens”. 불행하게도 이 용어는 다음과 같은 경우에는 이상적이지 않습니다. 여러 가지 이유, 특히 단순한 스칼라라는 점 계정과 관련된 가치에 대한 개념이 없습니다. 개성. 우리는 validators가 드물게 선출되는 것을 상상합니다(최대한 하루에 한 번이지만 분기당 한 번만큼 드물게 발생함) 지명 지분 증명(NPoS) 방식을 통해. 인센티브는 비례 배분을 통해 발생할 수 있습니다.POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 6 릴레이 체인 검증인 떼 (각각의 색상으로 지정 파라체인) 거래 (제출자: 외부배우) 파라체인 다리 가상 파라체인 (예: Ethereum) 파라체인 파라체인 큐와 I/O 전파된 트랜잭션 후보 제출 차단 2차 릴레이 체인 파라체인 커뮤니티 계정 인바운드 거래 아웃바운드 거래 인터체인 거래 (validators에서 관리) 대조자 전파된 블록 어부 그림 2. Polkadot 시스템의 요약 회로도. 이는 대조자가 사용자 트랜잭션을 수집하고 전파하는 것은 물론 블록 후보를 어부와 validator에게 전파하는 것을 보여줍니다. 그것은 또한 계정이 릴레이 체인을 통해 파라체인에서 수행되는 거래를 게시할 수 있는 방법을 보여줍니다. 그리고 그곳의 계정에 대한 거래로 해석될 수 있는 또 다른 파라체인으로 이동합니다. token 기지 확장을 통한 자금 조달(최대 100%) 연간, 약 10% 정도일 가능성이 높음) 모든 거래 수수료가 징수됩니다. 통화 기반 확장은 일반적으로 인플레이션으로 이어지는 반면 모든 token 소유자는 참여 시 공정한 기회를 가지게 되며, 어떤 token보유자도 자신의 가치 감소를 겪을 필요가 없습니다. 그들이 기꺼이 받아 들인다면 시간이 지남에 따라 보유하게 될 것입니다. 합의 메커니즘에서의 역할. 특정 비율 token 중 staking 프로세스의 대상이 됩니다. 는 효과적인 token 기본 확장은 다음을 통해 조정됩니다. 이 목표를 달성하기 위한 시장 기반 메커니즘. 검증인은 자신의 지분에 의해 크게 결속되어 있습니다. 종료 validators의 채권은 validators의 의무가 종료된 후에도 오랫동안(대략 3개월 정도) 유지됩니다. 이 긴 채권 청산 기간은 향후 잘못된 행동을 허용합니다. 체인의 주기적인 체크포인트까지 처벌됩니다. 잘못된 행동은 감점 등의 처벌을 초래합니다. 보상을 제공하거나 고의로 계약을 훼손하는 경우 네트워크의 무결성, validator의 일부 또는 전부를 잃습니다. 다른 validators, 정보 제공자 또는 이해관계자에 대한 지분 전체적으로 (소각을 통해). 예를 들어 validator 포크의 양쪽 가지를 모두 비준하려고 시도하는 사람(때로는 "단거리" 공격으로 알려져 있음)이 식별될 수 있으며, 후자의 방법으로 처벌한다. 장거리 "아무것도 위험하지 않은" 공격4은 단순한 "체크포인트" 래치를 통해 우회됩니다. 이 래치는 1개 이상의 위험한 체인 재구성을 방지합니다. 특정 체인 깊이. 새로 동기화되는 클라이언트를 확인하려면 잘못된 체인에 속을 수 없습니다. "하드 포크"가 발생합니다(최대한 같은 기간). validators의 채권 청산) 최근 체크포인트 블록 hashes를 클라이언트에 하드 코딩합니다. 이는 "유한한 체인 길이" 또는 제네시스 블록을 주기적으로 재설정합니다. 5.3. 파라체인과 콜레이터. 각 파라체인은 릴레이 체인과 유사한 보안 규정: 는 파라체인의 헤더는 릴레이 체인 블록 내에 밀봉되어 있습니다. 확인 후에는 재구성이나 "이중 지출"이 발생하지 않도록 할 수 있습니다. 이는 Bitcoin의 사이드체인 및 병합 채굴이 제공하는 것과 유사한 보안 보장입니다. 그러나 Polkadot은 또한 파라체인의 상태 전환이 유효하다는 강력한 보장을 제공합니다. 이 validator 집합이 암호화 방식으로 무작위로 하위 집합으로 분할되어 발생합니다. 당 하나의 하위 집합 파라체인, 블록마다 잠재적으로 다른 하위 집합. 이 설정은 일반적으로 파라체인의 블록 시간이 적어도 릴레이 체인의 길이만큼 길어야 합니다. 구체적인 파티셔닝을 결정하는 수단은 범위를 벗어납니다. 4이러한 공격은 적이 제네시스 블록부터 완전히 새로운 역사의 사슬을 구축하는 곳입니다. 제어를 통해 그들은 상쇄된 지분의 상대적으로 작은 부분을 다른 모든 것에 비해 점진적으로 늘릴 수 있습니다. 이해관계자는 대안 역사에 적극적으로 참여하는 유일한 참여자이기 때문입니다. 생성에는 본질적인 물리적 제한이 존재하지 않기 때문에 (실제 계산 에너지를 소비해야 하는 PoW와는 달리) 실제 체인보다 긴 체인을 만들 수 있습니다. 상대적으로 짧은 시간 범위를 가지며 잠재적으로 네트워크의 표준 상태를 인계받아 가장 길고 최상의 상태로 만들 수 있습니다.POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 7 이 문서의 내용은 다음 중 하나에 기반을 두고 있을 가능성이 높습니다. RanDAO [19]과 유사한 커밋-공개 프레임워크 또는 각 파라체인의 이전 블록에서 결합된 데이터를 사용합니다. 암호화된 보안 hash에 따라. validator의 이러한 하위 집합은 다음을 제공해야 합니다. 유효성이 보장된 파라체인 블록 후보 채권몰수의 고통) 타당성은 두 가지를 중심으로 이루어집니다. 중요한 점; 첫째, 그것은 본질적으로 타당하다. 모든 상태 전환이 충실하게 실행되었으며 모든 참조된 외부 데이터(예: 트랜잭션)는 포함에 유효합니다. 둘째, 외부에 있는 모든 데이터는 외부 트랜잭션과 같은 후보는 참가자가 다음을 수행할 수 있도록 충분히 높은 가용성을 가지고 있습니다. 그것을 다운로드하고 수동으로 블록을 실행하십시오.5 검증인은 외부 "거래" 데이터가 포함되지 않은 "널" 블록만 제공할 수 있지만 그렇게 할 경우 보상이 감소할 위험이 있습니다. 그들은 함께 일한다 대조자(개인)가 포함된 파라체인 가십 프로토콜 트랜잭션을 블록으로 수집하고 해당 블록이 상위 블록의 유효한 하위 블록임을 구성하는 비대화형, 영지식 증명을 제공합니다. 문제에 대한 수수료). 자체적으로 지정하는 것은 파라체인 프로토콜에 달려 있습니다. 스팸 방지 수단: "컴퓨팅 리소스 측정" 또는 "거래 수수료"에 대한 기본 개념이 없습니다. 릴레이 체인에 의해 부과됩니다. 또한 릴레이 체인 프로토콜에 의해 이에 대한 직접적인 시행은 없습니다(비록 이해관계자가 채택을 선택할 가능성은 거의 없습니다. 적절한 메커니즘을 제공하지 않는 파라체인). 이는 체인의 가능성에 대한 명시적인 고개를 끄덕이는 것입니다. Ethereum, 예: 훨씬 간단한 수수료 모델이나 아직 제안되지 않은 스팸 방지 모델을 갖춘 Bitcoin와 유사한 체인입니다. Polkadot의 릴레이 체인 자체는 아마도 Ethereum과 유사한 계정 및 상태 체인, 아마도 EVM파생품일 수 있습니다. 릴레이 체인 노드는 다음을 수행해야 하므로 실질적인 기타 처리, 트랜잭션 처리량 수행 큰 거래 수수료를 통해 부분적으로 최소화됩니다. 그리고 연구 모델에 필요한 경우 블록 크기 제한이 있습니다. 5.4. 인터체인 커뮤니케이션. Polkadot의 중요한 최종 요소는 체인 간 통신입니다. 이후 파라체인은 그들 사이에 일종의 정보 채널을 가질 수 있으므로, 우리는 Polkadot a를 고려할 수 있습니다. 확장 가능한 멀티체인. Polkadot의 경우 통신은 매우 간단합니다. 파라체인은 (해당 체인의 논리에 따라) 다음을 수행할 수 있습니다. 트랜잭션을 두 번째 파라체인으로 전달하는 데 영향을 미칩니다. 또는 잠재적으로 릴레이 체인입니다. 외부 거래와 마찬가지로 프로덕션 blockchains에서는 완전히 비동기식입니다. 그리고 그들이 어떤 것을 반환할 수 있는 본질적인 능력도 없습니다. 일종의 정보를 원래의 출처로 되돌리는 것입니다. 목적지: 가져옴 이전 데이터 블록의 validators. 계정이 게시물을 받습니다: 항목이 삭제되었습니다. 수신 Merkle tree 계정에서 게시물을 보냅니다: 에 배치된 항목 송신 Merkle tree 목적지를 위해 파라체인 출구 출처 : 주식 다음 블록의 데이터 validators 보관된 우편물 증명 파라체인 이그레스 머클 나무 라우팅된 참조 배치됨 대상 파라체인에서 수신 Merkle tree 진입 그림 3. 기본 회로도 표시 게시된 라우팅의 주요 부분 거래("게시물"). 구현 복잡성을 최소화하려면 위험 그리고 최소한의 스트레이트 재킷 의 미래 파라체인 아키텍처에서는 이러한 인터체인 트랜잭션이 표준 외부 서명 트랜잭션과 사실상 구별할 수 없습니다. 거래에는 파라체인을 식별하는 기능을 제공하는 원본 세그먼트가 있습니다. 임의의 크기를 가질 수 있는 주소입니다. Bitcoin 및 Ethereum과 같은 일반적인 현재 시스템과 달리, 인터체인 거래에는 어떤 종류의 수수료 "지불"도 함께 제공되지 않습니다. 그러한 지불은 소스 및 대상 파라체인의 협상 로직을 통해 관리되어야 합니다. 제안된 것과 같은 시스템 Ethereum의 Serenity 릴리스 [7]은 간단한 수단이 될 것입니다 하지만 그러한 크로스체인 자원 지불을 관리하는 것은 우리는 적절한 시기에 다른 사람들이 전면에 나올 수 있다고 가정합니다. 인터체인 트랜잭션은 간단한 방법을 사용하여 해결됩니다. Merkle tree을 기반으로 한 대기열 메커니즘을 통해 충실함. 릴레이 체인 유지관리자의 임무는 다음과 같습니다. 하나의 파라체인의 출력 큐에서 트랜잭션을 이동합니다. 대상 파라체인의 입력 큐에 넣습니다. 는 전달된 트랜잭션은 릴레이 체인에서 참조되지만 상대적인 트랜잭션은 아닙니다.체인 거래 자체. 파라체인이 다른 파라체인에 스팸을 보내는 것을 방지하려면 거래, 거래를 보내려면 필요합니다. 대상의 입력 대기열이 너무 크지 않아야 합니다. 이전 블록이 끝나는 시간. 입력의 경우 블록 처리 후 대기열이 너무 크면 "포화"된 것으로 간주되어 트랜잭션이 라우팅되지 않을 수 있습니다. 다시 아래로 줄어들 때까지 후속 블록 내에 포함됩니다. 한계. 이러한 대기열은 릴레이 체인에서 관리됩니다. 파라체인이 서로의 포화도를 결정할 수 있도록 허용 상태; 이런 식으로 거래 게시 시도가 실패했습니다. 지연된 대상에 대한 정보는 동시에 보고될 수 있습니다. (단, 반환 경로가 존재하지 않기 때문에 이러한 이유로 2차 트랜잭션이 실패한 경우 다시 보고할 수 없습니다. 원래 발신자 및 기타 복구 수단 일어나야 할 것입니다.) 5.5. Polkadot 및 Ethereum. Ethereum의 Turing 완전성으로 인해 Polkadot 및 Ethereum이 상호 운용될 수 있는 충분한 기회가 있을 것으로 기대합니다. 적어도 쉽게 추론할 수 있는 보안 범위 내에서 서로. 간단히 말해서, 우리는 다음과 같은 거래를 상상합니다. Polkadot은 validators에 의해 서명된 다음 5이러한 작업은 validator 사이에서 공유되거나 다음과 같이 강력하게 결속된 validator 집합의 지정 작업이 될 수 있습니다. 가용성 보증인.
POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 8 Ethereum 해석되고 제정될 수 있는 곳 거래 전달 계약. 다른 방향으로는, 특별히 형식화된 로그(이벤트)의 사용이 예상됩니다. 특정 메시지가 전달되어야 하는지 신속하게 확인할 수 있는 "돌파 계약"에서 비롯됩니다. 5.5.1. Polkadot ~ Ethereum. A의 선택을 통해 BFT 합의 메커니즘은 validator로 구성됩니다. 승인 투표를 통해 결정된 이해관계자 집합 메커니즘을 통해 우리는 안전한 합의를 얻을 수 있습니다. 자주 변경되지 않으며 적당한 수의 validator입니다. 총 144 validators가 있는 시스템에서 블록 시간은 4초 및 900블록 최종성(악의적인 공격 허용) 이중투표 등 행위 신고, 처벌 복구) 블록의 유효성은 합리적으로 97개의 서명(144개의 2/3에 1을 더한 수)과 챌린지가 저장되지 않는 60분의 검증 기간을 통해 입증된 것으로 간주됩니다. Ethereum는 "침입 계약"을 호스팅할 수 있습니다. 144명의 서명자를 유지하고 다음에 의해 통제될 수 있습니다. 그들. 타원 곡선 디지털 서명(ECDSA) 복구에는 EVM 아래에서 3,000 가스만 필요하므로 우리는 검증이 다음에서만 발생하기를 원할 것입니다. validators의 절대다수(완전한 만장일치 아님), Ethereum의 기본 비용으로 명령어가 실행되었음을 확인합니다. Polkadot 네트워크에서 나오는 가스는 300,000개를 넘지 않을 것으로 적절하게 검증되었습니다. 이는 전체 가스의 6%에 불과합니다. 총 블록 가스 한도는 5.5M입니다. validator 수를 늘립니다(처리에 필요한 만큼). 수십 개의 체인)은 필연적으로 이 비용을 증가시킵니다. 기술이 성숙해지고 인프라가 향상됩니다. 아니라는 사실과 함께 모든 validator이 포함되어야 합니다(예: 가장 높은 이러한 작업을 위해 스테이킹된 validator이 호출될 수 있습니다) 이 메커니즘의 한계는 합리적으로 확장됩니다. 그러한 validator의 일일 순환을 가정합니다(이는 상당히 보수적입니다. 매주 또는 매월도 허용될 수 있습니다.) 그러면 네트워크 유지 관리 비용이 발생합니다. 이 Ethereum 전달 브리지는 약 540,000입니다. 일일 가스 또는 현재 가스 가격으로 연간 $45입니다. 브리지를 통해 단독으로 전달되는 기본 트랜잭션에는 비용이 듭니다. 약 $0.11; 추가 계약 계산 비용 물론 더요. 트랜잭션 버퍼링 및 번들링을 통해 함께 침입 승인 비용은 쉽게 공유하여 거래당 비용을 대폭 절감합니다. 전달하기 전에 20개의 트랜잭션이 필요한 경우 기본 거래를 전달하는 데 드는 비용은 다음과 같습니다. 약 $0.01. 이 다중 서명 계약 모델에 대한 흥미롭고 저렴한 대안 중 하나는 다자간 소유권 의미 체계를 달성하기 위해 임계값 서명을 사용하는 것입니다. ECDSA에 대한 임계값 서명 체계 계산 비용이 많이 들고 다른 방식의 경우 Schnorr 서명과 같은 것은 매우 합리적입니다. Ethereum 이를 가능하게 하는 기본 요소를 도입할 계획입니다. 다가오는 Metropolis 하드포크에서 사용하기 저렴한 계획입니다. 그러한 수단을 사용할 수 있다면 가스 비용은 Polkadot 거래를 Ethereum로 전달하기 위해 네트워크는 거의 0으로 극적으로 줄어들 것입니다. 검증을 위한 기본 비용을 초과하는 간접비 서명 및 기본 트랜잭션 실행. 이 모델에서 Polkadot의 validator 노드는 메시지에 서명하는 것 외에는 거의 할 일이 없습니다. 거래가 실제로 Ethereum 네트워크로 라우팅되도록 하려면 validator 자신도 다음 위치에 있을 것이라고 가정합니다. Ethereum 네트워크 또는 작은 현상금일 가능성이 높습니다. 메시지를 전달한 첫 번째 배우에게 제공됩니다. 네트워크에 (포상금은 사소하게 지급될 수 있습니다. 거래 발신자). 5.5.2. Ethereum ~ Polkadot. 거래가 이루어지도록 하기 Ethereum에서 Polkadot으로 전달되는 것은 간단한 로그 개념을 사용합니다. Ethereum 계약이 Polkadot의 특정 파라체인에 트랜잭션을 전달하려는 경우, 특별한 "돌파 계약"을 호출하기만 하면 됩니다. 브레이크 아웃 계약은 가능한 모든 비용을 지불합니다. Merkle 증명과 해당 블록의 헤더가 유효하다는 주장을 통해 그 존재가 입증될 수 있도록 로깅 명령을 발행해야 합니다. 정식. 후자의 두 조건 중 타당성은 아마도 가장 간단하게 증명할 수 있습니다. 원칙적으로 유일한 요구 사항은 다음과 같습니다.증명이 필요한 각 Polkadot 노드에 대해 (즉, 지정된 validator 노드)는 표준 Ethereum 노드의 완전히 동기화된 인스턴스를 실행합니다. 불행하게도 이것은 그 자체로 상당히 무거운 종속성입니다. 더 경량 방법은 다음과 같은 간단한 증명을 사용하는 것입니다. 헤더만 제공하여 올바르게 평가되었습니다. 제대로 실행하려면 Ethereum의 상태 트리 일부가 필요합니다. 블록 내 트랜잭션을 확인하고 로그(블록 영수증에 포함된)가 유효한지 확인합니다. 이러한 "SPV와 유사한"6 증거에는 상당한 양의 정보가 필요할 수 있습니다. 편리하게도 일반적으로 필요하지 않습니다. 모두: Polkadot 내부의 결합 시스템은 결합을 허용합니다. 제3자가 헤더를 잃을 위험을 무릅쓰고 헤더를 제출할 수 있습니다. 다른 제3자(예: "어부", 6.2.3 참조)가 헤더가 유효하지 않다는 증거를 제공해야 합니다. (특히 상태 루트 또는 수신 루트가 사기꾼이었습니다). Ethereum과 같은 최종화되지 않은 PoW 네트워크에서는 정규성을 최종적으로 증명하는 것은 불가능합니다. 이 문제를 해결하기 위해 모든 종류의 응용 프로그램에 의존하려고 합니다. 체인 종속 원인 효과는 여러 번의 "확인"을 기다리거나 종속 트랜잭션이 어느 정도 완료될 때까지 기다립니다. 체인 내의 특정 깊이. Ethereum에 이 깊이는 알려진 네트워크 문제가 없는 가장 가치가 낮은 거래의 경우 1블록부터 이전과 마찬가지로 1200블록까지 다양합니다. 교환을 위한 초기 프론티어 릴리스 중 사례입니다. 안정적인 "Homestead" 네트워크에서 이 그림은 다음 위치에 있습니다. 대부분의 거래소에는 120개의 블록이 있으며, 우리는 아마도 비슷한 매개변수. 그래서 우리 할 수 있다 상상하다 우리의 Polkadot-쪽 Ethereum인터페이스는 몇 가지 간단한 기능을 갖습니다. Ethereum 네트워크에서 새 헤더를 수락하고 PoW를 검증하여 다음과 같은 일부 증거를 수락할 수 있습니다. 충분한 깊이의 헤더에 대한 Ethereum측 브레이크아웃 계약에 의해 특정 로그가 방출되었습니다(그리고 앞으로 Polkadot 내의 해당 메시지) 그리고 마지막으로 이전에 승인된 증거를 승인할 수 있지만 아직 제정되지 않은 헤더에 잘못된 수신 루트가 포함되어 있습니다. 실제로 Ethereum 헤더 데이터 자체를 얻으려면(그리고 모든 SPV 증명 또는 유효성/정규성 반박) Polkadot 네트워크, 전달에 대한 인센티브 6SPV는 Bitcoin의 Simplified Payment Verification을 의미하며 고객이 거래 내용만 보관하면서 확인할 수 있는 방법을 설명합니다. 가장 긴 PoW 체인의 모든 블록 헤더 사본.POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 9 데이터가 필요합니다. 결제만큼 간단할 수도 있어요 (Ethereum 측에서 징수한 수수료로 자금 조달) 지불됨 헤더가 다음과 같은 유용한 블록을 전달할 수 있는 누구에게나 유효합니다. 검증인은 마지막 수천 개의 블록과 관련된 정보를 유지해야 합니다. 일부 프로토콜 고유 수단을 통해 또는 플랫폼에서 유지되는 계약을 통해 포크를 관리할 수 있습니다. 릴레이 체인. 5.6. Polkadot 그리고 Bitcoin. Bitcoin 상호 운용 Polkadot에 대한 흥미로운 도전 과제를 제시합니다. "양방향 페그"는 유용한 인프라가 될 것입니다. 두 네트워크 측면 모두에 있어야 합니다. 그러나 이로 인해 Bitcoin의 제한 사항, 이러한 페그를 안전하게 제공하는 것은 사소하지 않은 사업. 다음에서 거래 전달 Bitcoin ~ Polkadot은 원칙적으로 Ethereum과 유사한 프로세스로 수행될 수 있습니다. "브레이크아웃 주소" Polkadot validator에 의해 어떤 방식으로든 제어될 수 있습니다. 전송된 tokens(및 함께 전송된 데이터)를 수신합니다. SPV 증명은 인센티브를 받은 oracle에 의해 제공될 수 있으며, 확인 기간과 함께 포상금이 제공됩니다. 트랜잭션을 암시하는 비정규 블록 식별 "이중 지출"되었습니다. token은(는) 다음에서 소유하고 있습니다. "탈출 주소"는 원칙적으로 나중에 분산될 수 있도록 동일한 validator에 의해 제어됩니다. 그러나 문제는 회전하는 validator 세트에서 침전물을 안전하게 제어할 수 있는 방법입니다. 달리 Ethereum 기반으로 임의의 결정을 내릴 수 있습니다. 서명 조합 시 Bitcoin는 실질적으로 더 제한적이며 대부분의 클라이언트는 최대 3명의 당사자와의 다중 서명 거래만 허용합니다. 이를 36개 또는 궁극적으로 원하는 대로 수천 개로 확장하는 것은 현재 프로토콜에서는 불가능합니다. 한 가지 옵션은 Bitcoin 프로토콜을 변경하여 활성화하는 것입니다. 그러나 이러한 기능은 소위 "하드 포크"로 불립니다. Bitcoin 세계는 최근 시도로 판단을 정리하기가 어렵습니다. 한 가지 가능성은 임계값 서명을 사용하는 것입니다. 단일 식별이 가능한 대중을 허용하는 암호화 체계 여러 비밀 "부분"에 의해 효과적으로 제어되는 키, 유효한 서명을 생성하려면 그 중 일부 또는 전부를 활용해야 합니다. 불행하게도 임계값 서명은 호환됩니다. Bitcoin의 ECDSA를 사용하면 계산 비용이 많이 듭니다. 다항식 복잡성을 생성합니다. 다음과 같은 다른 계획 Schnorr 서명은 훨씬 낮은 비용을 제공하지만 Bitcoin에 도입될 수 있는 타임라인 프로토콜이 불확실합니다. 예금의 궁극적인 보안은 여러 개의 validator을 결합하는 경우 다른 옵션 중 하나는 다음과 같습니다. 다중 서명 키 보유자를 크게 줄이십시오. 임계값과 같은 총 validator의 결합된 하위 집합 서명이 가능해집니다(또는 최악의 경우 Bitcoin의 기본 서명 다중 서명이 가능합니다). 이는 물론 validators가 불법적으로 행동할 경우 배상금에서 공제될 수 있는 채권 총액, 그러나 이는 단순히 상한을 설정하는 것은 우아한 성능 저하입니다. 사이에 안전하게 운영될 수 있는 자금의 양 두 개의 네트워크(또는 실제로 공격이 발생하면 % 손실이 발생함) validators에서 성공). 따라서 우리는 합리적으로 안전한 Bitcoin 상호 운용성 "가상 파라체인"을 배치하는 것이 비현실적이지 않다고 생각합니다. 그럼에도 불구하고 일정이 불확실하고 가능성이 매우 높은 상당한 노력이 필요하지만 그 안에서 이해관계자의 협력이 필요하다. 네트워크.
プロトコルの詳細
プロトコルは大きく 3 つに分類できます。 部分: コンセンサスメカニズム、パラチェーンインターフェイス そしてチェーン間トランザクションルーティング。 6.1.リレーチェーン 操作。の リレーチェーン するだろう おそらく、Ethereum とほぼ同様のチェーンである可能性があります。 アドレスをアカウントにマッピングする状態を伴う状態ベースです 情報、主に残高と(リプレイを防ぐため) トランザクションカウンター。ここにアカウントを配置することで、アイデンティティが持つアカウントを提供するという 1 つの目的が達成されます。 システム内のステークの量。7 ただし、顕著な違いがあります。 • コントラクトはトランザクションを通じて展開できません。リレーチェーン上のアプリケーション機能を回避したいという要望から、それは行われません。 契約の公的展開をサポートします。 • コンピューティング リソースの使用量 (「ガス」) は考慮されません。 公的に使用できる唯一の機能であるため、 ガス会計の背後にある理論的根拠は修正されるでしょう もう成立しません。そのため、定額料金が適用されます すべてのケースで、より高いパフォーマンスを可能にします。 動的コードの実行が必要になる場合があります よりシンプルなトランザクション形式。 • リストされたコントラクトでは、自動実行とネットワークメッセージ出力を可能にする特別な機能がサポートされています。 リレーチェーンに VM があり、それが EVM をベースにしているため、最大限の簡素化を実現するために多くの変更が加えられています。 おそらく 多くの組み込みコントラクトがあります ( Ethereum のアドレス 1 ~ 4) を使用して、プラットフォーム固有の コンセンサス契約を含む管理すべき義務、 validator コントラクトとパラチェーン コントラクト。 EVM でない場合は、WebAssembly [2] (wasm) バックエンドが最も可能性の高い代替手段です。この場合は全体的に 構造は似ていますが、その必要はありません Wasm が実行可能なターゲットである組み込みコントラクトの場合 未熟な言語ではなく汎用言語向け EVM の言語は限定されています。 現在の Ethereum プロトコルからのその他の逸脱も十分に考えられます。たとえば、 同じブロック内で競合しないトランザクションを並列実行できるトランザクション受信形式。 Serenity シリーズの変更で提案されているとおりです。 可能性は低いですが、セレニティのようなものである可能性があります。 「純粋な」チェーンをリレー チェーンとして展開できるため、 staking token のようなものを管理するための特定の契約 それを基本的な部分にするのではなく、バランスを取る チェーンのプロトコル。現時点では、その可能性は低いと考えています 十分に優れたプロトコルの簡素化を提供します。 さらなる複雑さと不確実性が伴う価値がある それを開発する上で。 7 特定の保有者がシステム全体のセキュリティに対して責任を負う金額を表す手段として、これらのステーク アカウントは、 必然的に何らかの経済的価値をエンコードします。ただし、このような値を使用する意図はありませんので、ご理解ください。 いかなる方法であっても、現実世界の商品やサービスと交換することを目的とする場合、token を次のものに喩えるものではないことに注意してください。 通貨であるため、リレーチェーンはアプリケーションに関する虚無的な哲学を保持しています。POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 10 コンセンサス メカニズム、validator セット、検証メカニズム、およびパラチェーンを管理するために必要な機能の小さな部分が多数あります。これら モノリシックプロトコルの下で一緒に実装できます。ただし、モジュール性を高めるため、これらをリレーチェーンの「契約」と呼びます。これは、 それらはオブジェクトであることを意味すると解釈されます(という意味で) オブジェクト指向プログラミング)はリレーチェーンのコンセンサスメカニズムによって管理されますが、必ずしもそうではありません これらは、EVM のようなオペコードのプログラムとして定義されていません。 たとえそれらが アカウントシステム。 6.2.ステーキング契約。このコントラクトは validator セットを維持します。以下を管理します。 • 現在 validator であるアカウント。 • 短くするとvalidatorsになる可能性があります 気づいてください。 • どのアカウントが指名権を賭けているか validator; • staking ボリューム、許容可能なペイアウト率とアドレス、および短期 (セッション) ID を含むそれぞれのプロパティ。 アカウントがなりたいという願望を登録できるようになります。 結合された validator (その要件とともに)、何らかのアイデンティティを指名し、既存の結合された validator がこのステータスを終了する希望を登録します。それも 検証および正規化メカニズムのための機構自体が含まれています。 6.2.1.ステーク - token 流動性。一般的に望ましいのは、 合計 staking token をできるだけ多くする ネットワーク保守業務に関与して以来 これは、ネットワーク セキュリティを staking token 全体の「時価総額」に直接結び付けることになります。これは簡単にできます 通貨を吊り上げ、validator として参加する人に収益を分配することでインセンティブが与えられます。ただし、これを行うと問題が発生します。token 減額の罰を受けてステーキングコントラクトに固定されているのに、どうすればかなりの部分が十分に残るのでしょうか 価格発見を可能にするために液体を使用しますか? これに対する 1 つの答えは、単純なデリバティブ契約を許可し、基礎となるステーク済み token 上で代替可能な token を確保することです。これを信頼性のない方法で手配するのは困難です。 さらに、これらのデリバティブ token は、異なるユーロ圏政府の債券が代替不可能であるのと同じ理由で同等に扱うことができません。 原資産が故障して、 無価値。ユーロ圏各国政府では、 デフォルト。 validator でステーキングされた token では、validator が 悪意を持って行動し、罰せられます。 私たちの理念に従い、すべての token を賭けるわけではないという最も単純な解決策を選択します。これはつまり、 token の一部 (おそらく 20%) は強制的に液体のままになります。これはセキュリティの観点からは不完全ですが、根本的な違いを生む可能性は低いです。 ネットワークのセキュリティ。保釈金没収によって可能な賠償金の80%はまだ支払えるだろう 100% staking の「完璧なケース」と比較します。 ステーキングされたtokenとリキッドtokenの比率は、リバース オークション メカニズムを通じて非常に簡単に目標とすることができます。 基本的に、token 保有者は、validator になることに興味があります。 それぞれが、staking 契約に次のようなオファーを投稿します。 要求される最低ペイアウト率 部分。 各セッションの開始時 (セッションは 定期的に、おそらく 1 時間に 1 回程度の頻度で発生します) validator スロットは、それぞれの希望に応じて埋められます validator の賭け金とペイアウト率。考えられるアルゴリズムの 1 つ というのは、これは最低のオファーを持った人たちを採用することになるからです。 目標とする合計賭け金を超えない賭け金を表す スロット数で割った値であり、その半分の下限以上となります。スロットが埋まらない場合は、 下限は、満足するために、何らかの係数によって繰り返し削減される可能性があります。 6.2.2.指名する。信頼性の高い指名が可能 staking token をアクティブな validator に与えます。 validator の職務の責任。作品のノミネート 承認投票システムを通じて。各推薦者候補者は、staking 契約に指示を投稿できます。 1 つ以上の validator アイデンティティを表現し、その下に 彼らは自分たちの絆を託す用意があるという責任を持っています。 各セッションでは、推薦者の絆が分散されます。 1 つ以上の validator で表されます。分散アルゴリズムは、合計が等しい validator のセットを最適化します。 絆。指名者の債券は、validator a の有効な責任の下に置かれます。利息を得るか、苦しむか それに応じて刑罰も軽減される。 6.2.3.保証金の没収/バーニング。特定のvalidator行動により、懲罰的に絆が減らされます。もし ボンドが許容最小値を下回った場合、 セッションが途中で終了し、別のセッションが開始されました。罰せられるvalidatorの不正行為のリストはすべてではありませんが、次のとおりです。 • パラチェーングループの一員であるため、提供できない パラチェーンブロックの有効性についてのコンセンサス。 • 無効なファイルの有効性を確認するために積極的に署名する。 パラチェーンブロック。 • 以前は出力ペイロードを提供できなかった 利用可能として投票しました。 • 合意プロセス中の非アクティブ。 • 競合するフォーク上のリレーチェーンブロックを検証する。 不正行為の一部のケースでは、ネットワークの完全性が脅かされ(無効なパラチェーン ブロックへの署名やフォークの複数の側面の検証など)、その結果、ボンドの全体的な削減を通じて実質的な追放が発生します。で その他、それほど深刻ではないケース (例: コンセンサスにおける不活動) プロセス)、または責任を正確に割り当てることができない場合(非効率なグループの一員である場合)、ごく一部 代わりに、債券の全額に罰金が課される場合があります。後者の場合、これは サブグループのチャーンとうまく連携して、悪意のある行為が確実に行われるようにします。 ノードは、巻き添えで被害を受けた善良なノードよりも大幅に多くの損失を被ります。 場合によっては (マルチフォーク検証や無効な場合など) サブブロック署名) validator は定期的に検証されるため、互いの不正行為をそれ自体で簡単に検出できません。 各パラチェーンブロックの作成は非常に困難な作業になります。ここ 社外の関係者の支援を得る必要がある そのような不正行為を検証して報告するための検証プロセス。当事者は、そのような活動を報告すると報酬を受け取ります。彼らの「漁師」という言葉は、ありそうもないことに由来しています。 そのような報酬の。 通常、これらの事件は非常に深刻であるため、私たちは、没収された保証金から報酬が簡単に支払われることを想定しています。 一般に、燃焼のバランスをとることを好みます。 (つまり、ゼロに減らす) ではなく、再割り当てを使用します。 大規模な再配分を試みています。これには次のような効果があります
POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 11 token の全体的な値を増やし、 特定のネットワークではなく、ある程度のネットワーク全般 発見に関与した当事者。 これは主に安全のためです メカニズム: 大量のものが関与するため、すべてが揃った場合、極端かつ急性の行動の奨励につながる可能性があります。 単一の対象に与えられます。 一般に、報酬は、ネットワークにとって検証を価値のあるものにするのに十分な額であることが重要ですが、ネットワークのフロントにかかるコストを相殺できるほど大きくないことが重要です。 資金力があり、巧妙に組織された「業界レベル」の犯罪者 不運な validator に対してハッキング攻撃を行い、不正行為を強制します。 このようにして、請求額は通常、ゼロになるはずです。 誤ったvalidatorの直接結合より大きい。 不正行為をしたり、報奨金を得るために自分自身を報告したりすることによって生じる倒錯的なインセンティブ。これは明示的に対処できます になるための最低直接債券要件を通じて validator または、保証金がほとんど預けられていない validator には大きなインセンティブがないことを推薦者に教育することによって暗黙的に 行儀よく振る舞うこと。 6.3.パラチェーンレジストリ。各パラチェーンは次のように定義されます。 このレジストリ。これは比較的単純なデータベースのような構造であり、静的情報と動的情報の両方を保持します。 各チェーン。 静的情報には、チェーン インデックス (単純な 整数)、検証プロトコル ID とともに、 異なるクラスを区別する手段 パラチェーンを使用することで、正しい検証アルゴリズムを実現できます。 有効な候補者を推薦するよう委託されたvalidatorsによって運営されています。最初の概念実証では、配置に焦点を当てます。 新しい検証アルゴリズムがクライアント自体に組み込まれるため、事実上、毎回プロトコルのハードフォークが必要になります。 チェーンの追加クラスが追加されました。結局のところ、 検証アルゴリズムを指定できる場合があります。 クライアントが安心して利用できるよう、厳密かつ効率的な方法です。 新しいパラチェーンを効果的に操作できる ハードフォーク。これに対する考えられる手段の 1 つは、次のように指定することです。 十分に確立されたパラチェーン検証アルゴリズム、 WebAssembly など、ネイティブにコンパイルされたプラットフォームに依存しない言語。判断するには追加の調査が必要です これが本当に実現可能かどうかはわかりませんが、もし可能であれば、 これにより、ハードフォークを排除するという大きな利点が得られます 永遠に。 動的情報には、グローバルな合意が必要なトランザクション ルーティング システムの側面が含まれます。 パラチェーンの入力キューとして(セクション6.6で説明)。 レジストリにはパラチェーンのみを追加できます 国民投票の完全な投票を通じて。これはなんとかなるだろう 内部に配置されますが、外部に配置される可能性が高くなります。 再利用を容易にするための住民投票契約 より一般的なガバナンスコンポーネント。パラメータは 投票要件 (例: 必要な定足数、過半数 必須)追加チェーンの登録など、 あまり正式ではないシステムのアップグレードは「マスター」で規定されます。 憲法」に従うが、かなり伝統的なものに従う可能性が高い 少なくとも最初はパス。正確な配合はできていない 現在の作業の範囲ですが、例:システム全体の 3 分の 1 以上で可決する 3 分の 2 の圧倒的多数 積極的に投票することが賢明な出発点かもしれません。 追加の操作には、パラチェーンの一時停止と削除が含まれます。 サスペンションは願わくば決してないでしょう しかし、それは最低限の安全策として設計されています パラチェーンの検証システムには解決しがたい問題があります。それが起こる可能性がある最も明白な例は、 必要なのは、実装間のコンセンサスが重要な違いであるため、validator は同意できない 有効性またはブロック。バリデーターは使用することをお勧めします。 複数のクライアント実装を可能にするために 保釈金を没収される前にそのような問題を発見すること。 停止は緊急措置なので、 むしろ動的なvalidator投票の後援の下で 住民投票よりも。再インストールはどちらも可能です validators または住民投票から。 パラチェーンの完全な除去は、 国民投票の後、それに伴い、 ~への秩序ある移行を可能にするための実質的な猶予期間 スタンドアロンのチェーンか、他のチェーンの一部になるかのどちらか コンセンサスシステム。 猶予期間はおそらく次のとおりです 数か月のオーダーで、異なる順序でパラチェーン レジストリにチェーンごとに設定される可能性があります。 パラチェーンは、以下に応じてさまざまな猶予期間を楽しむことができます。 彼らの必要性。 6.4.リレーブロックの密閉。シーリングとは、本質的には、 正規化のプロセスへ。つまり基礎データです どれを変換するオリジナルを根本的に特異で意味のあるものにマッピングします。 PoW チェーンの下では、 封印は事実上採掘と同義です。私たちの場合、 これには、validators からの、有効性、可用性、正規性に関する署名付きステートメントの収集が含まれます。 特定のリレーチェーン ブロックとパラチェーン ブロック それは表します。 基礎となる BFT コンセンサス アルゴリズムの仕組みは、現在の作業の範囲外です。 させていただきます 代わりに、を想定するプリミティブを使用してそれを記述します。 合意形成ステートマシン。最終的に私たちが期待するのは、 多くの有望なBFTコンセンサスに触発される コア内のアルゴリズム。 Tangaora [9] (BFT の亜種) ラフト [16])、テンダーミント [11]、ハニーバジャーBFT [14]。 アルゴリズムは複数のパラチェーンで並行して合意に達する必要があるため、通常のアルゴリズムとは異なります。 blockchain コンセンサス メカニズム。一度は コンセンサスに達した場合、そのコンセンサスを記録することができます 以下のいずれかによって提供できる反駁できない証拠において 参加者はそれに参加します。不正行為も想定されます プロトコル内では通常、小さな値に減らすことができます。 不正行為を行った参加者を含むグループを最小限に抑える 罰を与える際の巻き添え被害。8 私たちの署名済みステートメントの形式をとった証明は、リレーチェーンブロックのヘッダーに一緒に配置されます 他の特定のフィールド、特にリレーチェーンのステートトライルートとトランザクショントライルート。 の 封印 プロセス かかります 場所 下 ある 独身 合意形成 仕組み アドレス指定 両方 の リレーチェーンのブロックとパラチェーンのブロック リレーのコンテンツの一部: パラチェーンはサブグループによって個別に「コミット」されてから照合されるわけではありません 後で。これにより、リレーチェーンのプロセスがより複雑になりますが、システム全体のコンセンサスを 1 つの段階で完了できるため、遅延が最小限に抑えられ、 非常に複雑なデータ可用性要件に対応します。 以下のルーティング プロセスに役立ちます。 8 Tendermint BFT やオリジナルの Slasher などの既存の PoS ベースの BFT コンセンサス スキームは、これらの主張を満たしています。
POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 12 各参加者のコンセンサスマシンの状態は、 単純な (2 次元) テーブルとしてモデル化できます。各参加者 (validator) は、次の形式で一連の情報を持っています。 各パラチェーン ブロック候補およびリレーチェーン ブロック候補に関する他の参加者からの署名付きステートメント (「投票」) の合計。情報のセットは 2 つです データの: 可用性: あります これ validator 持っています 出口 このブロックからのトランザクションポスト情報なので、 次のブロックのパラチェーン候補を適切に検証できますか?彼らは投票するかもしれない 1 (既知) または 0 (まだ不明)。かつて彼らは 1 票を投じる場合、彼らは同様に投票することを約束します。 このプロセスの残りの部分。そうでない後の投票 これが処罰の理由であることを尊重してください。 有効性: パラチェーン ブロックは有効であり、すべて有効です。 外部参照データ (例: 取引) 利用可能ですか?これは、投票しているパラチェーンに割り当てられている validator にのみ関係します。 1 (有効)、-1 (無効)、または 0 のいずれかに投票できます。 (まだ知られていません)。一度非ゼロに投票すると、 残りの期間もこの方法で投票することを約束します プロセス。これを尊重しない後の投票 が処罰の根拠となります。 すべての validator は投票を提出する必要があります。投票は上記のルールに従って再提出することができます。の進行状況 コンセンサスは、各パラチェーン上で並行して発生する複数の標準 BFT コンセンサス アルゴリズムとしてモデル化できます。これらは相対的な要因によって潜在的に妨げられるため、 少数の悪意のある攻撃者が集中している 単一のパラチェーン グループでは、全体的なコンセンサスが存在します。 バックストップを確立し、最悪のシナリオを制限します。 1 つまたは複数の無効なパラチェーン ブロックのみでデッドロック (および 責任者には一連の懲罰を科す)。 個々のブロックの有効性に関する基本規則 (これにより、validator の合計セットが全体として次のようになります) 独自のパラチェーン候補となることで合意 正規リレーから参照されます): • validator の少なくとも 3 分の 2 が肯定的に投票し、否定的に投票する人がいない必要があります。 • 出力キュー情報の利用可能性に肯定的に投票している validator が 3 分の 1 を超えている必要があります。 有効性に関して少なくとも 1 つの肯定的な投票と少なくとも 1 つの否定的な投票がある場合、例外条件が作成されます。 validator のセット全体が投票して決定する必要があります 悪意のある当事者がいる場合、または事故があった場合 フォーク。有効・無効以外の第三の投票 これは両方に投票することと同等です。つまり、 ノードには矛盾した意見があります。この原因として考えられるのは、 ノードの所有者は複数の実装を実行しています。 一致しない場合は、プロトコルに曖昧さがある可能性があることを示しています。 すべての投票が完全な validator セットからカウントされた後、次の場合 負けた意見は少なくともある程度の割合を占める( パラメータ化される。多くても半分、おそらく大幅に少ない) 勝利意見の投票のうち、次のように仮定されます。 偶発的にパラチェーンがフォークされた場合、パラチェーンはコンセンサスプロセスから自動的に一時停止されます。そうでない場合は、悪質な行為とみなし、処罰します。 反対意見に投票した少数派。 結論は、次のことを示す一連の署名です。 正規性。その後、リレーチェーンブロックを密閉することができます そして次のブロックを封印するプロセスが始まりました。 6.5.シールリレーブロックの改良。その間 このシール方法はシステムの動作を強力に保証しますが、スケールアウトはあまりうまくいきません すべてのパラチェーンの鍵情報には、 すべての validator の 3 分の 1 以上で可用性が保証されています。 これは、すべての validator の責任の足跡が チェーンが追加されると増加します。 オープンコンセンサスネットワーク内でのデータの可用性 これは本質的に未解決の問題ですが、validator ノードにかかるオーバーヘッドを軽減する方法はあります。シンプルな 1 つの 解決策は、validators が負担しなければならないことを認識することです データの可用性に対して責任を負うため、データ自体を実際に保存、通信、複製する必要はありません。 セカンダリ データ サイロ。おそらく関連する (あるいは、まさに 同じ)このデータを編集する照合者は、 validator が利息/収入の一部を支払いとして提供することで、利用可能性を保証するというタスク。 ただし、これによりある程度の中間的なスケーラビリティは得られるかもしれませんが、それでも根本的な問題の解決にはなりません。それ以来 チェーンを追加するには、通常、追加の validator が必要となり、継続的なネットワーク リソースの消費 (特に帯域幅の点で) は の 2 乗で増加します。 の鎖は長期的には維持できない性質です。 結局のところ、我々は頭を打ち続けることになるだろう という基本的な制限に反して、 安全に利用できるとみなされるコンセンサスネットワーク、 継続的な帯域幅要件は合計のオーダーに相当します validators 倍の合計入力情報。これは次の理由によるものです 信頼できないネットワークでは、データ ストレージのタスクを多くのノードに適切に分散できず、 処理という非常に分散可能なタスクは別として。 6.5.1.レイテンシーの紹介。これを和らげる一つの手段 ルールは、即時性の概念を緩和することです。 可用性に関して 33%+1 validators の投票をすぐにではなく最終的にのみ要求することで、指数関数的なデータ伝播をより効果的に活用し、データ交換のピークを平準化することができます。 合理的な平等(証明されていないが) 次のようになります: (1) レイテンシ = 参加者 × チェーン 現在のモデルでは、システムのサイズが拡大します 処理が確実に行われるようにチェーンの数を設定します。 配布された。各チェーンには少なくとも 1 つの validator が必要であり、可用性証明書を定数に固定するためです。 validator の割合が増加すると、参加者も同様に増加します チェーンの数で。最終的には次のようになります。 (2) レイテンシ = サイズ2 つまり、システムが成長するにつれて、必要な帯域幅と可用性が得られるまでの遅延がシステム全体で判明します。 ネットワーク。番号としても特徴付けられます。 ファイナリティ前のブロックの数は、その二乗に応じて増加します。これは これは実質的な成長要因であるが、それが顕著な障害となり、私たちを「非フラット」パラダイムに追い込む可能性がある 複数の「Polkadot」を階層に構成するなど リレーチェーンのツリーを介したポストのマルチレベルルーティング用。
POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 13 6.5.2.一般参加。もう一つ考えられる方向性 それは、プロセスへの一般の参加を求めることです。 マイクロクレームシステム。漁師と同じように、 主張するvalidatorを取り締まる外部の関係者である可能性があります 可用性。 彼らの任務は、そのような能力を証明できないと思われる人物を見つけることです。 そうすることで彼らは 他の validator に対してマイクロ苦情を申し立てることができます。捕虜か シビル攻撃を軽減するためにステーキングボンドが使用される可能性があります そうなるとシステムはほとんど役に立たなくなります。 6.5.3.可用性の保証者。最終的なルートは次のとおりです 結合された validator の 2 番目のセットを「可用性」として指名します。 保証人」。これらは通常の validator と同様に結合され、同じセットから取得されることもあります (ただし、その場合、少なくともセッションごとに、長期にわたって選択されることになります)。通常の validator とは異なり、 パラチェーン間で切り替えるのではなく、 すべての重要なチェーン間データの可用性を証明するために単一のグループを形成します。 これには、参加者とチェーン間の等価性が緩和されるという利点があります。 基本的に、チェーンは次のことができます。 (元のチェーン validator セットとともに) 成長しますが、 参加者、特にデータ可用性の証明に参加する人々は、少なくとも準線形性を維持できます。 そしておそらく一定です。 6.5.4.照合者の設定。この重要な側面の 1 つは、 このシステムは、健全な選択が行われることを保証することを目的としています。 特定のパラチェーンでブロックを作成するコレーター。もし 単一の照合者がパラチェーンを支配し、その後いくつかの攻撃を行った が不足する可能性が高いため、より実現可能になります。 外部データの利用可能性はそれほど明らかではありません。 1 つのオプションは、パラチェーン ブロックに人工的に重み付けすることです。 さまざまな照合者を優先するための擬似ランダム メカニズム。まず第一に、次のようにします。 validators が支持するコンセンサス メカニズムの一部として パラチェーンブロック候補は「より重い」と判定されました。 同様に、validator に次のことを試みるよう奨励する必要があります。 見つけられる最も重いブロックを提案します。これはおそらく これは、報酬の一部を候補者の体重に比例させることで行われます。 照合者に合理的な公平性が与えられるようにするため 彼らの候補者が勝利者として選ばれる可能性 候補者が合意に達した場合、私たちは特定の重要性を決定します。 パラチェーンブロック候補は、各照合器に接続されたランダム関数で決定されます。 たとえば、 照合者の住所間の XOR 距離測定値 および暗号的に安全な擬似乱数 ブロックが作成されるポイントの近くで決定される (概念的な「当たりチケット」)。これにより、それぞれに効果的な効果が得られます。 照合者 (より具体的には、各照合者の住所) 候補ブロックが「勝つ」ランダムな確率 他のすべて。 単一の照合者によるシビル攻撃を軽減するために、当選チケットに近いアドレスを「マイニング」し、 各ブロックをお気に入りにするには、照合者のアドレスに慣性を追加します。これは、それらを要求するのと同じくらい簡単かもしれません アドレスにベースライン金額の資金が含まれていること。さらに エレガントなアプローチは、 に駐車した金額の当選チケット 問題のアドレス。まだモデリングは終わっていないのですが、 このメカニズムにより、非常に 小規模な利害関係者が照合者として貢献します。 6.5.5.太り過ぎのブロック。 validator セットが侵害された場合、ブロックを作成して提案する可能性がありますが、 有効ですが、実行に膨大な時間がかかり、 検証します。 validator グループは次のような可能性があるため、これは問題です。 非常に長い時間がかかるブロックを合理的に形成する ショートカットを許可する特定の情報がすでにわかっている場合を除き、実行します。大きな因数分解 プライム。 もし 1 人の照合者がその情報を知っていたとしたら、 彼らは自分たちで手に入れたほうが明らかに有利だろう 他の候補者は、古いブロックの処理で忙しい限り受け入れられました。これらのブロックをオーバーウェイトと呼びます。 これらのブロックの送信と検証を行う validator に対する保護は、主に、 無効なブロックですが、追加の警告があります: ブロックの実行にかかった時間 (およびそのステータス) 太りすぎ)は主観的なものであり、投票の最終結果は 不正行為は基本的に 3 つのグループに分類されます。 1 つ 可能性としては、ブロックが明らかに太りすぎではないということです。 この場合、3分の2以上が「できる」と宣言している。 ある制限内でブロックを実行します (例: ブロック間に許可される合計時間の 50%)。 もう一つは、 ブロックはdです間違いなく太りすぎです。これは、以下の場合に当てはまります。 3 分の 2 がブロックを実行できなかったと宣言 上記制限内で。 最後の可能性はほぼ等しいです validator の間で意見が分かれています。この場合、私たちは、 相応の罰を与えることを選択します。 validator がいつそうなるかを確実に予測できるようにするため オーバーウェイトブロックを提案する場合、各ブロックのパフォーマンスに関する情報を公開するよう要求するのが賢明かもしれません。十分な期間を経て、 これにより、処理速度のプロファイリングが可能になるはずです 彼らを判断するであろう仲間と比較して。 6.5.6.コレーター保険。 validators には次の問題が 1 つ残っています。 PoW ネットワークとは異なり、照合者の 有効性を確保するためにブロックを作成するには、実際にその中でトランザクションを実行する必要があります。悪意のある照合者は、無効なブロックや重量超過のブロックを validator にフィードして、彼らを苦しめる (無駄な) 可能性があります。 彼らのリソース)、潜在的にかなりの機会費用がかかることになります。 これを軽減するために、私たちは、 validator の一部。まず、パラチェーンブロック候補が送信されました validator へはリレー チェーン アカウントから署名する必要があります 資金を使って。そうでない場合は、validator がドロップされるはずです それはすぐに。第二に、そのような候補は、次の組み合わせ(乗算など)によって優先順位を付ける必要があります。 アカウント内の資金の量が一定の上限まで、 照合者が過去に提案に成功した以前のブロックの数 (以前のブロックは言うまでもありません) 罰)、および勝利への近接要因 前述したようにチケット。キャップも同じはず この事件でvalidatorに支払われた懲罰的損害賠償金として うちは無効なブロックを送信しています。 照合者が無効または過大なブロック候補を validator に送信することを妨げるために、validator は次のことを行うことができます。 次のブロックに、不正行為を主張する問題ブロックを含むトランザクションを配置し、不正行為を行った照合者の資金の一部または全部を転送する 被害を受けたvalidatorにアカウントを送信します。 このタイプのトランザクションは、照合者が確実に実行できないように、他のトランザクションよりも優先して実行されます。 処罰の前に資金を削除してください。の量 損害賠償として送金される資金はまだ動的パラメータです
POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 14 モデル化される予定ですが、引き起こされた悲しみのレベルを反映するvalidatorブロック報酬の割合になる可能性があります。へ 悪意のある validator が照合者の資金を恣意的に没収するのを防ぐため、照合者はその代わりにランダムに選ばれた validator からなる陪審を招いて validator の決定に対して上訴することができます 少額の入金のため。 彼らが validator に有利であると判断した場合、デポジットは彼らによって消費されます。そうでない場合は、 デポジットは返還され、validator には罰金が科せられます( validator ははるかにアーチ型の位置にあり、罰金は おそらくかなり重いでしょう)。 6.6.インターチェーン トランザクション ルーティング。インターチェーン トランザクション ルーティングは重要なメンテナンスの 1 つです リレーチェーンのタスクとそのvalidator。 これは、 投稿されたトランザクション (多くの場合、単に「投稿」と短縮される) が望ましい出力になるまでの過程を制御するロジック あるソースパラチェーンから、信頼を持たない別の宛先パラチェーンの交渉不可能な入力になるまで 要件。 上記の文言は慎重に選択しています。特に私たちは ソース内にトランザクションが存在する必要はありません parachain はこの投稿を明示的に承認しました。唯一の 私たちがモデルに課す制約は、パラチェーンです。 ブロック全体の一部としてパッケージ化して提供する必要があります 処理出力、その結果である投稿 ブロックの実行。 これらのポストは、複数の FIFO キューとして構造化されています。の リストの数はルーティング ベースとして知られており、 およそ 16。注目すべきことに、この数字は数量を表します。 に頼ることなくサポートできるパラチェーンの数 マルチフェーズルーティング。当初、Polkadot はこれをサポートします 一種の直接ルーティングですが、考えられる 1 つの概要を説明します。 手段としてのマルチフェーズ配線プロセス (「ハイパー配線」) パラチェーンの初期セットをはるかに超えてスケールアウトします。 私たち 仮定する それ すべて 参加者 知っています の 次の 2 つのブロック n、n + 1 のサブグループ化。要約すると、 ルーティング システムは次の段階に従います。 • CollatorS: Validators[n][S] のメンバーに連絡します。 • CollatorS: サブグループごとに: で確認します。 V alidators[n][s] の少なくとも 1 人のメンバーが接触中 • コレーター: 各サブグループについて: 仮定する egress[n −1][s][S] が利用可能です (すべての受信ポスト 最後のブロックから「S」へのデータ) • コレーター: S のブロック候補 b を構成します。 (b.header、b.ext、b.proof、b.receipt、b.egress) • コレーター: 送信 証拠 情報 proof[S] = (b.header、b.ext、b.proof、b.receipt) から バリデーター[n][S] • CollatorS: 外部トランザクション データ b.ext を保証します。 他の照合者とvalidatorが利用できるようになります • コレーター: のための それぞれ サブグループ s: 送信 出口 情報 出口[n][S][s] = (b.header、b.receipt、b.egress[s]) に の 受信 サブグループの メンバー の 次へ ブロック バリデータ[n + 1][s] • ValidatorV : すべての同じセットのメンバーを事前接続します 次のブロックの場合: N = Chain[n + 1][V ]; とします。接続する Chain[n + 1][v] = N となるすべての validators v • バリデーター V : このためのすべてのデータ入力を照合します ブロック: のための それぞれ サブグループ s: 取得 egress[n −1][s][Chain[n][V ]]、Chain[n][v] = Chain[n][V ] となるように他の validators v から取得します。 おそらく、試みの証拠として、ランダムに選択された他の validator を経由します。 • バリデーター V : これに対する候補証明を受け入れる ブロックプルーフ[Chain[n][V ]]。投票ブロックの有効性 • バリデーター V : の候補出力データを受け入れる 次のブロック: サブグループごとに、受け入れます 出口[n][s][N]。投票ブロック出力の可用性。関心のある validator 間で再公開します。 チェーン[n + 1][v] = チェーン[n + 1][V ]。 • ValidatorV : コンセンサスが得られるまで ここで: egress[n][from][to] は現在の出力キューです。 パラチェーン「from」から~への投稿に関する情報 ブロック番号「n」のパラチェーン「to」。 CollatorS は、パラチェーン S の照合器です。V alidators[n][s] は、ブロック番号 n のパラチェーンの validator のセットです。逆に、 Chain[n][v] は、ブロック番号 n で validator v が割り当てられるパラチェーンです。 block.egress[to] は出口です パラチェーンブロックからの投稿のキュー。 パラチェーンの目的地は です。 照合者は以下に基づいて(取引)手数料を徴収するため、 彼らのブロックが正規化されることを奨励されている 次のブロックの宛先ごとに、サブグループの メンバーには現在からの出力キューが通知されます ブロック。バリデーターは、(パラチェーン)ブロックに関する合意形成のみを目的としており、それ自体はほとんど気にしません。 どの照合者のブロックが最終的に正規となるのか。で 原則として、validator は照合者と同盟を結び、他の照合者が犯罪に関与する可能性を減らすために共謀する可能性があります。 ブロックが正規化されますが、これは両方とも困難です ランダムセレのため手配しますvalidator のアクション パラチェーンは、持続するパラチェーンブロックに支払われる手数料を削減することで防御できる可能性があります。 コンセンサスプロセス。 6.6.1.外部データの可用性。パラチェーンの確保 外部データが実際に利用できるかどうかは、永続的な問題です ワークロードを分散することを目的とした分散型システム ネットワーク。問題の中心は可用性です どちらも不可能であるため、 非インタラクティブな可用性の証明などを作成する BFT システムが適切に利用できないことの証明 正確さが依存する遷移を検証します。 一部の外部データの利用可能性、最大数 許容可能なビザンチン ノードの数とシステムの 1 つ データが利用可能であることを証明する必要があります。 Polkadot のように、システムが適切にスケールアウトするには、これ 問題が発生します: validators の割合が一定の場合 データの可用性を証明する必要があり、次のように仮定します。 validators は、データが利用可能であると主張する前に実際にデータを保存したいと考えている場合、どうすれば回避できますか? システムのサイズ (したがって validator の数) に応じて増加する帯域幅/ストレージ要件の問題はありますか?考えられる答えの 1 つは、別のセットを用意することです。 validator 件 (在庫保証者)、注文は増加中 全体として Polkadot のサイズでサブリニアに。これは 6.5.3 で説明されています。 二次的なトリックもあります。 グループとしての照合者には、すべてのデータが確実に収集されるようにするという本質的なインセンティブがあります。 選択したパラチェーンがなければ利用可能です。 それ以上のブロックを作成できません。 取引手数料を徴収します。照合者もグループを形成しますが、そのメンバーは (ランダムな性質のため) 様々です。 パラチェーン validator グループ) 入力は簡単ではありません
POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 15 証明するために。したがって、最近の照合者 (おそらく最後の数千ブロック) は、 特定のパラチェーンの外部データの利用可能性 小規模な結合の場合は validators までブロックします。 検証者は、明らかに違反している validator サブグループの証言者に連絡し、データを取得して照合者に返すか、検証をエスカレーションする必要があります。 利用可能性が欠如していることを証言することで問題を解決する (データの提供を直接拒否することは保釈金没収犯罪としてカウントされるため、不正行為を行った validator はおそらくただの罪になるだろう) 接続を切断します)、追加の validator に連絡します 同じテストを実行します。後者の場合、担保保証金 が返されます。 このような利用不能の証言を行うことができる validator の定足数に達すると、解放され、 不正行為をしたサブグループは罰せられ、ブロックは元に戻されます。 6.6.2.投稿ルーティング。各パラチェーンヘッダーには、 出口トライルート;これは、を含むトライのルートです。 ルーティングベースのビン。各ビンは連結されたリストです 出口ポストの数。 マークル証明はさまざまな場所で提供される可能性があります parachain validators は、特定のパラチェーンの ブロックには、特定の宛先パラチェーンに対する特定の出力キューがありました。 パラチェーンブロックの処理の開始時に、それぞれの 当該ブロックに向かう他のパラチェーンの出力キューは ブロックの入力キューにマージされました。私たちは強いと仮定しますが、 おそらく CSPR9、サブブロックの順序付けにより、どのサブブロックにも優先順位が与えられない決定論的な操作を実現します。 パラチェーンブロックペアリング。照合者は新しいキューを計算します パラチェーンに従って出力キューを排出します ロジック。 入力キューの内容は明示的に書き込まれます。 パラチェーンブロックに入れます。 これには主に次の 2 つの目的があります。 まず、これはパラチェーンが他のパラチェーンから独立してトラストレスに同期できることを意味します。第二に、 イングレス全体が発生した場合のデータロジスティクスを簡素化します。 キューを単一のブロックで処理することはできません。 validator と照合者は次のブロックを処理できます キューのデータを特別に取得する必要はありません。 パラチェーンの入力キューがしきい値を超えている場合 ブロック処理の終了時に量がマークされる リレーチェーン上で飽和状態になり、それ以上のメッセージは送信できなくなります クリアされるまで配信されます。 マークル証明は、 照合者の操作の忠実性を実証するために使用されます。 パラチェーンブロックの証拠。 6.6.3.批評。この基本に関する小さな欠陥が 1 つあります メカニズムは爆弾後攻撃です。 ここがすべての場所です パラチェーンは可能な限り最大量の投稿を送信します 特定のパラチェーンに。これによりターゲットが拘束される一方で、 キューを一度に入力しても、何度繰り返してもダメージはありません 標準的なトランザクション DoS 攻撃。 正常に動作しており、十分に同期されており、 悪意のないコレーターと validator (N 個のパラチェーンの場合)、 パラチェーンごとに合計 N × M validator と L 個の照合器があり、 ブロックごとの合計データ経路を次のように分類できます。 バリデータ: M −1+L+L: 他の validator の場合は M −1 パラチェーン セットでは、候補パラチェーン ブロックを提供する各コレーターに L、各コレーターに 2 番目の L 前のブロックの出力ペイロードを必要とする次のブロックの。 (後者は実際には最悪のケースに近いです) 照合者がそのようなものを共有する可能性が高いため、 データです。) Collator: M +kN: M (関連するそれぞれへの接続用) パラチェーン ブロック validator、各パラチェーン validator グループのサブセットに出力ペイロードをシードするための kN 次のブロック (およびおそらくお気に入りの照合者)。 そのため、ノードごとのデータ パスウェイは直線的に増加します。 システム全体の複雑さによります。これがある間、 システムが数百または数千のパラチェーンにスケールアップされると、ある程度の通信遅延が発生する可能性があるのは当然です。 複雑さの増加率を下げる代わりに吸収されます。 この場合、マルチフェーズルーティングアルゴリズムが使用される可能性があります。 瞬間的な経路の数を減らすため その代償として、ストレージ バッファとレイテンシが発生します。 6.6.4.ハイパーキューブルーティング。ハイパーキューブ ルーティングは、主に、 上で説明した基本的なルーティング メカニズム。 本質的には、 パラチェーンやサブグループノードの数に応じてノード接続を増やすのではなく、 パラチェーンの対数。投稿は次の間を通過する可能性があります 最終配送に向かういくつかのパラチェーンのキュー。 ルーティング自体は決定的でシンプルです。まずは、 入力/出力キュー内のビンの数を制限します。 パラチェーンの総数ではなく、 はルーティングベース (b) 。これは数値として固定されます パラチェーンの変更が行われ、代わりにルーティング指数 (e) が増加します。このモデルでは、メッセージ量は O(be) とともに成長し、経路は一定のまま およびレイテンシー (または配信に必要なブロック数) O(e)で。 私たちのルーティング モデルは e 次元の超立方体です。 立方体の各側面には b 個の可能な位置があります。 各ブロックでは、単一の軸に沿ってメッセージをルーティングします。私たち ラウンドロビン方式で軸を交互に切り替えることで、ブロックの最悪の場合の配信時間が保証されます。 パラチェーン処理の一部として、外部バインド 入力キューで見つかったメッセージは、適切な出力キューのビンに直ちにルーティングされます。 現在のブロック番号 (および配線次元)。これ このプロセスではホップごとに追加のデータ転送が必要になります 配送ルート上だが、それ自体が問題 何らかの代替手段を使用することで軽減できる可能性があります データ ペイロード配信の、参照のみを含む、 ポストトライのポストの完全なペイロードではなく。 システムのハイパーキューブ ルーティングの例 パラチェーンが 4 つある場合、b = 2 および e = 2 は次のようになります。 フェーズ 0、各メッセージ M: • sub0: if Mdest ∈{2, 3} then sendTo(2) else keep • sub1: if Mdest ∈{2, 3} then sendTo(3) else keep • sub2: if Mdest ∈{0, 1} then sendTo(0) else keep • sub3: if Mdest ∈{0, 1} then sendTo(1) else keep フェーズ 1、各メッセージ M: • sub0: if Mdest ∈{1, 3} then sendTo(1) else keep • sub1: if Mdest ∈{0, 2} then sendTo(0) else keep • sub2: if Mdest ∈{1, 3} then sendTo(3) else keep • sub3: if Mdest ∈{0, 2} then sendTo(2) else keep ここでの 2 つの次元は、最初に見るのが簡単です。 宛先インデックスの 2 ビット。最初のブロックでは、 上位ビットのみが使用されます。 2 番目のブロックの取引 下位ビットを使用します。両方が発生すると(任意で) 順序)、投稿はルーティングされます。 9暗号的に安全な擬似ランダム
POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 16 6.6.5.セレンディピティを最大化する。基本的なものを1つ変更すると、 プロポーザルでは、固定合計 c2 −c validators が表示されます。 各サブグループに c−1 validator 個。各ブロックではなく、 validator の非構造化再パーティション化が存在します パラチェーン間ではなく、パラチェーンのサブグループごとに、 各 validator は、一意の異なる名前に割り当てられます。 次のブロックのパラチェーン サブグループ。これは 任意の 2 つのブロック間の不変式を導出します。 パラチェーンの 2 つのペアには、2 つの validator が存在します。 パラチェーンの責任を交換しました。これを使用して可用性を絶対に保証することはできませんが、 (単一の validator は、たとえ 有益)、それでも一般的なケースを最適化できます。 このアプローチには複雑さが伴います。パラチェーンの追加には再組織化も必要になる validator セットの。さらに、validator の数はパラチェーンの数の 2 乗に関連付けられ、 最初は非常に小さく始まり、最終的には大きく成長します 速すぎて、約 50 パラチェーンを超えると維持できなくなります。 これらはいずれも根本的な問題ではありません。最初のケースでは、 validator セットの再編成は必ず実行する必要があります。 とにかく定期的に行われます。 validatorのサイズについて 設定が小さすぎる場合、複数の validator が割り当てられる可能性があります 同じパラチェーンに整数係数を適用します。 全体の合計は validator です。 6.6.4 で説明したハイパーキューブ ルーティングなどのマルチフェーズ ルーティング メカニズムは、次のようになります。 多数の validator の要件を軽減します チェーン数が多い場合。 6.7.パラチェーンの検証。 validator の主な目的 絆の強い俳優として、パラチェーンの ブロックは有効です。これには、状態遷移、含まれる外部トランザクション、実行が含まれますが、これらに限定されません。 入力キュー内の待機中のポストと最終状態 出力キューの。 プロセス自体は非常に簡単です。 validator が前のブロックを封印すると、それらは解放されます パラチェーンブロックの候補を提供する作業を開始する 次のコンセンサスラウンドの候補者。 最初に、validator は、パラチェーン コレーター (次に説明します) または 1 つのパラメーターを通じてパラチェーン ブロック候補を見つけます。 その共同validatorの。パラチェーンブロック候補データ ブロックのヘッダー、前のブロックのヘッダー、 含まれる外部入力データ (Ethereum および Bitcoin の場合、そのようなデータはトランザクションと呼ばれますが、原則として任意の目的のための任意のデータ構造が含まれる場合があります)、出力キュー データおよび状態遷移の妥当性を証明する内部データ (Ethereum の場合) これは、各トランザクションを実行するために必要なさまざまな状態/ストレージ トライ ノードになります)。 実験的証拠は、最近の Ethereum ブロックのこの完全なデータセットを示しています 最大でも数百 KiB です。 同時に、まだ完了していない場合は、validator が実行されます。 前のブロックの遷移に関する情報を、最初は前のブロックから取得しようとします。 validator 以降、すべての validator が署名しています データの可用性。 validator がそのような候補ブロックを受信すると、 次に、それをローカルで検証します。検証プロセスは、パラチェーン クラスの validator モジュール内に含まれています。 作成する必要があるコンセンサス重視のソフトウェア モジュール Polkadot の実装の場合 (原則的には C ABI を備えたライブラリでは、単一のライブラリで次のことが可能になります。 適切な実装間で共有される 「参照」実装が 1 つだけであることから安全性が低下します)。 このプロセスは前のブロックのヘッダーを取得し、最近合意されたリレーチェーンを通じてそのアイデンティティを検証します。 hash が記録されるブロック。親ヘッダーの有効性が確認されると、特定のパラチェーンが クラスの検証関数が呼び出される可能性があります。これは、多数のデータ フィールドを受け入れる単一の関数です (おおよそ 前に与えられたもの)、単純なブール値を返します ブロックの有効性を宣言します。 このような検証関数のほとんどは、最初に から直接派生できるヘッダーフィールド 親ブロック (例: 親 hash、番号)。フォロー中 これにより、内部データ構造が次のように設定されます。 トランザクションや投稿を処理するために必要です。 Ethereum のようなチェーンの場合、これは に必要なノードを含むデータベースを試してください。 トランザクションの完全な実行。他のチェーンタイプには、 その他のp修復メカニズム。 完了すると、イングレス投稿と外部トランザクション (または外部データが表すもの) は次のようになります。 チェーンの仕様に従って制定され、バランスがとれています。 (A 賢明なデフォルトは、すべての入力ポストを要求することかもしれません 外部トランザクションがサービスされる前に処理されますが、これはパラチェーンのロジックが決定する必要があります。) この制定により、一連の出力投稿は 作成され、これらが実際に一致することが検証されます 照合者の候補者。最後に、適切に設定された ヘッダーは候補者のヘッダーと照合されます。 完全に検証された候補ブロックでは、validator その後、ヘッダーの hash に投票し、必要な検証情報をすべてそのサブグループ内の co-validator に送信できます。 6.7.1.パラチェーンコレーター。パラチェーンの照合者は、マイナーのタスクの多くを実行する、拘束されていないオペレーターです。 現在のblockchainネットワーク上で。それらは具体的です 特定のパラチェーンに。操作するには、次のことを行う必要があります。 リレーチェーンと完全に同期されたものの両方を維持する パラチェーン。 「完全に同期」の正確な意味はパラチェーンのクラスによって異なりますが、パラチェーンの入力キューの現在の状態が常に含まれます。 Ethereum の場合、少なくともメンテナンスも必要です 最後の数ブロックのマークルツリー データベースですが、 ブルームを含む他のさまざまなデータ構造も含まれます アカウントの存在、家族情報、ログ記録用のフィルター ブロック番号の出力と逆引き参照テーブル。 2 つのチェーンの同期を維持するだけでなく、 トランザクションキューを維持し、適切に検証されたトランザクションを受け入れることによって、トランザクションを「フィッシング」する必要もあります パブリックネットワークから。キューとチェーンでは、 各ブロックで選択された validator の新しい候補ブロック (リレーチェーンが同期されているため、その ID がわかっている) を作成し、それらを 有効性の証明などのさまざまな付随情報。 ピアネットワーク。 その厄介な問題として、含まれる取引に関連するすべての手数料を徴収します。これに関してはさまざまな経済学が浮かんでいる アレンジメント。競争の激しい市場では、 担保者が余っているため、取引が行われる可能性があります。 インセンティブを与えるために手数料をパラチェーン validators と共有する 特定の照合者のブロックを含めること。 同様に、
POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 17 一部の照合者は、必要な手数料を徴収する場合もあります。 ブロックをより魅力的なものにするために支払われる validator秒。 この場合、自然な市場が形成されるはずです トランザクションはキューをスキップして高い手数料を支払う そして、より早くチェーンに組み込まれるようになります。 6.8.ネットワーキング。従来の blockchain でのネットワーキング Ethereum や Bitcoin などの要件はかなり単純です。 すべてのトランザクションとブロックは、単純な方向性のないゴシップでブロードキャストされます。同期は特に複雑です。 Ethereum を使用していますが、実際には、このロジックは いくつかの要求および応答メッセージ タイプを中心に解決するプロトコル自体ではなく、ピア戦略。 Ethereum は、devp2p プロトコルを使用して現在のプロトコルの提供を進めました。これにより、多くの機能が可能になりました。 サブプロトコルは単一のピア接続上で多重化されるため、同じピア オーバーレイを多数サポートします。 p2p プロトコルと同時に、Ethereum 部分 プロトコルはまだ比較的単純なままであり、p2p 議定書はしばらくの間、重要な作業が完了していないため、 QoS サポートなどの機能がありません。悲しいことに、よりユビキタスな「Web 3」プロトコルを作成したいという願望は主に 失敗しました。明示的に使用しているのはプロジェクトだけです Ethereum クラウドセールから資金を調達しました。 Polkadot の要件はかなり厳密です。完全に均一なネットワークではなく、Polkadot 数種類の参加者がおり、それぞれのピア構成や複数のネットワークに対して異なる要件があります。 参加者が会話する傾向がある「通り」 特定のデータ。これは、実質的により構造化されたネットワーク オーバーレイ、およびそれをサポートするプロトコルを意味します。 おそらく必要になるだろう。さらに、新しい種類の「チェーン」など、将来の追加を容易にする拡張性も備えています。 それら自体には新しいオーバーレイ構造が必要です。 ネットワーキングの仕組みについて徹底的に議論しながら、 プロトコルはこの文書の範囲外であるように見えるかもしれませんが、一部の要件分析は合理的です。できます ネットワーク参加者を大まかに 2 つのセットに分類します (リレーチェーン、パラチェーン) 3 つのサブセットのそれぞれ。できます また、各パラチェーン参加者は、 ではなく、自分たち同士で会話することに興味がある 他のパラチェーンの参加者: • リレーチェーン参加者: • バリデータ: P、それぞれのサブセット P[s] に分割 パラチェーン • 可用性保証者: A (これは、プロトコルの基本形式のバリデーターによって表される場合があります) • リレーチェーンクライアント: M (各メンバーのメンバーに注意してください) パラチェーン セットも M のメンバーになる傾向があります) • パラチェーン参加者: • パラチェーン コレーター: C[0]、C[1]、. 。 。 • パラチェーン漁師: F[0]、F[1]、 。 。 。 • パラチェーン クライアント: S[0]、S[1]、. 。 。 • パラチェーン ライトクライアント: L[0]、L[1]、. 。 。 一般に、私たちはコミュニケーションの特定のクラスに名前を付けます これらのセットのメンバー間で発生する傾向があります。 •P |あ <-> P |答え: の いっぱい セット の validators/保証人 しなければならない なる よくつながっている に コンセンサスを得る。 • P[s] <-> C[s] | P[s]: 特定のパラチェーン グループのメンバーとしての各 validator は噂話をする傾向があります 他の同様のメンバーおよび照合者とともに そのパラチェーンのブロック候補を発見して共有します。 • A <-> P[s] | C | A:各空室保証人 コンセンサスに敏感なクロスチェーンを収集する必要がある validator からのデータが割り当てられています。照合者 また、彼らの合意形成の可能性を最適化する可能性もあります。 可用性保証者に通知することでブロックします。 データを取得すると、データは次の企業に支払われます。 合意を促進するための他のそのような保証人。 • P[s] <-> A | P[s']: パラチェーン validators は 以前の validator セットまたは可用性保証者から追加の入力データを収集する必要があります。 • F[s] <-> P: 漁師は報告する際、 参加者に対するクレーム。 • M <-> M | P | A: 一般的なリレー チェーン クライアントは、validator と保証人からデータを支払います。 • S[s] <-> S[s] | P[s] | A: パラチェーンのクライアントは、validator/保証人からデータを支払います。 • L[s] <-> L[s] | S[s]: パラチェーン ライト クライアント 完全なクライアントからデータを分配します。 効率的な輸送メカニズムを確保するために、「フラット」 オーバーレイ ネットワーク (Ethereum の devp2p など) ノードは、そのノードの適合性を (恣意的にではなく) 区別しません。 同僚が適切である可能性は低いです。適度に拡張可能な ピアの選択と検出のメカニズムが必要になる可能性があります 積極的であると同時にプロトコルに含まれること 適切な種類のピアを確保するための先読みを計画する 偶然にも適切なタイミングで実行されました。 ピアメイクの正確な戦略は、参加者のクラスごとに異なります。 マルチチェーンの場合、照合者は継続的に実行する必要があります。 それに応じて選出された validator に再接続するか、 validator のサブセットとの継続的な契約が必要です validator が役に立たないほとんどの時間で切断されないようにするためです。照合者も当然、その情報を維持しようとします。 または可用性保証者へのより安定した接続 コンセンサスに敏感な情報を迅速に広めることを保証するために設定されています。 データ。 可用性の保証者は主に、 相互および validators への安定した接続 (コンセンサスおよびコンセンサスが重要なパラチェーン データの場合) 彼らは証明します)、そして一部の照合者(パラチェーンの場合)も証明します データ)と一部の漁師と完全な顧客(分散のため) 情報)。バリデーターは、他の validator、特に同じサブグループ内のvalidator を探す傾向があります。 パラチェーンブロック候補を提供できる照合者。 漁師、一般的なリレーチェーン、パラチェーンなど クライアントは通常、接続をオープンな状態に保つことを目的とします。 validator または保証人ですが、他の多くの同様のノード そうでなければ自分自身に。パラチェーンのライトクライアントも同様に、パラチェーンの完全なクライアントに接続することを目指します。 他のパラチェーンライトクライアントだけではないにしても。 6.8.1.ピアチャーンの問題。基本的なプロトコルの提案では、これらの各サブセットは、検証するために割り当てられた validator として各ブロックとともに常にランダムに変化します。 パラチェーン遷移はランダムに選択されます。これはできる 異種 (非ピア) ノードが問題となる可能性があります。 相互にデータを渡します。どちらかに頼らなければなりません 公平に分散され、適切に接続されたピア ネットワーク
POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 18 ホップ距離 (したがって最悪の場合の遅延) がネットワーク サイズの対数に応じてのみ増加するようにする (Kademlia のようなプロトコル [13] がここで役立つかもしれません)、または、次のことを行う必要があります。 ピアセットを維持するために必要な接続ネゴシエーションを実行できるようにするために、より長いブロック時間を導入します。 ノードの現在の通信ニーズを反映します。 どちらも優れた解決策ではありません: ブロック時間が長い ネットワークに強制的にアクセスすると、ネットワークが役に立たなくなる可能性があります。 特定のアプリケーションとチェーン。完全に公平であっても ネットワークに接続すると、かなりの無駄が発生します 関心のないノードにより拡張される帯域幅の減少 彼らにとって役に立たないデータを転送するため。 両方の方向がソリューションの一部を形成する可能性がありますが、 レイテンシーを最小限に抑えるために合理的な最適化を行うと、 これらのパラチェーンのボラティリティを制限するためです validator 一連のブロック間でのみメンバーシップを再割り当てするセット (例: 15 個のグループ、4 秒ごと) ブロック時間は、接続を 1 回につき 1 回だけ変更することを意味します。 分)、またはメンバーシップを段階的にローテーションすることによって(例:一度に 1 人のメンバーによって変更されます (例: 各パラチェーンに 15 validator が割り当てられている場合、完全に一意なパラチェーン間の間隔は平均で丸 1 分になります。 セット)。ピアのチャーンの量を制限し、有利なピア接続が適切に確立されるようにすることで、 パラチェーンの部分的な予測可能性を通じて進歩する セットを使用すると、各ノードが永続的に保持されるようにすることができます。 偶然の仲間選び。 6.8.2.効果的なネットワーク プロトコルへのパス。おそらく、 最も効果的かつ合理的な開発努力は、ローリングではなく既存のプロトコルの利用に焦点を当てます。 私たち自身の。 いくつかのピアツーピアベースプロトコルが存在します。 Ethereum 独自の devp2p を使用または拡張する場合があります [22]、IPFS の libp2p [1]、GNU の GNUnet [4]。これらのプロトコルとその構築との関連性を完全にレビューします。 特定の構造保証、動的ピアステアリング、および拡張可能なサブプロトコルをサポートするモジュラーピアネットワーク この文書の範囲をはるかに超えていますが、 Polkadot の実装における重要なステップ。 7. プロトコルの実用性 7.1.インターチェーントランザクション支払い。素晴らしい一方で、 Ethereum のガスのような総合的な計算リソース アカウンティング フレームワークの必要性をなくすことで、かなりの自由とシンプルさが得られますが、これは重要な疑問を引き起こします。ガスがなければ、パラチェーンはどのように機能するのでしょうか。 別のパラチェーンが強制的に計算を実行するのを避けますか?トランザクション後の入力キューに依存することもできますが、 あるチェーンが別のチェーンにスパム送信するのを防ぐためのバッファー トランザクション データの場合、トランザクション処理のスパムを防止するための同等のメカニズムがプロトコルによって提供されることはありません。 これはより高いレベルに委ねられる問題です。チェーン以来 受信メッセージに任意のセマンティクスを自由に付加できる トランザクション後のデータを使用すると、計算が確実に行われるようになります。 開始前に料金を支払う必要があります。同じような流れで、 Ethereum Serenity が支持するモデル、想像できます パラチェーン内の「侵入」契約により、 validator と引き換えに支払いが保証されます。 特定の量の処理リソースの提供。 これらのリソースはガスのようなもので測定される可能性があります。 しかし、主観的な実行時間や Bitcoin のような定額料金モデルなど、まったく新しいモデルである可能性もあります。 オフチェーンの呼び出し元が利用できるとはすぐには想定できないため、これ自体はあまり役に立ちません。 侵入によって認識されるあらゆる価値メカニズム 契約。ただし、ソースチェーン内に二次的な「ブレイクアウト」コントラクトが存在することは想像できます。 2 つの契約は共に橋を形成し、お互いを認識し、 価値の同等性を提供します。 (ステーキング-tokens、利用可能 それぞれを国際収支の決済に使用できます。) 別のそのようなチェーンを呼び出すことはプロキシを意味します この橋を通って、 チェーン間での価値の移転を交渉して、 宛先パラチェーンで必要な計算リソースの料金を支払います。 7.2.追加 チェーン。その間 の 追加 の ある パラチェーンは比較的安価な操作ですが、無料ではありません。 パラチェーンが増えると、パラチェーンあたりの validator が少なくなります そして最終的には、それぞれが 平均債券の減少。パラチェーンを攻撃するための強制コストが小さいという問題は、次のように軽減されます。 漁師の皆さん、validator セットの成長は本質的に、 基礎となるコンセンサスの仕組みにより、レイテンシが高くなるそーだ。さらに各パラチェーン validators を悲しませる可能性があります。 負担の大きい検証アルゴリズム。 したがって、validator の「価格」が発生することになります。 および/または利害関係者コミュニティが、 新しいパラチェーンの追加。このチェーン市場は、 おそらく次のいずれかが追加されているのがわかります。 • 一部となる可能性が高い(staking tokens のロックアップまたはバーンアウトに関して)正味拠出金の支払いがゼロのチェーン(コンソーシアム チェーンなど) Doge チェーン、アプリ固有のチェーン)。 • ネットワークに本質的な価値を提供するチェーン 特定の機能を追加するのが難しい 他の場所(機密性、内部拡張性、サービス提携など)を取得するため。 基本的に、利害関係者のコミュニティは次のことを行う必要があります。 経済的または経済的に子チェーンを追加するよう奨励される リレーに機能的なチェーンを追加したいという願望を通じて。 新しいチェーンが追加されると、非常に大きな影響を受けることが想定されます。 削除の通知期間が短いため、新しいチェーンを使用できます。 妥協するリスクなしに実験できる 中長期的な価値提案。 8. 結論 私たちは、著者が取ることができる方向性を概説しました。 特定の既存のプロトコルとの下位互換性がある可能性のある、スケーラブルな異種マルチチェーン プロトコル blockchain ネットワーク。このようなプロトコルの下では、参加者は 賢明な自己利益に基づいて、既存ユーザーに通常のコストをかけずに、非常に自由な方法で拡張できるシステム全体を作成します。 標準の blockchain デザインから来ています。私たちは与えました 必要となるアーキテクチャの大まかな概要 参加者の性質、経済的インセンティブ そして彼らが関与しなければならないプロセス。私たちは持っています 基本設計を特定し、その長所について議論し、 制限;したがって、さらなる方向性があります。 これらの制限が緩和され、完全にスケーラブルな blockchain ソリューションに向けてさらに前進する可能性があります。POLKADOT: 異種マルチチェーン フレームワークのビジョン ドラフト 1 19 8.1.不足している資料と未解決の質問。プロトコルの実装が異なる場合、ネットワークの分岐が常に発生する可能性があります。そんな状態からの回復 例外的な状況については議論されなかった。ネットワークには必然的にゼロ以外のファイナライゼーション期間があると仮定すると、 リレーチェーンの分岐から回復することは大きな問題ではありませんが、慎重に統合する必要があります。 コンセンサスプロトコル。 保証金の没収と逆に報酬の提供は、 深くは研究されていません。現時点では報酬を想定しています 勝者総取りの原則に基づいて提供されます。これは当てはまらない場合があります。 漁師に最適な奨励モデルを提供する。短期間のコミットと公開のプロセスにより、多くの漁師が許可されるでしょう。 賞品をより公平に分配して賞品を受け取るため、 ただし、このプロセスにより、追加のレイテンシーが発生する可能性があります。 不正行為の発見。 8.2.謝辞。皆様、本当にありがとうございました これを漠然と理解するのに協力してくれた校正者 存在感のある形状。 特にピーター・ツァバン、ビョルン ワーグナー、ケン・カプラー、ロバート・ハーバマイヤー、ヴィタリック・ブテリン、レト・トリンクラー、ジャック・ピーターソン。 皆さんのおかげで アイデアや始まりに貢献した人々 その中で、マレク・コテヴィッチとアーロン・ブキャナンは特に言及に値する。そして、助けてくれた他の皆さんにも感謝します 途中で。すべての間違いは私自身のものです。 の初期研究を含むこの研究の一部 コンセンサスアルゴリズムの一部は英国によって資金提供されました。 Innovate UK プログラムに基づく政府。
세부 프로토콜
프로토콜은 대략 세 가지로 나눌 수 있습니다. 부분: 합의 메커니즘, 파라체인 인터페이스 그리고 인터체인 트랜잭션 라우팅. 6.1. 릴레이 체인 운영. 는 릴레이 체인 의지 아마도 Ethereum와 대체로 유사한 체인일 것입니다. 상태는 계정에 주소를 매핑하는 상태 기반입니다. 정보, 주로 잔액 및 (재생 방지를 위해) 거래 카운터. 여기에 계정을 배치하면 한 가지 목적이 달성됩니다. 즉, ID가 소유한 계정을 제공하는 것입니다. 시스템에 어느 정도의 지분이 있는지.7 하지만 주목할만한 차이점이 있습니다. • 계약은 트랜잭션을 통해 전개될 수 없습니다. 릴레이 체인의 애플리케이션 기능을 피하려는 욕구에 따라 계약의 공개 배포를 지원합니다. • 컴퓨팅 리소스 사용량(“가스”)은 계산되지 않습니다. 공개적으로 사용할 수 있는 유일한 기능이기 때문에 가스 회계의 근거가 수정될 것입니다. 더 이상 보유하지 않습니다. 따라서 정액 요금이 적용됩니다. 모든 경우에 더 많은 성능을 제공합니다. 수행해야 할 수 있는 동적 코드 실행 그리고 더 간단한 거래 형식. • 자동 실행 및 네트워크 메시지 출력을 허용하는 나열된 계약에 대해 특수 기능이 지원됩니다. 릴레이 체인에 VM이 있고 VM이 있는 경우 EVM을 기반으로 하며 최대한의 단순성을 보장하기 위해 여러 가지 수정 사항이 있을 것입니다. 아마도 다수의 내장 계약이 있습니다(다음의 계약과 유사). 플랫폼별 허용을 위해 Ethereum의 주소 1-4 합의 계약을 포함하여 관리해야 할 의무, validator 계약 및 파라체인 계약. EVM이 아닌 경우 WebAssembly 2 백엔드가 가장 가능성 있는 대안입니다. 이 경우 전반적인 구조는 비슷하지만 그럴 필요는 없습니다. Wasm이 실행 가능한 목표가 되는 내장 계약 미숙한 언어보다는 범용 언어를 위해 EVM에 대한 언어가 제한되어 있습니다. 현재 Ethereum 프로토콜에서 다른 가능한 편차가 있을 수 있습니다. 동일한 블록 내에서 충돌하지 않는 트랜잭션의 병렬 실행을 허용하는 트랜잭션 영수증 형식, Serenity 시리즈 변경 사항에 대해 제안된 대로입니다. 가능성은 낮지만 세레니티와 같은 것이 가능합니다. "순수한" 체인을 릴레이 체인으로 배포하여 staking token과 같은 것을 관리하기 위한 특정 계약 그것을 근본적인 부분으로 만드는 것이 아니라 균형을 유지하는 것입니다. 체인의 프로토콜. 현재로서는 그럴 가능성이 없다고 생각합니다. 충분히 훌륭한 프로토콜 단순화를 제공할 것입니다. 추가적인 복잡성과 불확실성을 감수할 가치가 있습니다. 그것을 개발하는 중. 7특정 보유자가 시스템의 전반적인 보안에 대해 책임을 지는 금액을 나타내는 수단으로 이러한 스테이크 계정은 필연적으로 경제적 가치를 인코딩합니다. 그러나 그러한 값을 사용할 의도는 없으므로 이해해야 합니다. 실제 상품 및 서비스와 교환할 목적으로 어떤 방식으로든 token은(는) 다음과 유사하지 않다는 점에 유의해야 합니다. 화폐와 마찬가지로 릴레이 체인은 애플리케이션에 관한 허무주의적 철학을 유지합니다.POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 10 합의 메커니즘, validator 세트, 검증 메커니즘 및 파라체인을 관리하는 데 필요한 여러 가지 작은 기능이 있습니다. 이것들 모놀리식 프로토콜 하에서 함께 구현될 수 있습니다. 그러나 모듈성을 보장한다는 이유로 이를 릴레이 체인의 "계약"이라고 설명합니다. 이것은 (의미에서) 객체라는 의미로 간주됩니다. 객체 지향 프로그래밍)은 릴레이체인의 합의 메커니즘에 의해 관리되지만 반드시 그런 것은 아닙니다. EVM과 유사한 opcode의 프로그램으로 정의되거나 심지어는 계정 시스템. 6.2. 스테이킹 계약. 이 계약은 validator 세트를 유지합니다. 다음을 관리합니다. • 현재 validator 계정은 무엇입니까? • 짧게는 validator이 될 수 있습니다. 통지; • 어떤 계정이 지명 지분을 배치했는지 validator; • staking 볼륨, 허용되는 지급률 및 주소, 단기(세션) ID를 포함한 각각의 속성. 계정이 되고자 하는 욕구를 등록할 수 있습니다. 보세 validator(요구 사항과 함께), 일부 신원을 지명하고 기존 보세 validator이 이 상태를 종료하려는 의사를 등록합니다. 그것은 또한 검증 및 정규화 메커니즘을 위한 기계 자체를 포함합니다. 6.2.1. 지분-token 유동성. 일반적으로 다음을 수행하는 것이 바람직합니다. 총 staking token을 최대한 많이 확보하세요. 이후 네트워크 유지 관리 작업에 참여 이는 네트워크 보안을 staking token의 전체 "시가 총액"과 직접적으로 연결합니다. 이것은 쉽게 할 수 있습니다 통화를 부풀리고 validators로 참여하는 사람들에게 수익금을 나눠줌으로써 인센티브를 받습니다. 그러나 그렇게 하면 문제가 발생합니다. token 축소 처벌로 스테이킹 계약에 갇혀 있는데 어떻게 상당 부분이 충분히 남을 수 있겠습니까? 가격 발견을 허용하기 위해 액체? 이에 대한 한 가지 대답은 기본 스테이킹된 token에 대체 가능한 token을 확보하여 간단한 파생 계약을 허용하는 것입니다. 이는 무신뢰 방식으로 마련하기가 어렵습니다. 더욱이 이러한 파생 상품은 다른 유로존 정부 채권이 대체 불가능하다는 것과 같은 이유로 동등하게 취급될 수 없습니다. 기초 자산이 실패하고 무가치하다. 유로존 정부와 관련하여 다음과 같은 일이 발생할 수 있습니다. 기본값. validator 스테이킹된 token을 사용하면 validator이(가) 악의적으로 행동하고 처벌을 받습니다. 우리의 교리에 따라 우리는 가장 간단한 솔루션을 선택합니다. 모든 token이 스테이킹되는 것은 아닙니다. 이것은 다음을 의미합니다 token의 일부(아마도 20%)는 강제로 유동 상태로 유지됩니다. 이는 보안 관점에서 불완전하지만 보안 측면에서 근본적인 차이를 만들 가능성은 없습니다. 네트워크 보안; 채권 몰수로 인한 배상금의 80%는 여전히 이루어질 수 있습니다. 100% staking의 "완벽한 사례"와 비교됩니다. 스테이킹된 token 사이의 비율은 역경매 메커니즘을 통해 상당히 간단하게 타겟팅할 수 있습니다. 본질적으로, validator가 되는 데 관심이 있는 token 보유자입니다. 각각 staking 계약서에 다음과 같은 제안을 게시할 것입니다. 그들이 받아야 할 최소 지급률 부분. 각 세션이 시작될 때(세션은 정기적으로, 아마도 한 시간에 한 번 정도 발생함) validator 슬롯은 각 원하는 대로 채워집니다. validator의 지분 및 지급률. 하나의 가능한 알고리즘 왜냐하면 이것은 가장 낮은 제안을 받은 사람들을 택하는 것이기 때문입니다. 목표로 삼은 총 지분보다 높지 않은 지분을 나타냅니다. 슬롯 수로 나눈 값이며 그 양의 절반보다 낮을 수 없습니다. 슬롯을 채울 수 없는 경우, 하한은 만족시키기 위해 어떤 요인에 의해 반복적으로 감소될 수 있습니다. 6.2.2. 지명. 무신뢰 지명 가능 staking token을 활성 validator에 전달하여 validator의 의무에 대한 책임입니다. 작품 추천 승인 투표 시스템을 통해. 각 후보자 후보는 staking 계약에 지침을 게시할 수 있습니다. 하나 이상의 validator 신원을 표현하는 것 그들은 자신의 유대를 맡길 준비가 되어 있습니다. 각 세션마다 지명자의 결속력이 분산됩니다. 하나 이상의 validator으로 표시됩니다. 분산 알고리즘은 등가 총계의 validator 세트를 최적화합니다. 채권. 지명자의 채권은 validator a의 실질적인 책임 하에 있게 됩니다.관심을 얻거나 고통을 겪을 수도 있습니다. 그에 따라 처벌이 감소됩니다. 6.2.3. 채권 압수/소각. 특정 validator 행동으로 인해 채권이 징벌적으로 감소됩니다. 만약에 채권이 허용 가능한 최소 금액 이하로 감소되었습니다. 세션이 조기 종료되었으며 다른 세션이 시작되었습니다. 처벌 가능한 validator 비행의 대략적인 목록은 다음과 같습니다. • 제공할 수 없는 파라체인 그룹의 일부임 파라체인 블록의 유효성에 대한 합의; • 무효의 유효성에 대해 적극적으로 서명합니다. 파라체인 블록; • 이전에는 송신 페이로드를 제공할 수 없음 사용 가능한 것으로 투표되었습니다. • 합의 과정 중 활동이 없습니다. • 경쟁 포크에서 릴레이 체인 블록을 검증합니다. 잘못된 행동의 일부 사례는 네트워크의 무결성을 위협합니다(예: 유효하지 않은 파라체인 블록에 서명하고 포크의 여러 측면을 검증하는 등). 따라서 채권의 전체 감소를 통해 효과적인 추방이 발생합니다. 에서 기타 덜 심각한 경우(예: 합의에 대한 비활동성) 프로세스) 또는 비난을 정확하게 할당할 수 없는 경우(비효과적인 그룹의 일부임), 작은 부분 대신 채권의 일부가 벌금으로 부과될 수 있습니다. 후자의 경우, 이는 하위 그룹 이탈과 잘 작동하여 악의적인 노드는 부수적으로 손상된 자비로운 노드보다 훨씬 더 많은 손실을 입습니다. 어떤 경우에는(예: 다중 포크 검증 및 유효하지 않은 경우) 하위 블록 서명) validators는 지속적인 검증으로 인해 서로의 잘못된 행동을 쉽게 감지할 수 없습니다. 각 파라체인 블록을 만드는 것은 너무 힘든 작업이 될 것입니다. 여기 외부 당사자의 지지를 얻어야 한다. 그러한 오작동을 확인하고 보고하기 위한 검증 프로세스. 당사자들은 그러한 활동을 보고한 대가로 보상을 받습니다. 그들의 "어부"라는 용어는 가능성이 없다는 데서 유래합니다. 그런 보상. 이러한 경우는 일반적으로 매우 심각하므로 압수된 채권으로 보상금을 쉽게 지불할 수 있다고 생각합니다. 일반적으로 우리는 균형 잡힌 연소를 선호합니다. (즉, 아무것도 아닌 것으로 축소) 도매 재분배를 시도하고 있습니다. 이는 다음과 같은 효과가 있습니다.
POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 11 token의 전체 가치를 높여서 특정 네트워크보다는 일반적으로 어느 정도 네트워크를 발견에 참여한 당사자. 이는 주로 안전을 위한 것입니다. 메커니즘: 관련된 많은 양은 극단적이고 심각한 행동 인센티브로 이어질 수 있습니다. 단일 대상에게 부여됩니다. 일반적으로 보상은 네트워크에 대한 검증을 가치 있게 만들 만큼 충분히 크지만, 네트워크에 대한 비용을 상쇄할 만큼 크지는 않은 것이 중요합니다. 재정이 좋고 조직이 잘 조직된 "산업 수준"의 범죄 잘못된 행동을 강요하기 위해 불운한 validator에 대한 해킹 공격입니다. 이런 식으로 청구된 금액은 일반적으로 0이 되어야 합니다. 잘못된 validator의 직접 채권보다 큽니다. 잘못된 행동을 하고 현상금을 위해 자신을 보고하는 비뚤어진 인센티브가 발생합니다. 이는 명시적으로 해결될 수 있습니다. 최소한의 직접 채권 요건을 통해 validator 또는 예치된 채권이 거의 없는 validator이 큰 인센티브가 없다는 것을 지명자에게 교육함으로써 암묵적으로 잘 행동하기 위해서. 6.3. 파라체인 레지스트리. 각 파라체인은 다음과 같이 정의됩니다. 이 레지스트리. 데이터베이스와 유사한 상대적으로 간단한 구성이며 정적 정보와 동적 정보를 모두 보유합니다. 각 체인. 정적 정보에는 체인 인덱스(간단한 정수), 검증 프로토콜 ID와 함께 다양한 클래스를 구별하는 수단 올바른 검증 알고리즘이 될 수 있도록 파라체인 유효한 후보자를 제시하기 위해 위임된 validators에 의해 운영됩니다. 초기 개념 증명은 배치에 중점을 둡니다. 새로운 검증 알고리즘을 클라이언트 자체에 적용하여 매번 프로토콜의 하드포크를 효과적으로 요구합니다. 체인 클래스가 추가되었습니다. 하지만 궁극적으로, 검증 알고리즘을 지정하는 것이 가능할 수도 있습니다. 고객이 만족할 만큼 엄격하고 효율적인 방법입니다. 별도의 조치 없이 새로운 파라체인과 효과적으로 작업할 수 있습니다. 하드포크. 이에 대한 한 가지 가능한 방법은 다음을 지정하는 것입니다. 잘 확립된 파라체인 검증 알고리즘, WebAssembly와 같이 기본적으로 컴파일되고 플랫폼 중립적인 언어입니다. 결정하기 위해서는 추가적인 연구가 필요하다 이것이 정말로 실현 가능한지 여부, 그러나 만약 그렇다면 이를 통해 하드포크를 추방하는 엄청난 이점을 얻을 수 있습니다. 영원히. 동적 정보에는 다음과 같은 글로벌 합의가 있어야 하는 트랜잭션 라우팅 시스템의 측면이 포함됩니다. 파라체인의 수신 대기열로 사용됩니다(섹션 6.6에 설명되어 있음). 레지스트리에는 파라체인만 추가할 수 있습니다. 전체 국민투표를 통해; 이건 관리할 수 있을 것 같아 내부적으로는 배치되지만 외부에 배치될 가능성이 더 높습니다. 재사용을 촉진하기 위한 국민투표 계약 보다 일반적인 거버넌스 구성 요소. 매개변수는 투표 요구 사항(예: 필요한 정족수, 과반수 필수) 추가 체인 및 기타 등록을 위해 덜 공식적인 시스템 업그레이드는 "마스터"에서 설정됩니다. 헌법”을 따르지만 상당히 전통적인 방식을 따를 가능성이 높습니다. 적어도 처음에는 경로입니다. 정확한 공식은 나오지 않았습니다 현재 작업의 범위, 예를 들어 전체 시스템의 3분의 1 이상을 통과하려면 2/3의 절대 다수가 통과해야 합니다. 스테이크에 대한 긍정적인 투표는 합리적인 출발점이 될 수 있습니다. 추가 작업에는 파라체인의 정지 및 제거가 포함됩니다. 정지는 결코 발생하지 않을 것입니다. 그러나 이는 최소한의 안전 장치로 설계되었습니다. 파라체인의 검증 시스템에는 다루기 힘든 문제가 있습니다. 가장 확실한 사례는 validator이 동의할 수 없게 만드는 구현 간의 합의에 중요한 차이점이 필요합니다. 유효성 또는 차단. 검증인은 다음을 사용하는 것이 좋습니다. 여러 클라이언트 구현을 수행할 수 있도록 채권을 몰수하기 전에 그러한 문제를 발견하는 것입니다. 정지는 긴급조치이므로, 오히려 역동적인 validator-투표의 후원으로 국민투표보다 복원은 둘 다 가능할 것입니다. validators 또는 국민 투표에서. 파라체인을 완전히 제거하는 것은 오직 국민투표 이후에는 질서 있는 전환을 허용하는 상당한 유예 기간 독립형 체인이 되거나 다른 체인의 일부가 되거나 합의 시스템. 유예 기간은 다음과 같습니다. 달의 순서이며 다른 순서로 파라체인 레지스트리에 퍼체인 기반으로 설정될 가능성이 높습니다. 파라체인은 다음에 따라 다양한 유예 기간을 누릴 수 있습니다. 그들의 필요. 6.4. 릴레이 블록 밀봉. 씰링은 본질적으로 다음을 의미합니다. 정규화 과정; 즉, 기본 데이터 변환하는 것원본을 근본적으로 독특하고 의미 있는 것으로 매핑합니다. PoW 체인 하에서, 봉인은 사실상 채굴과 동의어입니다. 우리의 경우, 여기에는 validators의 유효성, 가용성 및 정식성에 대한 서명된 진술 수집이 포함됩니다. 특정 릴레이 체인 블록과 파라체인 블록 그것은 나타냅니다. 기본 BFT 합의 알고리즘의 메커니즘은 현재 작업의 범위를 벗어납니다. 우리는 대신에 다음을 가정하는 기본 요소를 사용하여 설명합니다. 합의를 창출하는 상태 기계. 결국 우리는 기대한다 수많은 유망한 BFT 합의에서 영감을 얻습니다. 핵심 알고리즘; Tangaora [9] (BFT 변종) Raft [16]), Tendermint [11] 및 HoneyBadgerBFT [14]. 알고리즘은 여러 파라체인에 대해 병렬로 합의에 도달해야 하므로 일반적인 알고리즘과 다릅니다. blockchain 합의 메커니즘. 우리는 한 번 가정 합의에 도달하면 합의를 기록할 수 있습니다. 어느 누구라도 제공할 수 있는 반박할 수 없는 증거로 그것에 참가자. 우리는 또한 잘못된 행동을 가정합니다 프로토콜 내에서 일반적으로 작은 규모로 축소될 수 있습니다. 최소화하기 위해 잘못된 행동을 하는 참가자가 포함된 그룹 처벌을 내릴 때의 부수적 피해.8 서명된 진술의 형태를 취하는 증명은 릴레이 체인 블록의 헤더에 함께 배치됩니다. 특히 릴레이 체인의 statetrie 루트 및 transaction-trie 루트와 같은 특정 필드를 사용합니다. 는 밀봉 프로세스 걸립니다 장소 아래 에 싱글 합의 생성 메커니즘 주소 지정 둘 다 는 릴레이체인의 블록과 파라체인의 블록으로 릴레이 콘텐츠의 일부: 파라체인은 하위 그룹에 의해 별도로 "커밋"된 다음 대조되지 않습니다. 나중에. 이로 인해 릴레이체인의 프로세스가 더 복잡해지지만 단일 단계에서 전체 시스템의 합의를 완료할 수 있어 대기 시간이 최소화되고 허용됩니다. 매우 복잡한 데이터 가용성 요구 사항에 대해 아래 라우팅 프로세스에 도움이 됩니다. 8Tendermint BFT과 같은 기존 PoS 기반 BFT 합의 체계와 원본 Slasher는 이러한 주장을 충족합니다.
POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 12 각 참가자의 합의 기계 상태는 다음과 같습니다. 간단한(2차원) 테이블로 모델링됩니다. 각 참가자(validator)는 다음 형식의 정보 세트를 가지고 있습니다. 각 파라체인 블록 후보와 릴레이체인 블록 후보에 관한 다른 참가자의 서명된 진술("투표")입니다. 정보 세트는 2개입니다. 데이터: 가용성: 있음 이 validator 가지고 있다 출구 이 블록의 거래 게시물 정보 그들은 다음 블록에서 파라체인 후보를 적절하게 검증할 수 있습니까? 그들은 투표할 수 있습니다 1(알려짐) 또는 0(아직 알려지지 않음)입니다. 일단 그들은 1번 투표를 하면 그들은 비슷한 투표를 하기로 약속합니다. 이 과정의 나머지 부분. 그렇지 않은 나중에 투표 존중하는 것은 처벌의 근거가 됩니다. 유효성: 파라체인 블록이 유효하며 모두 유효합니다. 외부 참조 데이터(예: 거래) 가능합니까? 이는 투표 중인 파라체인에 할당된 validator에만 관련됩니다. 1(유효), -1(무효) 또는 0으로 투표할 수 있습니다. (아직 알려지지 않음). 0이 아닌 투표를 하면 나머지 투표에서도 이런 방식으로 투표하기로 약속했습니다. 과정. 이를 존중하지 않는 나중에 투표 처벌사유가 됩니다. 모든 validator은 투표를 제출해야 합니다. 위의 규칙에 따라 투표를 다시 제출할 수 있습니다. 의 진행 합의는 병렬로 발생하는 각 파라체인에 대한 여러 표준 BFT 합의 알고리즘으로 모델링될 수 있습니다. 이는 상대적으로 잠재적으로 방해를 받기 때문에 소수의 악의적인 행위자가 집중되어 있음 단일 파라체인 그룹에 대한 전반적인 합의가 존재합니다. 백스톱을 구축하여 최악의 시나리오를 제한합니다. 단지 하나 이상의 보이드 파라체인 블록에 대한 교착상태(그리고 책임자에 대한 일련의 처벌). 개별 블록의 유효성에 대한 기본 규칙 (전체적으로 validator의 전체 세트가 독특한 파라체인 후보가 되는 것에 대한 합의 표준 릴레이에서 참조됨): • validator의 최소 2/3가 긍정적으로 투표해야 하며 누구도 부정적으로 투표하지 않아야 합니다. • 송신 대기열 정보의 가용성에 대해 3분의 1 이상의 validator이 긍정적으로 투표해야 합니다. 타당성에 대해 적어도 하나의 긍정적인 투표와 적어도 하나의 부정적인 투표가 있는 경우 예외 조건이 생성됩니다. validator 전체 집합이 투표를 통해 결정해야 합니다. 악의적인 당사자가 있거나 우발적인 사고가 발생한 경우 포크. 유효, 무효 외에 세 번째 종류의 투표 허용되며 이는 둘 다에 투표하는 것과 같습니다. 즉, 노드는 서로 상충되는 의견을 가지고 있습니다. 이는 다음으로 인해 발생할 수 있습니다. 여러 구현을 실행하는 노드 소유자 동의하지 않음은 프로토콜에 모호성이 있을 수 있음을 나타냅니다. 모든 투표가 전체 validator 세트에서 계산된 후, 패배한 의견은 최소한 어느 정도 작은 비율을 차지합니다( 매개변수화되어야 합니다. 많아야 절반, 어쩌면 훨씬 적을 수도 있음) 승리한 의견의 득표수로 간주됩니다. 우발적인 파라체인 포크가 되어 파라체인은 합의 프로세스에서 자동으로 중단됩니다. 그렇지 않으면 악의적인 행위로 간주하여 처벌합니다. 반대 의견에 투표한 소수. 결론은 다음을 입증하는 일련의 서명입니다. 정규성. 그러면 릴레이 체인 블록이 봉인될 수 있습니다. 그리고 다음 블록을 봉인하는 과정이 시작되었습니다. 6.5. 릴레이 블록 밀봉 개선. 동안 이 밀봉 방법은 시스템 작동에 대한 강력한 보장을 제공하지만 특별히 확장이 잘 되지는 않습니다. 모든 파라체인의 핵심 정보에는 고유한 정보가 있어야 하기 때문에 전체 validator의 1/3 이상에서 가용성이 보장됩니다. 이는 모든 validator의 책임 범위가 더 많은 체인이 추가될수록 증가합니다. 개방형 합의 네트워크 내에서 데이터 가용성을 유지하는 동안 본질적으로 해결되지 않은 문제이므로 validator 노드에 발생하는 오버헤드를 완화하는 방법이 있습니다. 하나의 간단한 해결책은 validators가 어깨를 짊어져야 한다는 것을 깨닫는 것입니다. 데이터 가용성에 대한 책임이 있기 때문에 실제로 데이터 자체를 저장, 전달 또는 복제할 필요는 없습니다. 2차 데이터 사일로, 아마도 관련이 있거나 동일) 이 데이터를 수집하는 대조자는 지불 이자/소득의 일부를 제공하는 validator을 통해 가용성을 보장하는 작업입니다. 그러나 이렇게 하면 중간 정도의 확장성을 얻을 수는 있지만 여전히 근본적인 문제에는 도움이 되지 않습니다. 이후 더 많은 체인을 추가하려면 일반적으로 추가 validator이 필요하며 지속적인 네트워크 리소스 소비(특히 대역폭 측면에서)는 다음의 제곱에 따라 증가합니다. 는체인은 장기적으로 보호할 수 없는 자산입니다. 결국 우리는 계속해서 머리를 강타하게 될 것입니다. 다음과 같은 근본적인 한계에 반대합니다. 안전한 것으로 간주되는 합의 네트워크, 현재 진행 중인 대역폭 요구 사항은 총계 수준입니다. validators번 총 입력 정보입니다. 이는 다음으로 인해 발생합니다. 신뢰할 수 없는 네트워크가 여러 노드에 걸쳐 데이터 저장 작업을 적절하게 분배할 수 없음 처리라는 탁월한 배포 작업을 제외하고. 6.5.1. 지연 시간을 소개합니다. 이것을 부드럽게 하는 한 가지 방법 즉각성의 개념을 완화하는 것이 규칙입니다. 즉시가 아닌 최종적으로만 가용성에 대해 33%+1 validators 투표를 요구함으로써 우리는 기하급수적인 데이터 전파를 더 잘 활용하고 데이터 교환의 최대치를 균등화하는 데 도움을 줄 수 있습니다. 합리적인 평등(증명되지는 않았지만) 다음과 같을 수 있습니다: (1) 대기 시간 = 참가자 × 체인 현재 모델에서는 시스템 규모가 확장됩니다. 처리가 이루어지도록 체인 수를 확인합니다. 분산; 각 체인에는 최소한 하나의 validator이 필요하며 가용성 증명을 상수로 수정합니다. validator의 비율, 참가자도 비슷하게 증가합니다. 체인 수와 함께. 우리는 다음과 같이 끝납니다: (2) 대기 시간 = 크기2 이는 시스템이 성장함에 따라 필요한 대역폭과 가용성이 전체 시스템에 알려질 때까지의 대기 시간을 의미합니다. 네트워크는 숫자로 특징지어질 수도 있습니다. 최종 이전의 블록 수는 제곱에 따라 증가합니다. 이것은 상당한 성장 요인이며 주목할만한 장애물이 되어 우리를 "비평탄한" 패러다임으로 몰아넣을 수 있습니다. 예를 들어 여러 "Polkadotes"를 계층 구조로 구성하는 등 릴레이체인 트리를 통해 포스트의 다단계 라우팅을 위한 것입니다.
POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 13 6.5.2. 대중 참여. 또 하나의 가능한 방향 과정을 통해 대중의 참여를 유도하는 것입니다. 마이크로 컴플레인 시스템. 어부들과 비슷해요. 주장하는 validator을 경찰의 외부 당사자가 될 수 있습니다. 가용성. 그들의 임무는 그러한 가용성을 입증할 수 없는 것처럼 보이는 사람을 찾는 것입니다. 그렇게 함으로써 그들은 다른 validator에게 소소한 불만사항을 제기할 수 있습니다. PoW 또는 시빌 공격을 완화하기 위해 스테이크 채권을 사용할 수 있습니다. 이는 시스템을 거의 쓸모 없게 만듭니다. 6.5.3. 가용성 보증인. 최종 경로는 두 번째 결합된 validator 세트를 "가용성"으로 지정 보증인”. 이는 일반 validator과 마찬가지로 결합되며 동일한 세트에서 가져올 수도 있습니다. (그렇다면 적어도 세션당 장기간에 걸쳐 선택될 것입니다.) 일반 validator과 달리 파라체인 간에 전환하는 것이 아니라 오히려 모든 중요한 인터체인 데이터의 가용성을 증명하기 위해 단일 그룹을 구성합니다. 이는 참가자와 체인 간의 동등성을 완화할 수 있다는 장점이 있습니다. 본질적으로 체인은 다음과 같은 작업을 수행할 수 있습니다. (원래 체인 validator 세트와 함께) 성장하는 반면 참가자, 특히 데이터 가용성 증거에 참여하는 참가자는 최소한의 하위 선형 상태를 유지할 수 있습니다. 그리고 아마도 일정할 것이다. 6.5.4. 대조자 기본 설정. 이것의 중요한 측면 중 하나 시스템은 건전한 선택이 가능하도록 보장하는 것입니다. 특정 파라체인에서 블록을 생성하는 대조자. 만약 단일 대조자가 파라체인을 지배한 후 일부 공격 부족할 가능성이 높기 때문에 더욱 실현 가능해집니다. 외부 데이터의 가용성은 덜 명확합니다. 한 가지 옵션은 인공적으로 파라체인 블록에 가중치를 부여하는 것입니다. 다양한 대조자를 선호하기 위한 의사 무작위 메커니즘. 첫 번째 경우에는 다음이 필요합니다. validator이 선호하는 합의 메커니즘의 일부로 "무거운" 것으로 결정된 파라체인 블록 후보. 마찬가지로, 우리는 validators가 다음을 시도하도록 장려해야 합니다. 그들이 찾을 수 있는 가장 무거운 블록을 제안합니다. 후보자의 가중치에 비례하여 보상의 일부를 만들어 수행됩니다. 대조자에게 합리적인 공정한 대우를 보장하기 위해 자신의 후보가 당선자로 선택될 확률 합의된 후보자, 우리는 특정 가중치를 만듭니다. 파라체인 블록 후보는 각 콜레이터와 연결된 무작위 함수를 결정합니다. 예를 들어, collator의 주소 사이의 XOR 거리 측정 그리고 암호학적으로 안전한 의사 난수 블록이 생성되는 지점에 가깝게 결정됩니다. (명목상의 "당첨 티켓"). 이는 효과적으로 각 collator(또는 더 구체적으로 각 collator의 주소) 후보 블록이 "승리"할 무작위 확률 다른 모든 것. 단일 대조자의 시빌 공격을 완화하기 위해 당첨 티켓에 가까운 주소를 "채굴"하여 각 블록을 즐겨찾기에 추가하려면 대조자의 주소에 약간의 관성을 추가합니다. 이는 요구하는 것만큼 간단할 수 있습니다. 주소에 기본 자금 금액이 있어야 합니다. 더 우아한 접근 방식은 다음과 같은 근접성에 가중치를 두는 것입니다. 주차된 금액으로 당첨 티켓을 문제의 주소. 아직 모델링이 끝나지 않았지만, 이 메커니즘은 매우 소규모 이해관계자가 대조자로서 기여합니다. 6.5.5. 과체중 블록. validator 세트가 손상되면 블록을 생성하고 제안할 수 있습니다. 유효하고 실행하는 데 과도한 시간이 걸리며 검증하다. validator 그룹이 상당히 오랜 시간이 걸리는 블록을 합리적으로 형성합니다. 지름길을 허용하는 특정 정보가 이미 알려져 있지 않은 한 실행됩니다. 큰 인수분해 프라임. 단 한 명의 대조자가 해당 정보를 알고 있다면 그들은 자신의 것을 얻는 데 분명한 이점을 가질 것입니다 다른 사람들이 이전 블록을 처리하느라 바쁘다면 후보자들은 받아들여졌습니다. 우리는 이러한 블록을 과체중이라고 부릅니다. validators가 이러한 블록을 제출하고 검증하는 것에 대한 보호는 대체로 다음과 같은 방식으로 이루어집니다. 유효하지 않은 블록이지만 추가 주의사항은 다음과 같습니다. 블록을 실행하는 데 걸린 시간(따라서 블록의 상태) 과체중)은 주관적이며 투표의 최종 결과는 잘못된 행동은 본질적으로 세 가지 캠프로 분류됩니다. 하나 블록이 확실히 과체중이 아닐 가능성이 있습니다. 이 경우 2/3 이상이 그렇게 할 수 있다고 선언합니다. 일정 한도 내에서 블록을 실행합니다(예: 블록 간에 허용되는 총 시간의 50%). 또 다른 것은 블록은 d입니다확실히 과체중입니다. 2/3는 블록을 실행할 수 없다고 선언합니다. 상기 한도 내에서. 마지막 가능성 중 하나는 상당히 동일합니다. validators 사이의 의견 분열. 이 경우, 우리는 적절한 처벌을 선택하세요. validators가 언제 일어날지 예측할 수 있도록 하기 위해 비중확대 블록을 제안하는 경우 각 블록에 대한 자체 성과에 대한 정보를 게시하도록 요구하는 것이 합리적일 수 있습니다. ffi충분한 시간에 걸쳐, 이를 통해 처리 속도를 프로파일링할 수 있습니다. 그들을 판단할 동료들에 비해. 6.5.6. Collator 보험. validators에 대해 한 가지 문제가 남아 있습니다. PoW 네트워크와 달리 대조자의 유효성을 위해 블록을 실제로 실행해야 합니다. 악의적인 대조자는 유효하지 않거나 과중한 블록을 validator에 공급하여 슬픔을 유발할 수 있습니다(낭비 자원)을 요구하고 잠재적으로 상당한 기회 비용을 요구합니다. 이를 완화하기 위해 우리는 간단한 전략을 제안합니다. validators의 일부입니다. 먼저, 파라체인 블록 후보가 전송되었습니다. validators은(는) 릴레이 체인 계정에서 서명되어야 합니다. 자금으로; 그렇지 않은 경우 validator이 삭제되어야 합니다. 즉시요. 둘째, 그러한 후보자는 다음의 조합(예: 곱셈)에 의해 우선순위로 정렬되어야 합니다. 일정 한도 내에서 계좌에 있는 자금의 양, 대조자가 과거에 성공적으로 제안한 이전 블록의 수(이전 블록은 말할 것도 없고) 처벌) 및 승리에 대한 근접 요인 이전에 논의한 티켓. 캡은 동일해야합니다 해당 사건에서 validator에게 지급된 징벌적 손해배상금 그 중 잘못된 블록을 보내는 중입니다. 대조자가 유효하지 않거나 과중한 블록 후보를 validators에 보내는 것을 막기 위해 모든 validator은 오작동하는 대조자의 자금 중 일부 또는 전부를 이체하는 결과로 오작동을 주장하는 문제가 있는 블록을 포함하는 거래를 다음 블록에 배치합니다. 불만이 있는 validator에게 설명하세요. 이러한 유형의 트랜잭션은 대조자가 확인할 수 없도록 다른 트랜잭션을 먼저 실행합니다. 처벌 전에 자금을 제거하십시오. 금액 손해배상금으로 이전된 자금은 아직까지 동적 매개변수입니다.
POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 14 모델링될 예정이지만 발생한 슬픔의 수준을 반영하기 위해 validator 블록 보상의 일부가 될 가능성이 높습니다. 받는 사람 악의적인 validator이 대조자의 자금을 임의로 압수하는 것을 방지하기 위해 대조자는 무작위로 선택된 validator의 배심원단과 함께 validator의 결정에 대해 항소할 수 있습니다. 소액 입금을 위해. validator의 호의를 발견하면 보증금이 소비됩니다. 그렇지 않은 경우, 보증금이 반환되고 validator에 벌금이 부과됩니다(이후 validator은(는) 훨씬 더 아치형 위치에 있으므로 벌금이 부과됩니다. 아마도 꽤 무거울 것입니다). 6.6. 인터체인 거래 라우팅. 인터체인 트랜잭션 라우팅은 필수 유지 관리 중 하나입니다. 릴레이 체인 및 해당 validator의 작업입니다. 이것은 게시된 트랜잭션(종종 단순히 "포스트"로 단축됨)이 원하는 출력이 되는 방식을 제어하는 논리 하나의 소스 파라체인에서 신뢰 없이 다른 대상 파라체인의 협상 불가능한 입력이 되기까지 요구 사항. 우리는 위의 문구를 신중하게 선택했습니다. 특히 우리는 소스에 트랜잭션이 있을 필요는 없습니다. parachain이 이 게시물을 명시적으로 승인했습니다. 유일한 우리 모델에 적용하는 제약은 파라체인입니다. 전체 블록의 일부로 패키지되어 제공되어야 합니다. 처리 출력, 결과인 게시물 블록의 실행. 이러한 게시물은 여러 FIFO 대기열로 구성됩니다. 는 목록의 수는 라우팅 기반으로 알려져 있으며 약 16입니다. 특히 이 숫자는 수량을 나타냅니다. 의존하지 않고도 우리가 지원할 수 있는 파라체인의 수 다단계 라우팅. 처음에는 Polkadot에서 이를 지원합니다. 일종의 직접 라우팅이지만 가능한 한 가지 방법을 간략하게 설명하겠습니다. 다단계 라우팅 프로세스("하이퍼 라우팅")를 수단으로 사용 초기 파라체인 세트를 훨씬 넘어 확장되는 것입니다. 우리 가정하다 그 모두 참가자 알고있다 는 다음 두 블록 n, n + 1에 대한 하위 그룹화. 요약하면, 라우팅 시스템은 다음 단계를 따릅니다. • CollatorS: 검증인의 연락처[n][S] • CollatorS: 각 하위 그룹에 대해: 연락 중인 검증인[n][s] 구성원 최소 1명 • 대조자: 각 하위 그룹에 대해: 가정하다 egress[n −1][s][S]를 사용할 수 있습니다(모든 수신 게시물 마지막 블록의 데이터를 'S'로) • 대조자: S에 대해 블록 후보 b를 구성합니다. (b.헤더, b.ext, b.증명, b.영수증, b.egress) • 대조자: 보내기 증거 정보 증명[S] = (b.header, b.ext, b.proof, b.receipt) 유효성 검사기[n][S] • CollatorS: 외부 트랜잭션 데이터 b.ext 보장 다른 대조자와 validators가 사용할 수 있습니다. • 대조자: 에 대한 각각 하위 그룹 들: 보내기 출구 정보 송신[n][S][s] = (b.헤더, b.receipt, b.egress[s]) 에 는 수신 하위 그룹 회원 의 다음 블록 유효성 검사기[n + 1][s] • ValidatorV : 동일 세트의 모든 멤버를 미리 연결합니다. 다음 블록의 경우: N = Chain[n + 1][V ]; 연결하다 Chain[n + 1][v] = N이 되는 모든 validators v • 유효성 검사기V: 이에 대한 모든 데이터 수신을 대조합니다. 블록: 에 대한 각각 하위 그룹 들: 검색 egress[n −1][s][Chain[n][V ]], Chain[n][v] = Chain[n][V ]가 되도록 다른 validators v에서 가져옵니다. 시도 증명을 위해 무작위로 선택된 다른 validator을 통해 진행될 수도 있습니다. • 유효성 검사기V: 이에 대한 후보 증명을 수락합니다. 블록 증명[체인[n][V ]]. 투표 차단 유효성 • 유효성 검사기V: 다음에 대한 후보 송신 데이터 수락 다음 블록: 각 하위 그룹에 대해 수락 송신[n][s][N]. 투표 차단 출구 가용성; 관심 있는 validators v 사이에서 다시 게시하십시오. 사슬[n + 1][v] = 사슬[n + 1][V ]. • ValidatorV : 합의가 있을 때까지 여기서: egress[n][from][to]는 현재 송신 대기열입니다. 파라체인 'from'에서 다음으로 가는 게시물에 대한 정보 블록 번호 'n'의 파라체인 'to'. CollatorS는 parachain S에 대한 collator입니다. V alidators[n][s]는 블록 번호 n에 있는 parachain s에 대한 validators 집합입니다. 반대로, Chain[n][v]는 블록 번호 n에 validator v가 할당된 파라체인입니다. block.egress[to]는 송신입니다. 일부 파라체인 블록 블록의 게시물 대기열 목적지 파라체인은 입니다. 대조자는 다음을 기준으로 (거래) 수수료를 징수하므로 그들의 블록은 표준이 되며, 그들은 다음과 같은 인센티브를 받습니다. 각 다음 블록 대상에 대해 하위 그룹의 구성원은 현재의 송신 대기열에 대한 정보를 받습니다. 블록. 검증인은 (파라체인) 블록에 대한 합의를 형성하는 것에 대해서만 인센티브를 받습니다. 어떤 collator의 블록이 궁극적으로 표준이 됩니다. 에서 원칙적으로 validator은 대조자와 동맹을 맺고 다른 대조자의 기회를 줄이기 위해 공모할 수 있습니다. 블록이 정식화되지만 이는 둘 다 어렵습니다. 무작위 선택으로 인해 정렬validators의 액션 파라체인을 유지하는 파라체인 블록에 대해 지불해야 하는 수수료를 줄임으로써 방어할 수 있습니다. 합의 과정. 6.6.1. 외부 데이터 가용성. 파라체인의 보장 외부 데이터가 실제로 사용 가능하다는 것은 지속적인 문제입니다. 작업 부하를 분산시키는 것을 목표로 하는 분산형 시스템 네트워크. 문제의 핵심은 가용성이다 불가능하기 때문에 발생하는 문제 가용성에 대한 비대화형 증명을 만들거나 어떤 종류의 것도 만들지 마세요. BFT 시스템이 제대로 작동하려면 가용성이 없다는 증거를 제시하세요. 정확성이 의존하는 모든 전환을 검증합니다. 일부 외부 데이터의 가용성, 최대 수 허용 가능한 비잔틴 노드 수와 시스템의 1개 데이터가 이용 가능하다는 것을 증명해야 합니다. Polkadot과 같이 시스템을 적절하게 확장하려면 다음을 수행하세요. 문제를 야기합니다: validators의 일정한 비율이 있는 경우 데이터의 가용성을 증명해야 하며, validators는 데이터가 사용 가능하다고 주장하기 전에 실제로 데이터를 저장하기를 원할 것입니다. 그렇다면 어떻게 하면 시스템 크기(따라서 validators 수)에 따라 대역폭/스토리지 요구 사항이 증가하는 문제가 있습니까? 한 가지 가능한 대답은 별도의 세트를 갖는 것입니다. validators(가용성 보증인) 중 주문이 증가함 전체적으로 Polkadot 크기의 준선형적입니다. 이것은 6.5.3에 설명되어 있습니다. 두 번째 트릭도 있어요. 그룹으로서 대조자는 모든 데이터가 파라체인이 없으면 선택한 파라체인에 사용할 수 있습니다. 더 이상 블록을 작성할 수 없습니다. 거래 수수료를 징수합니다. Collator는 또한 구성원이 다양한 그룹을 형성합니다(데이터의 무작위 특성으로 인해). parachain validator 그룹) 입력하기 쉽고 쉽습니다.
POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 15 증명하기 위해. 따라서 최근 대조자(아마도 마지막 수천 블록 중)는 다음에 대한 이의제기를 발행할 수 있습니다. 특정 파라체인에 대한 외부 데이터의 가용성 소액 채권을 위해 validators를 차단하세요. 검증인은 증언한 분명히 문제가 있는 validator 하위 그룹의 사람들에게 연락하여 데이터를 수집하여 대조자에게 반환하거나 에스컬레이션해야 합니다. 가용성이 부족하다는 것을 증언함으로써 문제가 됩니다(데이터 제공을 직접 거부하는 것은 채권 압수 범죄로 간주되므로 잘못된 행동을 하는 validator은 아마도 연결 끊기) 및 추가 validators에 연락 동일한 테스트를 실행합니다. 후자의 경우, 대조자의 채권 반환됩니다. 이러한 비가용성 평가를 작성할 수 있는 validator의 정족수에 도달하면 해당 사용자는 해제됩니다. 잘못 행동하는 하위 그룹은 처벌되고 블록은 되돌려집니다. 6.6.2. 게시물 라우팅. 각 파라체인 헤더에는 출구-트리-루트; 이것은 다음을 포함하는 트라이의 루트입니다. 라우팅 기반 저장소, 각 저장소는 연결된 목록임 송신 게시물의 수입니다. 머클 증명은 다음과 같이 제공될 수 있습니다. parachain validators는 특정 parachain이 블록에는 특정 대상 파라체인에 대한 특정 송신 대기열이 있습니다. 파라체인 블록 처리 초기에는 각 해당 블록에 대한 다른 파라체인의 송신 대기열은 다음과 같습니다. 우리 블록의 수신 대기열에 병합되었습니다. 우리는 강하다고 가정하고, 아마도 CSPR9, 하위 블록 순서는 어느 것 사이에도 편애를 제공하지 않는 결정론적 연산을 달성하기 위한 것입니다. 파라체인 블록 페어링. Collator는 새 대기열을 계산합니다. 파라체인의 요청에 따라 출구 대기열을 비웁니다. 논리. 수신 대기열의 내용이 명시적으로 기록됩니다. 파라체인 블록에 들어갑니다. 여기에는 두 가지 주요 목적이 있습니다. 첫째, 이는 파라체인이 다른 파라체인과 분리되어 신뢰 없이 동기화될 수 있음을 의미합니다. 둘째, 전체 수신이 필요한 경우 데이터 물류를 단순화합니다. 대기열은 단일 블록에서 처리될 수 없습니다. validators 및 대조자는 다음 블록을 처리할 수 있습니다. 큐의 데이터를 특별히 소싱할 필요 없이. 파라체인의 수신 대기열이 임계값을 초과하는 경우 블록 처리가 끝나면 금액이 표시됩니다. 릴레이 체인이 포화되어 더 이상 메시지가 전송되지 않을 수 있습니다. 삭제될 때까지 전달됩니다. 머클 증명은 콜레이터 작업의 충실도를 입증하는 데 사용됩니다. 파라체인 블록의 증명. 6.6.3. 비평. 이 기본과 관련된 하나의 사소한 결함 메커니즘은 폭탄 후 공격입니다. 이곳은 모두가 파라체인은 가능한 최대량의 게시물을 보냅니다. 특정 파라체인에. 이것이 목표의 목표를 묶는 동안 한 번에 수신 대기열을 실행하면 계속해서 손상이 발생하지 않습니다. 표준 트랜잭션 DoS 공격. 잘 동기화된 세트로 정상적으로 작동하고 N 파라체인의 경우 비악성 대조자 및 validators, 파라체인당 N × M 총 validators 및 L 콜레이터, 우리는 블록당 전체 데이터 경로를 다음과 같이 분류할 수 있습니다. 유효성 검사기: M −1+L+L: 다른 validator에 대한 M −1 파라체인 세트에서 후보 파라체인 블록을 제공하는 각 콜레이터에 대한 L과 각 콜레이터에 대한 두 번째 L 이전 블록의 송신 페이로드가 필요한 다음 블록의 (후자는 실제로 최악의 경우에 가깝습니다. 대조자가 이러한 작업을 공유할 가능성이 높기 때문에 작업 데이터.) Collator: M +kN: 각 관련 항목에 대한 연결을 위한 M parachain 블록 validator, 각 parachain validator 그룹의 일부 하위 집합에 송신 페이로드를 시딩하기 위한 kN 다음 블록(그리고 선호하는 일부 대조자). 따라서 노드당 데이터 경로 방식은 선형적으로 증가합니다. 시스템의 전반적인 복잡성과 관련이 있습니다. 이 동안 합리적입니다. 시스템이 수백 또는 수천 개의 파라체인으로 확장됨에 따라 일부 통신 지연이 발생할 수 있습니다. 복잡성 증가율이 낮아지는 대가로 흡수됩니다. 이 경우 다중 단계 라우팅 알고리즘을 사용할 수 있습니다. 순간적인 경로의 수를 줄이기 위해 스토리지 버퍼와 대기 시간을 도입하는 비용이 듭니다. 6.6.4. 하이퍼큐브 라우팅. 하이퍼 큐브 라우팅은 대부분 하이퍼 큐브 라우팅의 확장으로 구축될 수 있는 메커니즘입니다. 위에서 설명한 기본 라우팅 메커니즘. 본질적으로, 파라체인과 하위 그룹 노드의 수로 노드 연결성을 늘리는 대신, 파라체인의 로그. 게시물은 다음 사이에 전송될 수 있습니다. 여러 파라체인이 최종 배송을 위해 줄을 서고 있습니다. 라우팅 자체는 결정적이고 간단합니다. 우리는 다음과 같이 시작합니다 수신/송신 대기열의 저장소 수를 제한합니다. 파라체인의 총 개수가 아니라, 는라우팅 기반(b) . 숫자로 고정됩니다 대신 라우팅 지수(e)가 증가하여 파라체인이 변경됩니다. 이 모델에서는 메시지 볼륨이 O(be)와 함께 성장하며 경로는 일정하게 유지됩니다. 및 지연 시간(또는 전송에 필요한 블록 수) O(e)로. 우리의 라우팅 모델은 e차원의 하이퍼큐브입니다. 큐브의 각 면에는 b개의 가능한 위치가 있습니다. 각 블록은 단일 축을 따라 메시지를 라우팅합니다. 우리 라운드 로빈 방식으로 축을 교체하여 최악의 경우 e 블록 배달 시간을 보장합니다. 파라체인 가공의 일환으로 해외로 향하는 수신 대기열에서 발견된 메시지는 다음과 같은 경우 적절한 송신 대기열의 저장소로 즉시 라우팅됩니다. 현재 블록 번호(및 라우팅 차원) 이 프로세스에는 각 홉에 대한 추가 데이터 전송이 필요합니다. 배송 경로에 문제가 있지만, 이는 그 자체로 문제입니다 이는 대체 수단을 사용하여 완화될 수 있습니다. 데이터 페이로드 전달 및 참조만 포함, 포스트 트라이에 있는 포스트의 전체 페이로드가 아니라. 시스템에 대한 하이퍼큐브 라우팅의 예 4개의 파라체인을 사용하면 b = 2 및 e = 2는 다음과 같을 수 있습니다. 0단계, 각 메시지 M: • sub0: Mdest ∈{2, 3}이면 sendTo(2), 그렇지 않으면 유지 • sub1: Mdest ∈{2, 3}이면 sendTo(3), 그렇지 않으면 유지 • sub2: Mdest ∈{0, 1}이면 sendTo(0), 그렇지 않으면 유지 • sub3: Mdest ∈{0, 1}이면 sendTo(1), 그렇지 않으면 유지 1단계, 각 메시지 M: • sub0: Mdest ∈{1, 3}이면 sendTo(1), 그렇지 않으면 유지 • sub1: Mdest ∈{0, 2}이면 sendTo(0), 그렇지 않으면 유지 • sub2: Mdest ∈{1, 3}이면 sendTo(3), 그렇지 않으면 유지 • sub3: Mdest ∈{0, 2}이면 sendTo(2), 그렇지 않으면 유지 여기의 두 차원은 첫 번째로 쉽게 볼 수 있습니다. 대상 인덱스의 2비트; 첫 번째 블록의 경우, 상위 비트만 사용됩니다. 두 번째 블록 거래 하위 비트로. 둘 다 발생하면 (임의로 주문) 게시물이 라우팅됩니다. 9암호적으로 안전한 의사 난수
POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 16 6.6.5. 세렌디피티의 극대화. 기본의 한 가지 변형 제안에서는 고정된 총 c2 −c validators를 볼 수 있습니다. c−1 각 하위 그룹의 validators. 블록 하나하나가 아니라 validators의 구조화되지 않은 재파티셔닝이 있습니다. 파라체인 중에서 각 파라체인 하위 그룹 대신에 각 validator은 고유하고 다른 항목에 할당됩니다. 다음 블록의 파라체인 하위 그룹. 이것은 두 블록 사이에 불변성이 발생합니다. 두 쌍의 파라체인에는 두 개의 validator이 존재합니다. 파라체인 책임을 바꿨습니다. 가용성에 대한 절대적인 보장을 얻는 데 사용할 수는 없지만 (단일 validator은 때때로 오프라인 상태가 됩니다. 자비로운) 그럼에도 불구하고 일반적인 경우를 최적화할 수 있습니다. 이 접근 방식에는 합병증이 없지는 않습니다. 파라체인을 추가하려면 재구성도 필요합니다. validator 세트 중. 또한 validator의 수는 파라체인 수의 제곱에 연결되어 있으며, 처음에는 아주 작은 규모로 시작하여 결국에는 멀리 성장할 것입니다. 너무 빨라서 약 50개의 파라체인 이후에는 견딜 수 없게 됩니다. 이들 중 어느 것도 근본적인 문제는 아닙니다. 첫 번째 경우, validator 세트의 재구성은 반드시 이루어져야 하는 것입니다. 어쨌든 정기적으로 했어요. validator의 크기에 관하여 너무 작으면 여러 개의 validator이 할당될 수 있습니다. 동일한 파라체인에 정수 인자를 적용하여 총 validators. 6.6.4에서 논의된 하이퍼큐브 라우팅과 같은 다단계 라우팅 메커니즘은 많은 수의 validator에 대한 요구 사항을 완화합니다. 체인 수가 많을 때. 6.7. 파라체인 검증. A validator의 주요 목적 유대감이 강한 배우로서 파라체인이 상태 전환, 외부 트랜잭션 포함, 실행 등을 포함하되 이에 국한되지 않는 블록이 유효합니다. 수신 대기열의 대기 중인 게시물과 최종 상태 송신 대기열의 프로세스 자체는 매우 간단합니다. validator가 이전 블록을 봉인하면 무료입니다. 후보 파라체인 블록을 제공하기 위한 작업을 시작합니다. 다음 합의 라운드 후보. 처음에 validator는 파라체인 콜레이터(다음에 설명) 또는 하나를 통해 파라체인 블록 후보를 찾습니다. 공동 validators 중 하나입니다. 파라체인 블록 후보 데이터 블록의 헤더, 이전 블록의 헤더, 포함된 모든 외부 입력 데이터(Ethereum 및 Bitcoin의 경우 이러한 데이터는 트랜잭션으로 참조되지만 원칙적으로 임의의 목적을 위한 임의의 데이터 구조를 포함할 수 있음), 상태 전환 유효성을 증명하기 위한 송신 대기열 데이터 및 내부 데이터(Ethereum의 경우) 이는 각 트랜잭션을 실행하는 데 필요한 다양한 상태/저장 트리 노드입니다. 실험적 증거는 최근 Ethereum 블록에 대한 전체 데이터세트를 보여줍니다. 최대 수백 KiB입니다. 동시에 아직 완료되지 않은 경우 validator은(는) 처음에는 이전 블록의 전환과 관련된 정보를 검색하려고 시도합니다. validators 이상은 모든 validators 서명에서 데이터의 가용성. validator이 그러한 후보 블록을 수신하면, 그런 다음 로컬에서 유효성을 검사합니다. 검증 프로세스는 파라체인 클래스의 validator 모듈 내에 포함되어 있습니다. 반드시 작성해야 하는 합의에 민감한 소프트웨어 모듈 Polkadot 구현에 대해(원칙적으로는 C ABI가 포함된 라이브러리는 단일 라이브러리로 다음을 수행할 수 있습니다. 적절한 구현 간에 공유됩니다. 단일 "참조" 구현만으로 인한 안전성 감소). 이 프로세스는 이전 블록의 헤더를 가져와서 최근 합의된 릴레이 체인을 통해 그 신원을 확인합니다. hash이 기록되어야 하는 블록입니다. 상위 헤더의 유효성이 확인되면 특정 파라체인이 클래스의 유효성 검사 함수가 호출될 수 있습니다. 이는 다수의 데이터 필드(대략적으로)를 허용하는 단일 함수입니다. 이전에 제공된 것) 간단한 부울을 반환합니다. 블록의 유효성을 선언합니다. 대부분의 검증 기능은 먼저 직접 파생될 수 있는 헤더 필드 상위 블록(예: 상위 hash, 번호). 팔로잉 그러면 내부 데이터 구조가 다음과 같이 채워집니다. 거래 및/또는 게시물을 처리하기 위해 필요합니다. Ethereum와 같은 체인의 경우 이는 필요한 노드가 포함된 데이터베이스를 트리로 구성합니다. 거래의 완전한 실행. 다른 체인 유형에는 다른 p회복 메커니즘. 완료되면 수신 게시물과 외부 트랜잭션(또는 외부 데이터가 나타내는 모든 것)이 체인 사양에 따라 제정되고 균형이 맞춰집니다. (A 합리적인 기본값은 모든 수신 게시물을 요구하는 것일 수 있습니다. 외부 트랜잭션이 서비스되기 전에 처리되지만 이는 파라체인의 논리에 따라 결정되어야 합니다.) 이번 제정을 통해 일련의 출구 게시물이 게시될 예정입니다. 생성되었으며 이것이 실제로 일치하는지 확인됩니다. 콜러의 후보. 마지막으로, 제대로 채워졌습니다. 헤더는 후보자의 헤더와 비교하여 확인됩니다. 완전히 검증된 후보 블록을 사용하면 validator 그런 다음 헤더의 hash에 투표하고 모든 필수 유효성 검사 정보를 해당 하위 그룹의 co-validator에 보낼 수 있습니다. 6.7.1. 파라체인 콜레이터. 파라체인 콜레이터는 채굴자의 작업 대부분을 수행하는 비결합 운영자입니다. 현재 blockchain 네트워크에서. 그것들은 구체적이다 특정 파라체인에. 작동하려면 반드시 릴레이 체인과 완전 동기화를 모두 유지합니다. 파라체인. "완전히 동기화됨"의 정확한 의미는 파라체인 클래스에 따라 다르지만 항상 파라체인 수신 대기열의 현재 상태를 포함합니다. Ethereum의 경우 최소한 유지 관리도 포함됩니다. 마지막 몇 블록의 머클 트리 데이터베이스이지만 Bloom을 포함한 다양한 다른 데이터 구조도 포함 계정 존재, 가족 정보, 로깅을 위한 필터 블록 번호에 대한 출력 및 역방향 조회 테이블. 두 체인의 동기화를 유지하는 것 외에도 또한 트랜잭션 대기열을 유지하고 적절하게 검증된 트랜잭션을 수락하여 트랜잭션을 "피싱"해야 합니다. 공용 네트워크에서. 대기열과 체인을 사용하면 각 블록에서 선택된 validator에 대한 새로운 후보 블록을 생성하고(릴레이체인이 동기화된 이후 신원이 알려짐) 이를 유효성 증명 등 다양한 보조 정보를 통해 피어 네트워크. 문제가 발생하면 포함된 거래와 관련된 모든 수수료를 징수합니다. 이를 둘러싸고 다양한 경제학이 떠돌고 있다. 배열. 경쟁이 치열한 시장에서 대조자가 너무 많으면 거래가 발생할 가능성이 있습니다. 인센티브를 제공하기 위해 수수료는 파라체인 validator과 공유됩니다. 특정 collator의 블록을 포함합니다. 비슷하게,
POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 17 일부 대조자는 필요한 수수료를 인상할 수도 있습니다. 블록을 더 매력적으로 만들기 위해 비용을 지불합니다. validators. 이 경우 자연시장이 형성되어야 한다. 더 높은 수수료를 지불하는 거래가 대기열을 건너뛰는 경우 체인에 더 빠르게 포함됩니다. 6.8. 네트워킹. 기존 blockchains의 네트워킹 Ethereum 및 Bitcoin와 같은 요구 사항은 다소 간단합니다. 모든 거래와 블록은 단순하고 방향성이 없는 소문으로 방송됩니다. 특히 동기화가 더 복잡합니다. Ethereum을 사용하지만 실제로는 이 논리가 몇 가지 요청 및 응답 메시지 유형을 중심으로 해결된 프로토콜 자체가 아닌 피어 전략입니다. Ethereum은 devp2p 프로토콜을 사용하여 현재 프로토콜 제공에 진전을 이루었습니다. 단일 피어 연결을 통해 멀티플렉싱되는 서브프로토콜은 동일한 피어 오버레이를 가지며 여러 가지를 지원합니다. p2p 프로토콜을 동시에 사용하면 Ethereum 부분 프로토콜은 여전히 상대적으로 단순했고 p2p는 한동안 프로토콜은 중요한 문제로 인해 완료되지 않은 상태로 남아 있습니다. QoS 지원과 같은 기능이 누락되었습니다. 안타깝게도 보다 유비쿼터스적인 "웹 3" 프로토콜을 만들고자 하는 열망은 주로 실패했습니다. 이를 사용하는 유일한 프로젝트는 명시적으로 Ethereum 크라우드 세일을 통해 자금을 조달했습니다. Polkadot에 대한 요구 사항은 다소 더 중요합니다. 오히려 완전히 균일한 네트워크, Polkadot 동료 구성 및 여러 네트워크에 대해 각기 다른 요구 사항을 가진 여러 유형의 참가자가 있습니다. 참가자들이 대화를 나누는 경향이 있는 "길" 특정 데이터. 이는 훨씬 더 구조화된 네트워크 오버레이와 이를 지원하는 프로토콜을 의미합니다. 필요할 것 같습니다. 또한, 새로운 종류의 "체인"과 같은 향후 추가를 용이하게 하는 확장성이 가능합니다. 자체적으로는 새로운 오버레이 구조가 필요합니다. 네트워킹 방법에 대해 심도있게 논의하는 동안 프로토콜이 이 문서의 범위를 벗어나는 것처럼 보일 수 있지만 일부 요구 사항 분석은 합리적입니다. 우리는 할 수 있다 네트워크 참가자를 대략 두 세트로 나눕니다. (릴레이 체인, 파라체인) 각각 세 개의 하위 집합입니다. 우리는 할 수 있다 또한 각 파라체인 참가자는 오직 그들 사이의 대화에 관심이 있는 반면 다른 파라체인 참가자: • 릴레이 체인 참가자: • 유효성 검사기: P, 각각에 대해 하위 집합 P[s]로 분할 파라체인 • 가용성 보증자: A(프로토콜 기본 형식의 유효성 검사기로 표현될 수 있음) • 릴레이 체인 클라이언트: M(각 멤버 참고 파라체인 세트도 M)의 구성원이 되는 경향이 있습니다. • 파라체인 참가자: • 파라체인 대조자: C[0], C[1], . . . • 파라체인 어부: F[0], F[1], . . . • 파라체인 클라이언트: S[0], S[1], . . . • 파라체인 라이트 클라이언트: L[0], L[1], . . . 일반적으로 우리는 특정 종류의 의사소통을 명명합니다. 다음 세트의 구성원 간에 발생하는 경향이 있습니다. • 피 | 에이 <-> 피 | 답: 는 가득 찬 세트 의 validators/보증인 반드시 있다 잘 연결된 에 합의를 이루다. • P[s] <-> C[s] | P[s]: 특정 파라체인 그룹의 구성원인 각 validator은 험담을 하는 경향이 있습니다. 다른 회원 및 대조자와 함께 해당 파라체인의 블록 후보를 발견하고 공유합니다. • A <-> P[s] | 다 | A: 각 가용성 보증인 합의에 민감한 크로스체인을 수집해야 합니다. 할당된 validator의 데이터; 대조자 또한 그들의 의견에 대한 합의 가능성을 최적화할 수도 있습니다. 가용성 보증인에게 광고하여 차단합니다. 일단 데이터를 갖게 되면 데이터는 다음에 분배됩니다. 합의를 촉진하기 위한 기타 보증인. • P[s] <-> A | P[s']: 파라체인 validators는 이전 validator 세트 또는 가용성 보증자로부터 추가 입력 데이터를 수집해야 합니다. • F[s] <-> P: 보고 시 어부들은 다음과 같은 위치를 지정할 수 있습니다. 참가자와의 청구. • M <-> M | 피 | A: 일반 릴레이 체인 클라이언트는 validators 및 보증인으로부터 데이터를 지불합니다. • S[들] <-> S[들] | 추신 | A: 파라체인 클라이언트는 validator/보증인으로부터 데이터를 지불합니다. • L[초] <-> L[초] | S[s]: 파라체인 라이트 클라이언트 전체 클라이언트로부터 데이터를 지불합니다. 효율적인 운송 메커니즘을 보장하기 위해 "플랫" Ethereum의 devp2p와 같은 오버레이 네트워크 노드는 (비임의적으로) 자신의 적합성을 구별하지 않습니다. 또래는 적합하지 않을 것 같습니다. 합리적으로 확장 가능한 피어 선택 및 검색 메커니즘에는 다음이 필요할 수 있습니다. 공격적일 뿐만 아니라 프로토콜 내에 포함되어야 함 올바른 종류의 동료를 보장하기 위해 미리 계획을 세웁니다. "우연히" 연결되어 있습니다적절한 시기에 시행되었습니다. 동료 구성의 정확한 전략은 참가자 클래스마다 다릅니다. 다중 체인, 대조자는 지속적으로 그에 따라 선택된 validator에 다시 연결하거나 validator의 하위 집합과 지속적인 계약이 필요합니다. validator에 쓸모가 없는 대부분의 시간 동안 연결이 끊어지지 않도록 합니다. Collator는 자연스럽게 하나의 데이터를 유지하려고 시도합니다. 또는 가용성 보증인에 대한 보다 안정적인 연결 합의에 민감한 메시지의 신속한 전파를 보장하도록 설정되었습니다. 데이터. 가용성 보증인은 대부분 가용성을 유지하는 것을 목표로 합니다. 서로 및 validators에 대한 안정적인 연결(합의 및 합의에 중요한 파라체인 데이터의 경우) 그들이 증명함) 및 일부 대조자(파라체인의 경우) 데이터) 및 일부 어부 및 전체 고객(분산용) 정보). 유효성 검사기는 다른 validator, 특히 동일한 하위 그룹과 다른 validator을 찾는 경향이 있습니다. 파라체인 블록 후보를 제공할 수 있는 대조자. 어부 뿐만 아니라 일반 릴레이체인, 파라체인 클라이언트는 일반적으로 연결을 열린 상태로 유지하는 것을 목표로 합니다. validator 또는 보증인이지만 유사한 다른 노드가 많이 있습니다. 그렇지 않으면 스스로에게. 파라체인 라이트 클라이언트는 마찬가지로 파라체인의 전체 클라이언트에 연결되는 것을 목표로 합니다. 다른 파라체인 라이트 클라이언트뿐만이 아니라면요. 6.8.1. 동료 이탈 문제. 기본 프로토콜 제안에서 이러한 각 하위 집합은 검증을 위해 할당된 validator으로 각 블록과 함께 지속적으로 무작위로 변경됩니다. 파라체인 전환은 무작위로 선택됩니다. 이것은 할 수 있다 서로 다른(비피어) 노드가 다음을 수행해야 하는 경우 문제가 됩니다. 서로 데이터를 전달합니다. 다음 중 하나에 의존해야 합니다. 공정하게 분산되고 잘 연결된 피어 네트워크
POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 18 홉 거리(따라서 최악의 대기 시간)가 네트워크 크기의 대수만큼만 증가하는지 확인합니다. (Kademlia와 유사한 프로토콜 [13]이 여기서 도움이 될 수 있습니다) 또는 반드시 피어 세트를 유지하기 위해 필요한 연결 협상이 이루어질 수 있도록 더 긴 블록 시간을 도입합니다. 노드의 현재 통신 요구 사항을 반영합니다. 둘 다 훌륭한 솔루션은 아닙니다: 긴 블록 시간 네트워크에 강제로 연결하면 네트워크가 쓸모없게 될 수 있습니다. 특정 애플리케이션 및 체인. 완벽하게 공평한 것조차 연결된 네트워크는 상당한 낭비를 초래합니다. 관심 없는 노드로 인해 대역폭이 확장됩니다. 쓸모없는 데이터를 전달합니다. 양방향이 솔루션의 일부가 될 수 있지만, 지연 시간을 최소화하는 데 도움이 되는 합리적인 최적화는 이러한 파라체인의 변동성을 제한해야 합니다 validator 세트, 일련의 블록 사이에서만 멤버십을 재할당하거나(예: 4초에 15개의 그룹으로) 차단 시간은 연결을 1회에 한 번만 변경하는 것을 의미합니다. 분) 또는 증분 방식으로 멤버십을 순환합니다. 한 번에 한 멤버씩 변경(예: 각 파라체인에 15개의 validator이 할당되어 있으며, 평균적으로 완전히 고유한 파라체인 사이에는 1분이 걸립니다. 세트). 피어 이탈의 양을 제한하고 유리한 피어 연결이 잘 이루어지도록 보장함으로써 파라체인의 부분적인 예측 가능성을 통해 발전 세트를 통해 각 노드가 영구적으로 유지되도록 도울 수 있습니다. 우연한 동료 선택. 6.8.2. 효과적인 네트워크 프로토콜에 대한 경로. 아마도 가장 효과적이고 합리적인 개발 노력은 롤링보다는 기존 프로토콜을 활용하는 데 중점을 둘 것입니다. 우리 자신. 여러 P2P 기본 프로토콜이 존재합니다. Ethereum의 자체 devp2p를 포함하여 사용하거나 강화할 수 있습니다. [22], IPFS의 libp2p [1] 및 GNU의 GNUnet [4]. 이러한 프로토콜과 프로토콜 구축과의 관련성에 대한 전체 검토 특정 구조적 보장, 동적 피어 조정 및 확장 가능한 하위 프로토콜을 지원하는 모듈형 피어 네트워크 이 문서의 범위를 훨씬 벗어나지만 Polkadot 구현의 중요한 단계입니다. 7. 프로토콜의 실용성 7.1. 인터체인 거래 결제. 훌륭한 동안 Ethereum의 가스와 같은 전체적인 계산 리소스 회계 프레임워크에 대한 필요성을 없애면 상당한 자유와 단순성을 얻을 수 있습니다. 이는 중요한 질문을 제기합니다. 가스 없이 하나의 파라체인을 어떻게 수행할 수 있습니까? 다른 파라체인이 강제로 계산을 수행하는 것을 방지하시겠습니까? 우리는 트랜잭션-포스트 수신 큐에 의존할 수 있지만 한 체인이 다른 체인에 스팸을 보내는 것을 방지하는 버퍼 트랜잭션 데이터에는 트랜잭션 처리의 스팸을 방지하기 위해 프로토콜에서 제공하는 동등한 메커니즘이 없습니다. 이는 더 높은 수준에 맡겨진 문제이다. 체인 이후 들어오는 항목에 임의의 의미를 자유롭게 첨부할 수 있습니다. 거래 후 데이터를 통해 우리는 계산을 보장할 수 있습니다. 시작하기 전에 비용을 지불해야 합니다. 와 비슷한 맥락으로 Ethereum Serenity가 지지하는 모델, 우리는 상상할 수 있습니다 파라체인 내의 "침입" 계약을 통해 validator는 다음과 같은 대가로 지불을 보장받습니다. 특정 양의 처리 자원 제공. 이러한 자원은 가스와 같은 것으로 측정될 수 있습니다. 그러나 주관적인 실행 시간이나 Bitcoin과 같은 정액 요금 모델과 같은 완전히 새로운 모델일 수도 있습니다. 이는 오프체인 호출자가 사용할 수 있다고 쉽게 가정할 수 없기 때문에 그 자체로는 그다지 유용하지 않습니다. 침입에 의해 인식되는 모든 가치 메커니즘 계약. 그러나 소스 체인에서 2차 "돌파" 계약을 상상할 수 있습니다. 두 계약은 함께 다리를 형성하여 서로를 인식하고 가치 동등성을 제공합니다. (스테이킹-tokens, 사용 가능 각각은 국제수지 정산에 사용될 수 있습니다.) 다른 체인을 호출하는 것은 프록시를 의미합니다. 이 다리를 통해 체인 간의 가치 이전을 협상하여 대상 파라체인에 필요한 계산 리소스에 대한 비용을 지불합니다. 7.2. 추가 체인. 동안 는 추가 의 에 파라체인은 상대적으로 저렴한 운영이지만 무료는 아닙니다. 파라체인이 많을수록 파라체인당 validator 수가 줄어듭니다. 그리고 결국에는 더 많은 수의 validator이 각각 평균 채권 감소. 파라체인 공격에 대한 강제 비용이 더 작아지는 문제는 다음을 통해 완화됩니다. 어부 여러분, 성장하는 validator 세트는 본질적으로 기본 합의 메커니즘으로 인해 더 높은 수준의 대기 시간그래. 게다가 각 파라체인 validators에게 슬픔을 안겨줄 가능성이 있습니다. 과도한 부담을 주는 검증 알고리즘. 따라서 validators의 "가격"이 있을 것입니다. 및/또는 지분 보유 커뮤니티는 새로운 파라체인 추가. 이 체인 시장은 아마도 다음 중 하나가 추가된 것을 볼 수 있습니다: • 일부로 만들기 위해 지불하는 순 기여금(staking tokens 잠금 또는 소각 측면에서)이 0일 가능성이 있는 체인(예: 컨소시엄 체인, Doge 체인, 앱별 체인); • 네트워크에 본질적인 가치를 제공하는 체인 특정 기능을 추가하는 것은 어렵습니다. 다른 곳으로 이동하기 위해(예: 기밀성, 내부 확장성, 서비스 연계) 본질적으로 이해관계자 커뮤니티는 다음을 수행해야 합니다. 재정적으로나 경제적으로 하위 체인을 추가하도록 인센티브를 받을 수 있습니다. 릴레이에 특징적인 체인을 추가하려는 욕구를 통해. 새로운 체인이 추가되면 매우 큰 효과를 얻을 것으로 예상됩니다. 제거를 위한 짧은 통지 기간으로 인해 새로운 체인이 손상될 위험 없이 실험을 수행할 수 있습니다. 중장기적 가치 제안. 8. 결론 우리는 저자가 취할 수 있는 방향을 설명했습니다. 기존의 특정 체인과 역호환이 가능한 확장 가능한 이종 다중 체인 프로토콜 blockchain 네트워크. 이러한 프로토콜에 따라 참가자는 기존 사용자에게 일반적인 비용을 들이지 않고 매우 자유로운 방식으로 확장할 수 있는 전체 시스템을 만들기 위해 계몽된 사리사욕을 바탕으로 작업합니다. 표준 blockchain 디자인에서 나옵니다. 우리는 주었다 다음을 포함하여 필요한 아키텍처의 대략적인 개요 참가자의 성격, 경제적 인센티브 그리고 그들이 참여해야 하는 프로세스. 우리는 기본 디자인을 파악하고 그 장점에 대해 논의했습니다. 제한 사항; 따라서 우리는 더 많은 방향을 가지고 있습니다. 이러한 제한을 완화하고 완전히 확장 가능한 blockchain 솔루션을 향한 추가 기반을 마련할 수 있습니다.POLKADOT: 이종 다중 체인 프레임워크에 대한 비전 초안 1 19 8.1. 누락된 자료 및 공개 질문. 네트워크 분기는 프로토콜의 다양한 구현으로 인해 항상 가능합니다. 그러한 것으로부터의 회복 예외적인 상황은 논의되지 않았습니다. 네트워크가 반드시 0이 아닌 최종화 기간을 갖는다는 점을 고려하면, 릴레이체인 분기에서 복구하는 것은 큰 문제가 되지 않지만 합의 프로토콜. 채권 몰수와 반대로 보상 제공은 깊게 탐구되지 않았습니다. 현재 우리는 보상을 가정합니다. 승자독식 원칙에 따라 제공됩니다. 그렇지 않을 수도 있습니다. 어부들에게 최고의 인센티브 모델을 제공합니다. 단기간 커밋-공개 프로세스를 통해 많은 어부들이 보다 공정한 보상 분배를 통해 상금을 청구하고, 그러나 프로세스로 인해 추가 대기 시간이 발생할 수 있습니다. 잘못된 행동 발견. 8.2. 감사의 말씀. 많은 분들께 감사드립니다. 막연하게 이 문제를 이해하는 데 도움을 준 교정자들 표현 가능한 모양. 특히 Peter Czaban, Bj¨orn 바그너, 켄 카플러, 로버트 하버마이어, 비탈릭 부테린, 레토 트링클러, 잭 피터슨. 모두에게 감사드립니다 아이디어나 시작에 기여한 사람들 그 중에서도 Marek Kotewicz와 Aeron Buchanan은 특별히 언급할 가치가 있습니다. 그리고 도움을 주신 다른 모든 분들께도 감사드립니다 길을 따라. 모든 오류는 내 자신의 것입니다. 초기 연구를 포함한 이 작업의 일부 합의 알고리즘은 영국으로부터 부분적으로 자금을 지원받았습니다. Innovate UK 프로그램에 따른 정부.