【2023】仮想通貨ポルカドット（DOT）とは？根拠のある今後の予想｜ホワイトペーパー

事務員

皆さんは仮想通貨調べる際、どのように調査していますか？
ググるくらいしか私分かんなくて…。

クリプ犬

確かに、自分も最初の方はググるとかSNSを見るとかしか分からなかったな…。
でもググった先のサイトとか、分かりやすいの多いからいいんじゃないかな。

事務員

でも、サイトによっては記載していることが違ったり、逆に多いのはほとんど同じ内容書かれていたり、参考にしがたい時があるの…。
自分で根拠のあるものをみて納得したいんだよね～。

クリプ犬

事務員さんも成長したなぁ～(笑)
確かに投資するならなおさら根拠あるものを見たいよね。
そんな時はホワイトペーパーを見てみるといいよ◎

事務員

ホワイトペーパーってなになに？？

ホワイトぺーパーとは？

ホワイトペーパーとはその仮想通貨の開発された目的や技術について、今後の計画などが記載された報告書のようなものです。
ほとんどの仮想通貨にはホワイトペーパーは必ず用意されており、信頼できる報告書です。
気になる仮想通貨がある場合は、必ずホワイトペーパーを見るようにしましょう。

ホワイトペーパーについて

より詳しくはホームに記載しておりますので、仮想通貨　分析所 | 将来性のある仮想通貨の分析結果。 (crypt-information.com)をご参照ください。

ただ、ホワイトペーパーは全て英語で書かれていたり、技術の事ばかりで何書いているか分からないことも多いです…。

そこで、当サイトでは、仮想通貨毎のホワイトペーパーから読み取れた内容などを用いて今後の予想などしていきます。
ぜひ参考にしていってください◎

目次

結論｜今後の予想

1.「確認ポイント」
　　1-1.ロードマップ（開発スケジュール）
　　1-2.発行主体（プロジェクトメンバー）
　　1-3.拠点
　　 1-4.資金調達方法・使い道
　　 1-5.開発目的（具体性があるか）
　　1-6.発行上限

2.「ホワイトペーパー」
　　2-1.日本語訳
　　 2-2.原文

前提

こちらの記事では、ホワイトペーパーや項目毎の調査で今後の計画の信ぴょう性や現在の進捗、資金の有無を分析し、今後の将来性（どのくらい上がるかというよりも、今後投資する価値はあるのか）を予想していきます。

※ただし投資は自己責任で。特に仮想通貨は移り変わりが早いので注意です。

結論｜今後の予想

まず今後の予想から記載します。

結論：今回の分析だと、今後もまあ安心して投資できそうと判断しました。

安心度合い：

過去最高価格は6000円ほどでしたが、現在は862円ほど（2023/03/17現在）

【良い点】
・ロードマップが視覚的にも分かりやすく書かれており、簡単なQ&Aもあり、初心者の方にも優しい点
・バックの財団の規模が大きいと思われる点
・元CEOですが、イーサリアム共同創設者の一人である”GAVIN WOOD”氏であった点

【気になる点】
・最大供給量が記載されていない点
・Web3財団の資金源がはっきりとは分からない点（調査不足）

購入できる取引所

2023年4月7日【実際の使用レビュー】【国内取引所おすすめ】仮想通貨　取引所徹底比較してみた。

1.「ホワイトペーパー　確認ポイント」

まず以下の図をご覧ください。
ホワイトペーパーから読み取るべきポイントを簡単にまとめたものです。

ホワイトペーパーからはひとまず、発行上限までの6つの事項が確認できるかチェックしましょう。
仮想通貨は信用できる情報をどれだけ早く正確に手に入れられるかが大事です。
チェック項目を絞っておくことで、少しでも他の方より一歩先へ行けるよう準備しておきましょう。

ただ、ホワイトペーパーの中には、技術的側面が多く記載されたホワイトペーパーや、記載情報が少ないものもあります。
そこで、上記の6つの項目がホワイトペーパーに記載されているかの有無と、無かった場合の簡易的な検索結果をまとめましたので、ぜひご活用下さい。

1-1.ロードマップ（開発スケジュール）｜ポルカドット　仮想通貨

ロードマップとは、丁寧に一言で表すと、「（ある仮想通貨の）今後の計画を記したもの」です。

ホワイトペーパ―の中で、その仮想通貨の今後または現在の進捗具合を知るのに、ロードマップは大きな役割を果たします。このロードマップが細かく書かれている方が投資家にとっても投資対象かどうか判断しやすいですし、綿密な計画を練っている事も判断できるので、ロードマップの粒度も確認したいポイントです。

【DOT　ロードマップ】：
ホワイトペーパーからは見つけられませんでした。

【検索結果】：
公式ホームページに記載がありました。現在のフェーズはパラチェーンのオークションが完了し、ローンチしたもののアップデートの段階です。現在のフェーズがどこなのかも分かりやすく記載されており、また簡単なQ&Aも確認出来ました。

Polkadot Launch Roadmapより引用
2023/01/19

1-2.発行主体（プロジェクトメンバー）｜DOT 開発メンバー

発行主体は見落としがちですが、しっかり確認しましょう。
時価総額が高くSOLのように有名であれば、発行元が不明瞭なことはあり得ませんが、念のためどのホワイトペーパーでも確認するようにしましょう。

【DOT　開発メンバー（CEOなど）】：
こちらはホワイトペーパーのタイトルの下に記載がありました。
イーサリアム共同創設者”GAVIN WOOD”氏とのことでしたが、2022年10月末頃にCEOを辞退しているようです。
現CEOは”Björn Wagner”氏となっています。

1-3.活動拠点（実際に存在するかも併せて）｜DOT 仮想通貨

開発拠点・活動拠点がしっかり記載してあれば、信用度は上がります。
ただこれからはより非中央集権化が進むと思われるため、活動拠点がしっかりとしているものも少なくなってくるかもしれません。あれば本当に存在しているのか確認してみましょう。

【DOT　活動拠点】：
ホワイトペーパーからは見つけられませんでした。

【検索結果】：
Web3 Foundationという組織がポルカドットプロジェクトを推進しており、その拠点はスイスのツークという所にあるとのことです。
Web3 Foundationとは、Web3.0基盤の研究開発プロジェクトに資金を提供する財団です。

1-4.資金調達方法（資金の使い方も併せて）｜ポルカドットホワイトペーパー

資金の有無はその仮想通貨の将来性にも大きく関わってきます。
資金調達がしっかり公表されており、資金調達した企業が大物であればあるほど世間からの期待は大きいものとなり、価格もそれに比例するものです。
資金調達とは少し話がずれますが、かのイーロンマスクがドージコインに投資をするようなツイートをしたところ、とんでもない高騰を見せました。
たまたま買っていた方羨ましい…。(笑)

【DOT　資金調達方法】：
ホワイトペーパーには以下の記載がありました。
根拠は探せませんでしたが、政府からの助成金をもらっているプロジェクトは私の分析してきた仮想通貨の中でも初です。
またポルカドットの背景にあるWeb3財団自体、50以上の国の450を超えるプロジェクトに資金提供しており、規模の大きさが伺えますね。

これまでの開発には、英国政府からの助成金を含む複数の関係者が資金を提供しています。

ホワイトペーパーより引用
2023/01/20

【検索結果】：
ICOでも資金調達をしており、約150億円もの資金を調達しておりました。

1-5.開発目的（具体性のあるものかどうか）｜ポルカドット将来性

開発目的がはっきりしていない仮想通貨は将来性ははっきりいってありません。
もしあなたが本気でどこかの株を買う際、何のためにその会社が存在しているのか調べたりしますよね。
その会社が目的を持たずふんわりやっていそうだなと判断した時投資するでしょうか？
私ならしません…。
ただ、ホワイトペーパーに開発目的が書かれていないからといって将来性が無いとは言い切れません。
ホワイトペーパーが技術に関してを中心に書かれているものも多いためです。

【DOT　開発目的】：
ホワイトペーパーには以下の記載がありました。
簡単に言うと、異なるブロックチェーンとの相互運用性をポルカドットネットワークで実現させることが目的のようです。

ホワイトペーパーより引用
2023/01/20

現時点では期待度最高評価！の仮想通貨とは？

ディズニーファンも注目、仮想通貨MATICの将来性は？

1-6.発行上限｜ポルカドット価格

発行上限はその仮想通貨の価格に大きく影響を及ぼします。
極論を言ってしまうと、もし無限に発行されるものの場合、価格はどこまでも落ちる可能性があります。
上限がきちんと制定されているモノの方が筆者は安心いたします。

【DOT　発行上限】：
ホワイトペーパーからは見つけられませんでした。

【検索結果】：
最新（2023/01/22）のcoinmarketcapによると最大供給量の欄が「–」になっていました。
どうやら最大供給量は表示されていない様です。
この点は不安ですね。

2.「ホワイトペーパー」

以下では原文のリンクと日本語訳を記載しておりますので是非ご活用ください。

2-1.DOT ホワイトペーパー原文

PolkaDotPaper.pdf

2-2.DOT ホワイトペーパー日本語訳

2023/01/14翻訳
Google翻訳など使用し翻訳いたしました。

ポルカドット：テロジニアス・マルチチェーンフレームワークのためのビジョン
ドラフト1

DR. GAVIN WOOD
FOUNDER, ETHEREUM & PARITY
GAVIN@PARITY.IO

概要

現在のブロックチェーンアーキテクチャは、拡張性とスケーラビリティの実用的な手段を筆頭に、多くの問題に悩まされています。
これは、コンセンサスアーキテクチャの非常に重要な2つの部分、すなわち正準性と妥当性をあまりにも密接に結び付けていることに起因すると考える。
本論文では、この2つを根本的に分離するアーキテクチャである異種混在マルチチェーンを紹介します。
この2つの部分を区分けし、提供される全体的な機能をセキュリティとトランスポートの絶対的な最小値に抑えることで、コア拡張性の実用的な手段をその場で導入します。スケーラビリティは、これら2つの機能に対する分割統治アプローチによって対処され、信頼されていないパブリックノードのインセンティブによって、結合されたコアからスケールアウトされます。
このアーキテクチャの異種混在性により、非常に多様なタイプのコンセンサスシステムが、信頼性のない完全分散型の「フェデレーション」で相互運用され、オープンネットワークとクローズドネットワークが相互に信頼なくアクセスできるようになります。
我々は、イーサリアムのような既存のネットワークとの後方互換性を提供する方法を提案している。
このようなシステムは、グローバル・コマース・レベルのスケーラビリティとプライバシーを達成できる実用的なシステムの全体的な探索において、有用な基本レベルの構成要素を提供すると考えている。

1.はじめに

本書は、ブロックチェーンパラダイムをさらに発展させる上で取り得る一つの方向性を、その方向性が賢明である理由とともに技術的に「ビジョン」要約することを意図したものである。
ブロックチェーン技術の様々な側面を具体的に改善する可能性のあるシステムを、現段階の開発で可能な限り詳細に説明しています。
本書は、形式的なものであれ、仕様書であれ、それを意図したものではありません。
包括的であることも、最終的な設計であることも意図していない。
API、バインディング、言語、使用法など、フレームワークの非中核的な側面をカバーすることは意図していません。
これは特に実験的なものであり、パラメータが指定されている場合、それらは変更される可能性があります。
コミュニティのアイデアや批評に応えて、機構は追加、改良、削除される予定です。
この文書の大部分は、実験的な証拠とプロトタイピングによって、何がうまくいき、何がうまくいかないかという情報が得られるにつれて、おそらく修正されるでしょう。
この文書には、プロトコルの中核的な記述と、様々な側面を改善するための方向性のアイデアが含まれています。
この核となる記述は、最初の一連の概念実証の出発点として使用されることが想定されている。
最終的な「バージョン1.0」は、この洗練されたプロトコルをベースに、実証され、プロジェクトの目標達成に必要と判断された追加的なアイデアを加えたものとなる。

1.1.History.

09/10/2016: 0.1.0-proof1
20/10/2016: 0.1.0-proof2（英語
01/11/2016: 0.1.0-proof3（ゼロワン・プルーフ・スリー
10/11/2016: 0.1.0

2.紹介

ブロックチェーンは、「モノのインターネット」（IoT）、金融、ガバナンス、アイデンティティ管理、ウェブ分散化、資産追跡など、様々な分野で大きな有用性が期待されています。
しかし、技術的な期待や壮大な話とは裏腹に、現在の技術の重要な実世界への展開はまだ見られていない。
これは、現在の技術スタックが持つ5つの主要な欠点に起因していると考えています。スケーラビリティ：システムが1つのトランザクションを処理するために、処理、帯域幅、ストレージにどれだけのリソースがグローバルに費やされているか、またピーク時にどれだけのトランザクションを合理的に処理できるのか？分離性。複数の関係者やアプリケーションの多様なニーズに対して、同じフレームワークで最適に近い形で対応できるか？開発性: ツールはどの程度機能するか? APIは開発者のニーズに応えているか？教材は利用可能か？適切な統合がなされているか？ガバナンス。ネットワークは時間とともに進化し適応していく柔軟性を持ち続けることができるか？分散型システムの効果的なリーダーシップを発揮するために、十分な包括性、正当性、透明性を備えた意思決定が可能か? 適用性。その技術は、それ自体で切実なニーズに応えているか？実際のアプリケーションとのギャップを埋めるために、他の「ミドルウェア」が必要ではないか？今回の研究では、最初の2つの問題、すなわちスケーラビリティと分離可能性を解決することを目的としています。
とはいえ、Polkadotフレームワークは、これらの問題の各クラスで意味のある改善を提供できると考えています。
Parity Ethereumクライアント[17]のような最新の効率的なブロックチェーン実装は、性能の良い消費者向けハードウェアで実行すると、1秒間に3,000件を超えるトランザクションを処理することができます。
しかし、現在の実世界のブロックチェーンネットワークは、実質的に1秒間に約30件のトランザクションに制限されています。
この制限は主に、現在の同期コンセンサスメカニズムが、予想される処理時間に対して広いタイミングの安全マージンを必要とし、より遅い実装をサポートしたいという願望によって悪化しているという事実に起因しています。
状態遷移メカニズム、つまり当事者がトランザクションを照合・実行する手段は、コンセンサスの「正規化」メカニズム、つまり当事者がいくつかの有効な履歴のうちの1つに合意する手段と基本的に結びついているのです。
これは、Bitcoin [15] や Ethereum [5, 23] などのプルーフ・オブ・ワーク (PoW) システムにも、NXT [8] や Bitshares [12] などのプルーフ・オブ・ステーク (PoS) システムにも同様にあてはまり、最終的にはすべて同じハンデに悩まされることになります。
ブロックチェーンを成功に導いたのは、このシンプルな戦略です。
しかし、これら2つのメカニズムをプロトコルの単一ユニットに緊密に結合することで、リスクプロファイルが異なり、スケーラビリティ要件やプライバシーニーズも異なる複数の異なるアクターやアプリケーションを束ねることにもなってしまいます。
1つのサイズですべてに対応できるわけではありません。
多くの場合、ネットワークは広くアピールすることを望むあまり、保守主義を採用し、その結果、最小公倍数で少数の人に最適なサービスを提供し、最終的には革新、パフォーマンス、適応の能力を、時には劇的に低下させることになります。
Factom [21]のように、状態遷移のメカニズムを完全に削除するシステムもある。
しかし、我々が望む実用性の多くは、共有されたステートマシンに従って状態を遷移させる能力を必要とします。
この機構を削除することは、代替問題を解決することであり、代替解決策を提供することではありません。
したがって、スケーラブルな分散型計算プラットフォームへの道として、コンセンサス・アーキテクチャを状態遷移メカニズムから切り離すことが妥当な方向性であることは明らかだと思われます。
そして、おそらく驚くことではありませんが、これがPolkadotがスケーラビリティの解決策として採用している戦略なのです。

2.1.プロトコル、実装、ネットワーク。
ビットコインやイーサリアムと同様に、ポルカドットはネットワーク・プロトコルと、このプロトコルを実行する（これまで想定されていた）主要なパブリック・ネットワークを同時に指します。
ポルカドットはフリーでオープンなプロジェクトであることを意図しており、プロトコル仕様はクリエイティブ・コモンズ・ライセンスの下に、コードはFLOSSライセンスの下に置かれている。
このプロジェクトはオープンな方法で開発されており、有用なものであればどこでも貢献を受け付けます。
Python Enhancement Proposalsに似たRFCのシステムは、プロトコルの変更とアップグレードに関して公に協力する手段を可能にします。
私たちのポルカドット・プロトコルの初期実装は、Parityポルカドット・プラットフォームとして知られ、完全なプロトコル実装とAPIバインディングが含まれる予定です。
他のParityブロックチェーン実装と同様に、PPPは汎用ブロックチェーン技術スタックとして設計されており、パブリックネットワーク向けでもプライベート/コンソーシアム運用向けでもありません。
これまでの開発には、英国政府からの助成金を含む複数の関係者が資金を提供しています。
それにもかかわらず、このペーパーでは、公共ネットワークのコンテキストでポルカドットについて説明しています。
私たちが公共ネットワークで想定している機能は、他の環境（例えば、プライベートやコンソーシアム）で必要とされる機能の上位セットです。
さらに、このコンテキストでは、ポルカドットの全範囲をより明確に説明し、議論することができます。
これは、非公開の（「許可された」）状況で展開された場合にはポルカドットに直接関係しない特定のメカニズム（たとえば、他の公共ネットワークとの相互運用）が記述される可能性があることを読者が認識する必要があることを意味しています。

2.2. 以前の仕事
根本的なコンセンサスを状態遷移から切り離すことは、少なくとも2年前から非公式に私的に提案されています-Max KayeはEthereumのごく初期の頃にそのような戦略の提案者でした。
チェーンファイバーとして知られるより複雑でスケーラブルなソリューションは、2014年6月にさかのぼり、同年末に初めて公開されました1。これは、単一のリレーチェーンと複数の同質なチェーンが透明なチェーン間実行メカニズムを提供することを主張したものです。
非干渉性は、トランザクションのレイテンシーによって支払われました-システムの異質な部分の調整を必要とするトランザクションは、処理に時間がかかるでしょう。
ポルカドットは、そのアーキテクチャの多くを、その設計と条項の多くにおいて大きく異なるものの、このプロジェクトと様々な人々との対話から得ています。
ポルカドットに匹敵するようなシステムが実際に生産されているわけではありませんが、いくつかの関連するシステムが提案されています（詳細なレベルではほとんどありませんが）。
これらの提案は、グローバルにコヒーレントなステートマシンの概念を削除または削減するシステム、同種のシャードを通じてグローバルにコヒーレントなシングルマシンを提供しようとするシステム、異種性だけを対象とするシステムに分類することができます。

2.2.1.グローバル・ステートを持たないシステム。
Factom [21]は、一致する妥当性なしに正準性を示すシステムであり、事実上、データの慢性化を可能にする。
大域的な状態を回避し、それがもたらすスケーリングの困難さのため、スケーラブルな解決策とみなすことができる。
しかし、前述したように、それが解決する問題の集合は厳密かつ実質的に小さい。
Tangle [18]はコンセンサスシステムに対する新しいアプローチです。
トランザクションをブロックに整理し、厳密にリンクされたリストに対してコンセンサスを形成して状態変化のグローバルに正統な順序を与えるのではなく、大きく構造化された順序という考えを捨て、代わりに後の項目が明示的な参照を通じて前の項目の正統化を助ける依存トランザクションの無向グラフを推し進める。
任意の状態変化に対して、この依存関係グラフはすぐに難解になるが、はるかに単純なUTXOモデル2に対しては、これは非常に合理的である。
システムは緩やかにしかコヒーレントでなく、トランザクションは一般に互いに独立しているため、大量のグローバル並列処理がごく自然に行われるようになります。
UTXOモデルを使用すると、Tangleはより一般的で拡張可能なものではなく、純粋に価値伝達を行う「通貨」システムに限定されるという効果があります。
さらに、ハードなグローバル一貫性がなければ、システム状態に関する絶対的な知識を必要とする傾向にある他のシステムとの相互作用は、実用的ではなくなります。

2.2.2.Heterogeneous Chain Systems.
サイドチェーン[3]はビットコインプロトコルへの追加提案であり、メインビットコインチェーンと追加サイドチェーン間の信頼性のない相互作用を可能にするものである。
サイドチェーンの相互作用は、サイドチェーンが互いの資産のカストディアンとなり、地元の専門用語で言うところの「双方向ペッグ」3 を実現することに限定されるでしょう。
最終的なビジョンは、ビットコイン通貨が、ビットコインプロトコルよりも複雑な状態遷移システムを持つ他のチェーンにペグされることで、周辺機能とはいえ追加的に提供されるフレームワークであることです。
この意味で、サイドチェーンはスケーラビリティではなく、拡張性を重視しています。
実際、サイドチェーンの有効性については基本的に規定されていません。あるチェーン（例えばビットコイン）からのトークンがサイドチェーンのために保持される場合、サイドチェーンは有効な遷移を正規化するよう採掘者に動機を与える能力によってのみ安全が確保されるのです。
ビットコインネットワークのセキュリティは、他のブロックチェーンのために働くように簡単に移行することはできません。
さらに、Bitcoinの採掘者がmerge-mineすること（つまり、サイドチェーンの正規化能力を重複させること）、そしてさらに重要なことに、サイドチェーンの遷移を検証することを保証するプロトコルは、この提案の範囲外である。
Cosmos [10]はサイドチェーンと同様に提案されたマルチチェーンシステムで、Nakamoto PoWコンセンサス方式をJae Kwon氏のTendermintアルゴリズムに置き換えたものです。
基本的には、Tendermintの個々のインスタンスを使用する複数のチェーン（ゾーンで動作）を記述し、マスターハブチェーンを介して信頼性のない通信を行う手段を備えています。
このチェーン間通信は、任意の情報ではなく、デジタル資産（特にトークン）の転送に限定されます。しかし、このチェーン間通信には、転送の状況を送信者に報告するなどのデータのためのリターンパスがあります。
ゾーンチェーンのバリデータセット、特にインセンティブを与える手段は、サイドチェーンと同様、未解決の問題として残されています。
一般的な想定では、ゾーン化された各チェーンは、それ自体が価値のあるトークンを保持し、そのインフレはバリデータの支払いに使われる。
この提案はまだ設計の初期段階にあり、現時点では、グローバルな有効性をスケーラブルに確実なものにするための経済的手段に関する包括的な詳細が欠けている。
しかし、ゾーンとハブの間に要求される緩やかな一貫性により、より強い一貫性を強制するシステムと比較して、ゾーン化されたチェーンのパラメータにさらなる柔軟性を持たせることができるだろう。

2.2.3. キャスパー
Casper [6]とポルカドットの包括的なレビューや側面からの比較はまだ行われていませんが、この2つの特徴をかなり大まかに（そしてそれに応じて不正確に）説明することは可能です。
Casperは、参加者がどのフォークが最終的に標準になるかを賭けることに基づいて、PoSコンセンサスアルゴリズムを再構築したものです。
ネットワークフォークが長引いた場合でも堅牢であること、そして基本的なイーサリアムモデルの上にある程度のスケーラビリティを追加することに、多大な配慮がなされました。
そのため、これまでのCasperはポルカドットやその前身よりもかなり複雑なプロトコルになる傾向があり、基本的なブロックチェーン形式から大きく逸脱しているのが現状です。
今後、Casperがどのように進化していくのか、そして最終的にどのような形で展開されるのか、まだ見えていない。
Casperとポルカドットはどちらも興味深い新しいプロトコルで、ある意味Ethereumの拡張版と言えますが、最終的な目標と展開への道筋には大きな違いがあります。
CasperはEthereum財団を中心としたプロジェクトで、元々はプロトコルをPoSに変更するために設計されたもので、根本的にスケーラブルなブロックチェーンを作成する気はありません。
そのため、すべてのイーサリアムのクライアントとユーザーは、アップグレードするか、採用が不透明なフォークにとどまることを要求されます。
そのため、厳密な調整が必要な分散型プロジェクトにつきものの、展開が大幅に難しくなっています。
ポルカドットはいくつかの点で異なります。何よりもまず、ポルカドットは完全に拡張可能でスケーラブルなブロックチェーンの開発、展開、相互作用のテストベッドになるように設計されています。
新しいブロックチェーン技術が利用可能になったときに、過度に複雑な分散型調整やハードフォークを行うことなく、それを吸収できるような、ほぼ将来性のあるハーネスとして構築されています。
私たちはすでに、暗号化されたコンソーシアムチェーンや非常に短いブロックタイムによる高頻度チェーンなど、現在想定されているイーサリアムのどの将来バージョンでも実現不可能なユースケースをいくつか想定しています。
最後に、イーサリアムとの結合は極めて緩やかであり、2つのネットワーク間で信頼性の高い取引転送を可能にするためにイーサリアム側で必要な操作は一切ない。
つまり、Casper/Ethereum 2.0とポルカドットには一瞬の共通点がありますが、最終的なゴールは大きく異なり、競合するというよりは、最終的には当面の間、相互に有益な関係の下で共存する可能性が高いと考えています。

3.概要

ポルカドットはスケーラブルなヘテロジニアス・マルチチェーンです。
これは、潜在的なアプリケーションに対して様々な汎用性を持つ単一のチェーンを提供することに焦点を当てたこれまでのブロックチェーンの実装とは異なり、ポルカドット自体は固有のアプリケーション機能を全く提供しないように設計されていることを意味します。
むしろポルカドットは、検証可能でグローバルにコヒーレントな動的データ構造を数多く並べてホストできるような、基盤となる「リレーチェーン」を提供します。
このようなデータ構造を「並列化」チェーンまたはパラチェーンと呼びますが、ブロックチェーンである必要性は特にありません。
言い換えれば、ポルカドットは、2つの非常に重要な点を除いて、独立したチェーンのセット（例えば、イーサリアム、イーサリアムクラシック、ナメコイン、ビットコインを含むセット）と同等と見なすことができます。- プールされたセキュリティ、 – 信頼のないチェーン間取引可能性。
これらの点が、ポルカドットが「スケーラブル」であると考える理由です。
原理的には、ポルカドット上で展開される問題は、多数のパラチェーン上で実質的に並列化-スケールアウトされる可能性があります。
各パラチェーンのすべての側面は、ポルカドットネットワークの異なるセグメントによって並行して行われる可能性があるため、システムにはある程度のスケーラビリティがあります。
ポルカドットは、ミドルウェアレベルで対処すべき複雑さの多くを残した、かなり骨太なインフラストラクチャの一部を提供します。
これは開発リスクを減らすための意識的な決定で、必要なソフトウェアを短期間で開発し、そのセキュリティと堅牢性に十分なレベルの自信を持てるようにするためのものです。

3.1.Polkadot の理念。
ポルカドットは、生産可能な成熟した設計から初期のアイデアまで、リスクスペクトルを通して、コンセンサスシステムの次の波を構築するための絶対的な磐石な基盤を提供する必要があります。
ポルカドットは、セキュリティ、分離、通信に関する強力な保証を提供することで、パラチェーンがさまざまな特性を自ら選択することを可能にします。
実際、私たちは様々な実験的ブロックチェーンが、今日賢明と見なされるものの特性を押し広げていることを予見しています。
ビットコインやZ-cash [20]のような保守的で価値の高いチェーンが、価値の低い「テーマチェーン」（マーケティング的で楽しい）や手数料ゼロまたはゼロに近いテストネットと共存している姿が見えてきます。
完全に暗号化された「ダーク」なコンソーシアムチェーンが、イーサリアムのような高機能でオープンなチェーンと共存し、さらにはサービスを提供しているのを目にします。
また、より成熟したイーサリアムのようなチェーンや、より制限の多いビットコインのようなチェーンから難しい計算問題をアウトソーシングする手段として、主観的な時間課金型のワスムチェーンのような実験的な新しいVMベースのチェーンが使用されているのを見かけます。
チェーンのアップグレードを管理するために、ポルカドットは本質的にある種のガバナンス構造をサポートします。おそらく既存の安定した政治システムに基づき、黄紙会議[24]に似た二院制の側面を持つことになるでしょう。
最終的な権威として、基礎となるステイカブルトークンの保有者は「国民投票」によるコントロールを持つことになります。
ユーザーの開発ニーズと開発者の正当性ニーズを反映するために、我々は、「ユーザー」委員会（保証者により構成）と主要なクライアント開発者とエコシステムのプレーヤーにより構成される「技術」委員会の 2 議会を形成することが妥当な方向性であると予想しています。
トークン保有者は最終的な正当性を維持し、この構造を強化、再パラメータ化、置換、または解散するための超多数を形成することになりますが、これは最終的な必要性に疑いの余地はありません。
パラメータを変更することは、より大きなコンセンサスメカニズムの中では些細なことですが、置換や拡張といったより質的な変更は、非自動的な「ソフトディクリー」（例えば、ブロック番号の正規化、新しいプロトコルを正式に指定する文書のハッシュなど）か、コアコンセンサスメカニズムに、変更する必要があるあらゆる側面を記述できる十分な言語が必要になる場合が多いのです。
後者は最終的な目標ですが、合理的な開発スケジュールを立てるために前者を選択する可能性が高くなります。
ポルカドットの主要な信条と、すべての設計上の決定を評価する際のルールは次のとおりです。最小限のもの。ポルカドットは、できる限り少ない機能で構成されるべきです。
シンプル：ミドルウェアへのオフロード、パラチェーンによる配置、あるいは後の最適化で導入することが合理的である以上に、基本プロトコルに追加の複雑性を持たせるべきではありません。
ポルカドットは、コンセンサスシステム開発のためのテストベッドであるべきで、拡張機能を組み込むモデルをできるだけ抽象化することによって最適化されます。
堅牢であること。ポルカドットは、基本的に安定したベースレイヤーを提供する必要があります。
これは、経済的な健全性に加えて、高報酬の攻撃のベクトルを最小化するための分散化も意味します。

4.ポルカドットへの参加

ポルカドット・ネットワークの維持には、コレーター、フィッシャーマン、ノミネーター、バリデーターという4つの基本的な役割があります。
ポルカドットのある実装では、後者の役割は、実際には、基本的な検証者と利用可能性の保証者の2つの役割に分解されるかもしれない。

4.1. バリデーター
バリデータは最高額の課金者であり、ポルカドットネットワーク上で新しいブロックを封印するのを助ける。
バリデータの役割は、十分な量の保証金が預けられることを条件とするが、他の被保証者がバリデータを指名することも可能であり、バリデータの保証金の一部は、必ずしもバリデータ自身ではなく、指名された者が所有することになる。
バリデータは、高い可用性とバンド幅を持つリレーチェーンクライアントの実装を実行しなければならない。
各ブロックにおいて、ノミニーのパラチェーン上の新しいブロックを批准する役割を引き受ける準備が出来ていなければならない。
このプロセスには、候補ブロックの受信、検証、再パブリッシュが含まれます。
ノミネートは決定論的であるが、事実上、ずっと前から予測できない。
バリデータはすべてのパラチェーンについて完全に同期されたデータベースを維持することは合理的に期待できないので、バリデータは新しいパラチェーンブロックの候補をコレーターと呼ばれる第三者に指名することが予想される。
新しいパラチェーンブロックがすべて指定されたバリデータ部会で適切に批准された後、バリデータはリレーチェーンブロックそのものを批准しなければならない。
これには、トランザクションキューの状態を更新し(基本的にパラチェーンの出力キューから別のパラチェーンの入力キューにデータを移動する)、批准済みのリレーチェーン・トランザクションセットのトランザクションを処理し、最終パラチェーンの変更を含む最終ブロックを批准することが含まれる。
我々が選んだコンセンサスアルゴリズムのルールのもとで合意を見出す義務を果たさないバリデータは罰せられる。
最初の、意図的でない失敗に対しては、バリデータの報酬を差し控える。
失敗を繰り返すと、セキュリティボンドが減らされる（バーニング）。
二重署名や無効なブロックを提供するための共謀など、証明可能な悪意ある行為は、保証金全体を失うことになる(保証金は一部焼却されるが、大部分は情報提供者と誠実な行為者に渡される)。
ある意味でバリデーターは、現在のPoWブロックチェーンのマイニングプールに類似している。

4.2. ノミネーター
ノミネータとは、バリデータのセキュリティボンドに貢献するステークホルダーである。
ノミネータはリスクキャピタルを提供する以外には何の役割も持たず、特定のバリデータ（またはその集合）がネットワークの維持に責任を持って行動することを信頼していることを表明するものである。
バリデータは、債券の成長に応じて、預託金の比例配分による増減を受ける。
次に、コレーターとともに、ノミネーターは、ある意味で現在のPoWネットワークの採掘者に似ている。

4.3. コレーター
取引コレーター(Transaction Collator、略してCollator)は、バリデータが有効なパラチェーンブロックを生成するのを支援する当事者である。
つまり、現在のPoWブロックチェーンで採掘者が行っているのとほぼ同じ方法で、新しいブロックを作成し、取引を実行するために必要なすべての情報を保持しているのである。
通常の場合、彼らは取引を照合・実行して封印されていないブロックを作成し、それをゼロ知識証明とともに、現在パラチェーンブロックを提案する責任を負う1人または複数のバリデーターに提供する。
コレーター、ノミネーター、バリデーターの関係の正確な性質は、おそらく時間の経過とともに変化する。
当初は、取引量の少ないパラチェーンが少数（おそらく1つ）しか存在しないため、照合人と検証人が非常に緊密に連携することが予想される。
初期のクライアント実装には、パラチェーンコレーターノードが（リレーチェーン）バリデータノードに証明可能な有効なパラチェーンブロックを無条件で提供するためのRPCが含まれる予定です。
このようなすべてのパラチェーンの同期バージョンを維持するコストが増加するにつれて、経済的に動機づけられた独立したパーティーに任務を分離するのに役立つ、追加のインフラが整備されることを期待しています。
最終的には、取引手数料を最も多く徴収するために競い合うコレーター・プールが出現すると予想されます。
このような照合人は、特定のバリデータに一定期間サービスを提供する契約を結び、継続的に報酬を受け取ることができる。
あるいは、「フリーランス」の照合人は、有効なパラチェーンブロックを提供する市場を創設し、その見返りとして、すぐに支払われる報酬を競争的に分け合うこともできる。
同様に、分散化されたノミネータープールでは、複数のボンド参加者が調整し、バリデーターの任務を分担することができる。
このプール機能により、より分散化されたシステムへのオープンな参加が保証される。

4.4. フィッシャーマン
他の2つの活動当事者とは異なり、漁師はブロックオーサリングプロセスに直接関係しない。
むしろ彼らは、大きな単発の報酬に動機づけされた独立した “賞金稼ぎ “である。
まさにfishermanの存在のために、我々は、不品行がめったに起こらないこと、そして起こったとしても、悪意によるものではなく、ボンドパーティが秘密鍵のセキュリティに不注意であることによるものであることを期待する。
名前の由来は、期待される報酬の頻度、参加するための最小限の条件、最終的な報酬の大きさである。
漁師は、少なくとも1人の被保証者が違法行為を行ったことを適時に証明することで、報酬を得ることができる。
違法行為とは、同じ批准親を持つ2つのブロックにそれぞれ署名することや、パラチェーンの場合、無効なブロックの批准を手助けすることなどが挙げられる。
過剰な報酬や、セッションの秘密鍵の漏洩と不正使用を防ぐため、1人のバリデータが不正に署名したメッセージを提供した場合の基本報酬は最小である。
この報酬は、他のバリデータから本物の攻撃を示唆する不正な署名が提供されるほど、漸近的に増加する。
バリデータの少なくとも2/3が善良に振る舞うという、我々の基本的なセキュリティの主張に従って、漸近線は66%に設定される。
フィッシャーマンは、現在のブロックチェーンシステムにおける「フルノード」に類似しており、必要なリソースが比較的小さく、安定した稼働時間や帯域幅のコミットメントが必要でない。
フィッシャーマンは、少額の保証金を支払う必要がある点が異なります。
このボンドは、バリデータの時間と計算資源を浪費させるシビル攻撃を防ぐ。
この保証金はすぐに引き出すことができ、おそらく数ドル程度であろうが、悪さをするバリデータを発見した場合には、高額な報酬を得ることができる。

5.設計概要

このセクションは、システム全体の概要を説明することを目的としている。
システムのより詳細な検討は、その次のセクションで行う。

5.1. コンセンサス
リレーチェーン上で、ポルカドットは最新の非同期ビザンチン耐故障（BFT）アルゴリズムによって、相互に合意した有効ブロックの集合に対する低レベルのコンセンサスを実現する。
このアルゴリズムは、シンプルなTendermint [11]と、実質的により複雑なHoneyBadgerBFT [14]に触発されたものである。
後者は、ほとんど良性の権威または検証者のセットが与えられたときに、任意の欠陥のあるネットワークインフラ上で効率的かつ耐故障性のあるコンセンサスを提供する。
PoAスタイルのネットワークでは、これだけで十分ですが、ポルカドットは、特定の組織や信頼できる権威を必要としない、完全にオープンで公的な状況のネットワークとして展開することができると考えられています。
そのため、検証者のセットを決定し、誠実であるようにインセンティブを与える手段が必要です。
そのために、PoSに基づく選択基準を利用する。

5.2. ステークを証明する
ネットワークには、特定のアカウントがどれだけの「賭け金」を持っているかを測定する何らかの手段があると仮定します。
既存のシステムとの比較を容易にするために、測定単位を「トークン」と呼ぶことにします。
残念ながら、この用語は、アカウントに関連する単なるスカラー値であるため、個性の概念がないなど、多くの理由から理想的とはいえない。
バリデータは、NPoS (Nominated Proof-of-Stake) スキームにより、不定期（多くても1日1回、少ない場合は四半期に1回）に選出されるものと考える。
インセンティブは、トークン・ベースの拡大による資金の比例配分（最大で年間100%、ただし10%程度が望ましい）と、徴収した取引手数料によって実現することができる。

一般的にマネタリーベースの拡大はインフレにつながりますが、すべてのトークン所有者に公平な参加の機会が与えられるため、コンセンサスメカニズムに喜んで参加すれば、保有するトークンの価値が時間とともに減少することはありません。
特定の割合のトークンがステークプロセスのターゲットとなり、このターゲットに到達するために、市場ベースのメカニズムを通じて有効なトークン・ベースの拡大が調整されます。
バリデータはその賭け金によって大きな絆で結ばれている。退出したバリデータの債券は、バリデータの任務が終了した後もずっと残っている（おそらく3ヶ月程度）。
この長い債券償還期間により、将来的な不品行を、チェーンの定期的なチェックポイントまで罰することができる。
不正行為により、報酬の減額や、ネットワークの整合性を故意に損ねた場合には、バリデータは他のバリデータ、情報提供者、利害関係者全体に対して、一部または全部の持ち分を失う (焼却処分)などの処罰が下される。
例えば、フォークの両ブランチを批准しようとするバリデータ(「短距離攻撃」とも呼ばれる) は、後者の方法で特定され、処罰される可能性がある。
長距離の「何もしない」攻撃4 は、単純な「チェックポイント」ラッチによって回避され、特定の鎖の深さを超える危険な鎖の再編成を防ぐことができる。
新しく接続されたクライアントが間違ったチェーンに誘導されないように、定期的に「ハードフォーク」を行い、最近のチェックポイントのブロックハッシュをクライアントにハードコーディングする（最大でバリデータの債券清算期間と同じ）。
これは、「有限のチェーンの長さ」または定期的な生成ブロックのリセットという、さらに足跡を減らす方法とうまく調和する。

5.3.Parachain と Collator。
パラチェーンのヘッダーはリレーチェーンブロック内に封印され、確認後に再編成や “二重支出 “ができないようになっています。
これは、ビットコインのサイドチェーンやマージマイニングが提供するセキュリティと同様の保証です。
しかし、ポルカドットでは、パラチェーンの状態遷移が有効であることも強く保証しています。
これは、検証者のセットを暗号的にランダムに分割し、パラチェーンごとに1つのサブセットを作成し、サブセットはブロックごとに異なる可能性があります。
この設定は一般に、パラチェーンのブロック時間が少なくともリレーチェーンと同程度になることを意味する。
パーティショニングを決定する具体的な方法は本書の範囲外であるが、RanDAO [19]に類似したコミット・リベールフレームワークに基づくか、暗号的に安全なハッシュの下で各パラチェーンの以前のブロックから組み合わせたデータを使用するかのいずれかであろう。
このようなバリデータのサブセットは、有効性が保証されたパラチェーンブロック候補を提供する必要がある(債券の没収を覚悟の上で)。
1つ目は、本質的に有効であること、すなわちすべての状態遷移が忠実に実行され、参照されるすべての外部データ（すなわちトランザクション）が有効であることである。
第二に、外部トランザクションのような候補の外部にあるデータは、参加者がそれをダウンロードして手動でブロックを実行できるように、十分に高い可用性を備えていることである。
5 妥当性確認者は、外部の「取引」データを含まない「ヌル」ブロックのみを提供することもできるが、そうすると報酬が減少するリスクがある。
Validatorはパラチェーンゴシッププロトコルと連携し、コレーター（取引をブロックに照合し、ブロックがその親の有効な子であることを非対話的かつゼロ知識で証明する個人）と共に行動する（そしてそのための取引手数料を受け取る）。
リレーチェーンが課す「計算機資源の計量」や「取引手数料」という基本的な概念はない。
また、リレーチェーンプロトコルによる直接的な強制もありません（ただし、関係者が適切なメカニズムを提供しないパラチェーンを採用することはあり得ません）。
これは、イーサリアムとは異なるチェーン、例えば、よりシンプルな手数料モデルを持つビットコインのようなチェーンや、他のまだ提案されていないスパンプ防止モデルの可能性を明示的に示しているのです。
ポルカドットのリレーチェーン自体は、おそらくイーサリアムのようなアカウントと状態のチェーンとして存在し、おそらくEVMderivativeになるでしょう。
リレーチェーンノードは他の実質的な処理を行う必要があるため、取引スループットは部分的に大きな取引手数料と、研究モデルが必要とする場合にはブロックサイズ制限によって最小化されるでしょう。

5.4. チェーン間通信。
ポルカドットの最後の重要な要素は、チェーン間通信です。
パラチェーン同士はある種の情報チャネルを持つことができるので、ポルカドットはスケーラブルなマルチチェーンであると考えることができます。
ポルカドットの場合、通信は非常にシンプルです。パラチェーンで実行されるトランザクションは、（そのチェーンのロジックに従って）第2のパラチェーン、あるいは潜在的にはリレーチェーンにトランザクションをディスパッチすることが可能なのです。
本番ブロックチェーンの外部トランザクションと同様に、パラチェーンは完全に非同期であり、何らかの情報を発信元に戻す機能は本質的に存在しない。

最小限の実装の複雑さ、最小限のリスク、および将来のパラチェーンアーキテクチャのストレートジャケットを確実にするために、これらのインターチェーントランザクションは、標準的な外部署名付きトランザクションと事実上区別がつかない。
取引はパラチェーンを識別する機能を提供するオリジンセグメントと、任意のサイズにすることができるアドレスを持つ。
ビットコインやイーサリアムのような一般的な現行システムとは異なり、インターチェーン取引には何らかの手数料の「支払い」が伴うことはない。そのような支払いは、送信元と送信先のパラチェーンの交渉ロジックによって管理されなければならない。
EthereumのSerenityリリース[7]で提案されたようなシステムは、このようなクロスチェーンのリソース支払いを管理するシンプルな手段となるでしょうが、いずれは他のものも登場すると思われます。
チェーン間取引は、忠実性を確保するためにMerkle木を中心としたシンプルなキューイング機構を使用して解決されます。
あるパラチェーンの出力キューにあるトランザクションを、送信先のパラチェーンの入力キューに移すのは、リレーチェーンメンテナーの仕事である。
渡されたトランザクションはリレーチェーン上で参照されますが、リレーチェーントランザクションそのものではありません。
あるパラチェーンが他のパラチェーンにトランザクションのスパムをかけるのを防ぐため、トランザクションを送信するためには、前のブロックの終了時に送信先の入力キューが大きすぎないことが必要である。
ブロック処理後に入力キューが大きすぎる場合、それは「飽和」とみなされ、制限値以下になるまで、後続のブロック内でトランザクションがルーティングされない可能性があります。
これらのキューはリレーチェーン上で管理され、パラチェーンは互いの飽和状態を判断することができる。このようにして、停滞した宛先へのトランザクション投稿の失敗が同期的に報告されることがある。
(ただし、戻り経路が存在しないので、その理由で二次トランザクションが失敗した場合、元の呼び出し元に報告することはできず、他の回復手段を取らなければならない)。

5.5. ポルカドットとイーサリアム
Ethereumのチューリング完全性により、少なくとも簡単に推測できるセキュリティの範囲内で、ポルカドットとEthereumが互いに相互運用できる十分な機会があることを期待しています。
つまり、ポルカドットからのトランザクションはバリデータによって署名され、その後イーサリアムに送り込まれ、そこでトランザクション転送契約によって解釈され実行されることが想定されるのである。
別の方向では、特定のメッセージが転送されるべきかどうかを迅速に検証できるように、「脱走契約」から来る特別にフォーマットされたログ（イベント）の使用を予見している。

5.5.1. ポルカドットからイーサリアムへ。
承認投票メカニズムによって決定された利害関係者の集合から形成されたバリデーターを持つBFTコンセンサスメカニズムの選択を通じて、我々は、頻繁に変更されず控えめな数のバリデーターで安全なコンセンサスを得ることができます。
144人のバリデータ、4秒のブロックタイム、900ブロックのファイナリティ（二重投票のような悪意のある行為を報告、処罰、修復することが可能）を持つシステムでは、ブロックの有効性はわずか97の署名（144の2/3＋1）、およびチャレンジが寄託されていない次の60分の検証期間によって合理的に証明されると考えることができる。
イーサリアムは、144人の署名者を維持し、彼らによって制御されることができる「ブレークイン・コントラクト」をホストすることができます。
楕円曲線デジタル署名（ECDSA）の復元にはEVMで3,000ガスしかかからないため、また検証は（全会一致ではなく）検証者の超多数で行われることが望ましいため、ある命令がポルカドットネットワークからのものとして適切に検証されたことをイーサリアムが確認する基本コストは30万ガス以下、ブロックガスの合計上限550万のわずか6％にしかなりません。
検証者の数を増やせば（数十のチェーンに対応するために必要）必然的にこのコストは増加しますが、イーサリアムの取引帯域幅は技術の成熟とインフラの改善に伴い、時間とともに拡大することが広く予想されます。
また、すべてのバリデータが関与する必要はない（例えば、最も高いステークを持つバリデータのみがこの作業に呼ばれるかもしれない）ため、この仕組みの限界は合理的に拡張可能である。
このようなバリデーターを毎日交代で配置すると仮定すると（これはかなり保守的で、毎週あるいは毎月でも可）、このイーサリアム転送ブリッジを維持するためのネットワークへのコストは、1日あたり約54万ガス、現在のガス価格では年間45ドルであろう。
ブリッジを経由して転送される基本的な取引は約0.11ドルで、追加の契約計算には当然ながらもっとコストがかかる。
トランザクションをバッファリングしてバンドルすることで、ブレークイン・オーソリティ・コストを容易に共有でき、トランザクションあたりのコストを大幅に削減できる。転送前に20トランザクションが必要であれば、基本トランザクションの転送コストは約0.01ドルにまで低下するだろう。
このマルチシグネチャ契約モデルの興味深い、かつ安価な代替案は、マルチラテラル・オーナーシップ・セマンティクスを実現するために、閾値署名を使用することである。
ECDSA の閾値署名方式は計算コストが高いですが、Schnorr 署名のような他の方式では非常に合理的です。
Ethereumは、来るべきMetropolisハードフォークで、このような方式を安価に利用できるプリミティブを導入する予定です。
もしそのような手段を利用することができれば、ポルカドット取引をイーサリアムネットワークに転送するためのガスコストは劇的に削減され、署名を検証して基礎となる取引を実行するための基本コスト以上のオーバーヘッドをほぼゼロにできるだろう。
このモデルでは、ポルカドットのバリデータノードはメッセージに署名すること以外にはほとんど何もする必要がありません。
トランザクションを実際にイーサリアムネットワークにルーティングさせるために、バリデータ自身もイーサリアムネットワークに常駐するか、より可能性の高い方法として、メッセージをネットワークに転送した最初のアクターに少額の報奨金を提供する（報奨金は取引の発信者に支払われることもある）ことを想定している。

5.5.2. イーサリアムからポルカドットへ
EthereumからPolkadotにトランザクションを転送するには、単純なログの概念を使用します。
イーサリアムのコントラクトがポルカドットの特定のパラチェーンにトランザクションをディスパッチしたい場合、それは単に特別な「ブレイクアウトコントラクト」を呼び出すだけでよい。
ブレイクアウト・コントラクトは、必要とされる可能性のあるあらゆる支払いを受け取り、その存在がメルクル証明と対応するブロックのヘッダーが有効かつ正規であるという主張を通じて証明されるように、ロギング命令を発行する。
後者の2つの条件のうち、有効性はおそらく、証明するのが最も簡単である。
原理的には、証明を必要とする各ポルカドット・ノード（すなわち指定されたバリデータ・ノード）が、標準的なイーサリアム・ノードの完全に同期したインスタンスを実行していることが唯一の要件である。
残念ながら、これはかなり重い依存関係です。
より軽量な方法としては、ブロック内のトランザクションを適切に実行し、（ブロック受信に含まれる）ログが有効であることを確認するために必要なイーサリアムの状態トライの一部のみを提供することによって、ヘッダーが正しく評価されたという単純な証明を使用することである。
ポルカドット内のボンドシステムは、他の第三者（「フィッシャーマン」等、6.2.3参照）がヘッダーが無効である（特にステートルートやレシートルートが偽者である）証明を提供した場合、ボンドを失うリスクで、ボンドされた第三者がヘッダーを提出できるようにします。
Ethereumのような非最終的なPoWネットワークでは、正準性を決定的に証明することは不可能である。
これに対処するため、何らかのチェーン依存の因果関係に頼ろうとするアプリケーションは、「確認」の回数、または依存するトランザクションがチェーン内のある特定の深さに達するまで待ちます。
イーサリアムでは、この深さは、ネットワークの問題が知られていない最も価値の低い取引のための1ブロックから、取引所向けの最初のフロンティアリリース時のような1200ブロックまで様々です。
安定した「Homestead」ネットワークでは、この数値はほとんどの取引所で120ブロックに収まっており、私たちも同様のパラメータを取る可能性が高いでしょう。
つまり、イーサリアムネットワークから新しいヘッダーを受け入れ、PoWを検証することができ、十分な深さのヘッダーに対してイーサリアム側のブレイクアウト契約によって特定のログが発行されたという証明を受け入れることができ（そしてポルカドット内で該当メッセージを転送）、最後に以前受け入れられたがまだ実行されていないヘッダーに無効な受信ルートが含まれているという証明を受け入れることができるようになることで、ポルカドット側イーサリアムインターフェイスにいくつかの簡単な機能があると考えられるのです。
実際にEthereumヘッダーデータ自体（およびSPV証明や有効性/正統性の反論）をポルカドットネットワークに取り込むには、データを転送するためのインセンティブが必要です。
これは、ヘッダーが有効である有用なブロックを転送できた人に支払われる（イーサリアム側で収集した手数料で賄われる）支払いのような単純なものでもよい。
検証者は、プロトコルに内在する手段やリレーチェーン上で維持される契約を通じて、フォークを管理できるように、最後の数千ブロックに関連する情報を保持することが要求される。

5.6.Polkadot と Bitcoin。
ビットコインの相互運用は、ポルカドットにとって興味深い課題を提示します。いわゆる「双方向ペグ」は、両ネットワークの側で持つべき便利なインフラです。
しかし、ビットコインの制限により、そのようなペグを安全に提供することは、自明なことではありません。
ビットコインからポルカドットへのトランザクションの配信は、原理的にはイーサリアムと同様のプロセスで行うことができます。ポルカドットの検証者が何らかの方法で管理する「ブレイクアウトアドレス」が、転送されたトークン（およびそれに付随して送信されるデータ）を受け取ることができます。
SPV の証明はインセンティブ付きのオラクルによって提供され、確認期間とともに、取引が「二重支出」されたことを示唆する非正規のブロックを特定すると報奨金が与えられる可能性があります。
その後、「ブレイクアウトアドレス」に所有されたトークンは、原則的に同じバリデーターによって管理され、後に分散されることになる。
しかし、問題はどのようにしたら回転するバリデータから預金を安全に管理できるかである。
署名の組み合わせで任意に判断できるイーサリアムとは異なり、ビットコインは実質的に制限されており、ほとんどのクライアントが最大3者のマルチ署名取引しか受け付けない。
これを36人、あるいは最終的に希望する数千人にまで拡大することは、現在のプロトコルでは不可能である。
1つの選択肢は、そのような機能を可能にするためにビットコインのプロトコルを変更することですが、ビットコインの世界でいわゆる「ハードフォーク」は、最近の試みから判断して手配するのが困難です。
1つの可能性は、閾値署名の使用です。これは、1つの識別可能な公開鍵が複数の秘密の「部分」によって効果的に制御されるようにする暗号方式で、有効な署名を作成するためにはその一部または全部を利用する必要があります。
残念ながら、BitcoinのECDSAと互換性のある閾値署名は、作成に計算量が多く、複雑さも多項式となります。
シュナー署名のような他のスキームははるかに低いコストを提供しますが、それらがビットコインのプロトコルに導入される可能性があるスケジュールは不明です。
預金の最終的なセキュリティは、多数のバリデータに依存しているため、他の選択肢の1つは、マルチ署名の鍵保持者をバリデータ全体のうち緊密に結合した部分集合のみに減らし、閾値署名が実現可能になるようにすることである（または、最悪の場合、ビットコインのネイティブマルチ署名が実現可能となる）。
これはもちろん、バリデータが不正を行った場合に賠償金として差し引かれる債券の総額を減らすことになるが、これは猶予のある劣化であり、2つのネットワーク間で安全に運用できる資金の上限を設定するだけである（実際、バリデータからの攻撃が成功した場合の損失の割合を設定するだけである）。
そのため、2つのネットワーク間に合理的に安全なビットコイン相互運用性「仮想パラチェーン」を配置することは非現実的ではないと考えるが、それでも不確定なスケジュールでかなりの努力が必要であり、そのネットワーク内のステークホルダーの協力が必要になる可能性が高い。

6.プロトコルの深層

プロトコルは、コンセンサスメカニズム、パラチェーンインターフェース、チェーン間トランザクションルーティングの3つの部分に大別される。

6.1.Relay-chain Operation.
リレーチェーンは、アドレスとアカウント情報、主に残高と（リプレイを防ぐための）取引カウンターをマッピングしたステートベースである点で、イーサリアムとほぼ同様のチェーンとなる可能性が高い。
アカウントをここに置くことで、どのIDがどの程度のステークをシステムに所有しているかという会計処理を行うという1つの目的が達成される。
7 しかし、顕著な違いがある。- コントラクトはトランザクションを通じて展開できない。また、リレーチェーン上のアプリケーション機能を避けたいため、コントラクトの公開展開には対応しない。
ー計算資源の使用量（ガス）は計上されない。公開されるのは固定機能だけなので、ガス計上の根拠はもはや成り立たない。
そのため、すべてのケースで定額料金が適用され、動的なコード実行が必要な場合でも、より高いパフォーマンスと、よりシンプルなトランザクション形式が可能になります。
ー上場契約では、自動実行とネットワークメッセージの出力を可能にする特別な機能がサポートされています。
リレーチェーンがVMを持ち、EVMをベースにしている場合、最大限の単純性を確保するために多くの変更が加えられる。
おそらく、コンセンサス契約、バリデータ契約、パラチェーン契約など、プラットフォーム固有の義務を管理できるように、（イーサリアムのアドレス1〜4のような）多くの契約が組み込まれているはずです。
EVMでない場合、WebAssembly[2]（wasm）バックエンドが最も可能性の高い選択肢です。この場合、全体構造は似ていますが、EVMの未熟で限られた言語ではなく、Wasmが汎用言語のターゲットとして有効であるため、組み込みの契約は不要になるでしょう。
例えば、Serenityシリーズで提案されたように、同一ブロック内で競合しないトランザクションの並列実行を可能にするトランザクション受信形式の簡素化など、現在のイーサリアムプロトコルからの逸脱は十分に考えられる。
Serenityのような「純粋な」チェーンがリレーチェーンとして展開され、特定のコントラクトがチェーンのプロトコルの基本部分ではなく、ステーキングトークンの残高のようなものを管理できるようになる可能性は低いものの、あります。
現在のところ、私たちはこの方法が、開発に伴う複雑さと不確実性に見合うだけの十分なプロトコルの簡素化をもたらすとは思えないと感じています。
コンセンサスメカニズム、バリデータセット、バリデーションメカニズム、パラチェーンを管理するために必要ないくつかの小さな機能があります。
これらはモノリシックなプロトコルでまとめて実装することができる。
しかし、モジュール性を高める理由から、我々はこれらをリレーチェーンの「契約」と表現する。
これは、リレーチェーンのコンセンサスメカニズムによって管理されるオブジェクト（オブジェクト指向プログラミングの意味で）であることを意味するが、必ずしもEVMのようなオペコードでプログラムとして定義されているわけではなく、アカウントシステムを通じて個別にアドレス指定できるわけでもないと考えるべきである。

6.2.Staking 契約。
この契約はバリデータセットを管理する。
管理対象は以下のとおり。- どのアカウントが現在バリデータであるか – 短期間でバリデータになることが可能か – どのアカウントがバリデータを指名してステークを置いたか – ステーキング量、許容ペイアウト率、アドレス、短期間(セッション)のIDなどの各プロパティ。
アカウントは、ボンドバリデータになることを希望し(その要件とともに)、あるIDにノミネートを行い、既存のボンドバリデータはこの状態から抜けることを希望することを登録することができる。
また、バリデーションと正規化の仕組みそのものも含まれる。

6.2.1. ステーク・トークンの流動性
これはネットワークの安全性を杭打ちトークンの全体的な「時価総額」に直接結びつけるため、一般的にはネットワーク保守作業内でできるだけ多くの杭打ちトークンを持つことが望ましいとされています。
これは、通貨を膨張させ、その収益をバリデーターとして参加した人に渡すことで容易に動機付けることができます。
しかし、そうすることで問題が生じます。トークンが削減の罰を受けてステーキング契約にロックされた場合、価格発見を可能にするために、どのようにして相当部分を十分に流動的に保つことができるでしょうか。これに対する1つの答えは、基礎となるステーク・トークンの上に交換可能なトークンを確保する、単純なデリバティブ契約を認めることです。
これはトラストフリーな方法でアレンジすることが困難です。
さらに、ユーロ圏の異なる国債がカンジブルでないのと同じ理由で、これらのデリバティブ・トークンは平等に扱えません。
ユーロ圏の政府では、債務不履行が発生する可能性がある。
バリデーターがステークしたトークンでは、バリデーターが悪意を持って行動し、処罰される可能性がある。
我々の信条に従い、最も単純な解決策を選択する。すなわち、すべてのトークンにステークを付けないことである。
これは、ある割合（おそらく20%）のトークンが強制的に流動性を保つことを意味します。
これはセキュリティの観点からは不完全ですが、ネットワークのセキュリティに根本的な違いをもたらすことはないでしょう。100%ステークする「完璧なケース」に比べれば、債券没収による賠償金の80%はまだ可能でしょう。
ステークされたトークンと流動的なトークンの比率は、リバースオークションメカニズムによって非常に簡単にターゲットにすることができます。
基本的に、バリデーターになることに関心のあるトークン保有者は、参加するために必要な最低限のペイアウト率を明記したオファーを、ステーク契約に対してそれぞれポストする。
各セッションの開始時に（セッションは定期的に、おそらく1時間に1回）、各バリデーター候補の賭け金とペイアウト率に応じて、バリデーター枠が埋まっていく。
このための一つの可能なアルゴリズムは、対象となる賭け金の合計をスロット数で割ったものより高くなく、かつその半分より低くならない賭け金を示す、最も低い申し出のある人を選ぶというものである。
スロットが埋まらない場合は、下限を満たすために何らかの要因で繰り返し減少させることができる。

6.2.2. 指名すること
アクティブなバリデータに対して、信頼なくステークトークンを指名し、バリデータの業務を任せることが可能である。
ノミネートは、承認投票システムを通じて行われる。
各ノミネーターは、ステーキングコントラクトに、自分の債券を預けるバリデーターを1人以上指定することができます。
各セッションにおいて、ノミネーターの債券は1人または複数のバリデーターに分散して預けられる。
分散アルゴリズムは、債券の総額が等しくなるようにバリデーターを最適化する。
ノミネータの債券はバリデータの責任下に置かれ、それに応じて利子を得たり、罰を減らしたりする。

6.2.3. 保証金の没収/焼却
ある種のバリデータの振る舞いは、罰則としてそのバリデータの保証金を減らすことになる。
保証金が許容最小値より少なくなった場合、そのセッションは早々に終了し、次のセッションが開始される。
処罰の対象となるバリデーターの不品行には、以下のようなものがあります。- パラチェーンブロックの有効性について合意できないパラチェーングループに所属すること – 無効なパラチェーンブロックの有効性について積極的に署名すること – 以前に利用可能と投票されたegressペイロードを供給できないこと – 合意プロセス中の不活動 – 競合のフォーク上のリレーチェーンブロックを検証すること – などである。
不正行為の中には、ネットワークの完全性を脅かすものがあり（無効なパラチェーンブロックに署名したり、フォークの複数の側を検証したり）、その結果、絆の完全な縮小によって効果的な追放が行われます。
その他の、それほど深刻ではないケース（例：合意形成プロセスにおける非活動）や、責任を正確に負えない場合（非効率なグループの一員であること）には、代わりに保証金の一部が罰金として支払われることがあります。
後者の場合、悪意のあるノードが共謀して損害を受けた善意のノードよりも実質的に多くの損失を被ることを保証するために、サブグループの解約とうまく連動する。
いくつかの場合(例.
各パラチェーンブロックを常に検証するのは大変な作業であるため、バリデータ自身ではお互いの不正を容易に発見できない場合がある(マルチフォーク検証や無効なサブブロックへの署名など)。
そこで、検証プロセスの外部にいる関係者の協力を得て、そのような不正行為を検証し報告する必要がある。
報告者には報酬が与えられる。「漁夫の利」という言葉は、このような報酬が得られないことに由来する。
このようなケースは一般的に非常に深刻なので、報酬は没収された債券から簡単に支払われることを想定しています。
一般に、我々は全面的な再配分を試みるよりも、焼却（つまり無に帰すこと）と再配分のバランスをとることを好む。
これは、トークンの全体的な価値を高める効果があり、発見に関与した特定の当事者ではなく、ネットワーク全般をある程度補償することになります。
これは主に安全機構として機能します。多額のトークンが単一のターゲットに付与されると、極端で深刻な行動の誘因になる可能性があります。
一般に、報酬はネットワークにとって検証の価値を高めるのに十分な大きさであることが重要であるが、不運な検証者に不品行を強いるために、十分な資金と組織力を備えた「産業レベル」の犯罪的ハッキング攻撃を行うコストを相殺できるほど大きくないことが必要である。
このように、不正を行い、報奨金を得るために自ら報告するという逆インセンティブが生じないよう、請求額は一般に不正を行ったバリデータの直接の保証額より大きくならないようにする必要がある。
これは、バリデータになるための直接の保証の最低条件を明示的に定めるか、または推薦者を教育して、保証がほとんどないバリデータには良い行いをするインセンティブがあまりないことを暗黙的に教えることで、防ぐことができるだろう。

6.3.Parachain Registry.
各パラチェーンはこのレジストリに定義されています。
これは比較的単純なデータベースのような構造で、各チェーンに関する静的および動的な情報を保持します。
静的情報には、チェーンインデックス(単純な整数)、検証プロトコルID、パラチェーンの異なるクラスを区別する手段などがあり、有効な候補を提示することを委託されたバリデータが正しい検証アルゴリズムを実行できるようにする。
最初の概念実証では、新しい検証アルゴリズムをクライアント自体に組み込むことに重点を置き、チェーンのクラスが追加されるたびにプロトコルのハードフォークが必要になります。
しかし最終的には、検証アルゴリズムを厳密かつ効率的に規定することで、クライアントがハードフォークすることなく新しいパラチェーンを効果的に扱うことができるようになるかもしれません。
そのための一つの方法は、WebAssemblyのような、よく確立された、ネイティブにコンパイルされた、プラットフォームに中立な言語でパラチェーン検証アルゴリズムを指定することでしょう。
これが本当に実現可能かどうかを判断するには、さらなる研究が必要ですが、もしそうなら、ハードフォークを永久に追放するという大きな利点をもたらす可能性があります。
動的な情報は、パラチェーンのイングレスキュー(セクション6.6で説明)のような、グローバルな合意を持たなければならないトランザクションルーチングシステムのアスペクトを含む。
これは内部で管理できますが、より一般的なガバナンスコンポーネントのもとでの再利用を促進するために、外部のレフェレンダム契約に配置される可能性が高いでしょう。
追加チェーンの登録や、その他のあまり正式でないシステムのアップグレードに関する投票要件（必要な定足数、必要な過半数など）のパラメータは、「マスター憲法」で定められるが、少なくとも当初は、かなり伝統的な経路をたどるものと思われる。
正確な定式化は本研究の範囲外ですが、例えば、システム全体の出資者の3分の1以上が賛成票を投じれば、3分の2の賛成で可決されるというのは、賢明な出発点といえるかもしれません。
追加的な操作として、パラチェーンの停止と削除があります。
パラチェーンの停止は、できれば起こらないことを願いますが、パラチェーンの検証システムに何らかの難題があった場合の安全策となるように設計されています。
この措置が必要となる最も明白な例は、実装の違いによってバリデータが有効性またはブロックについて合意できない場合です。
バリデータは複数のクライアント実装を使用することを推奨され、債券没収の前にこのような問題を発見することができるようになる。
一時停止は緊急措置であるため、国民投票ではなく、動的検証者の投票によって行われる。
再導入は、バリデータまたは国民投票のいずれによっても可能である。
パラチェーンを完全に撤去する場合は、国民投票の後に、独立したチェーンに移行するか、他のコンセンサスシステムの一部になるかの秩序ある移行を可能にするために、かなりの猶予期間が必要である。
この猶予期間はおそらく数ヶ月で、パラチェーン登録簿にチェーンごとに設定され、異なるパラチェーンがその必要性に応じて異なる猶予期間を享受できるようにする。

6.4. リレーブロックのシーリング
Sealingとは、本質的には正規化のプロセスを指します。つまり、オリジナルを基本的に単一で意味のあるものにマッピングする基本的なデータ変換のことです。
PoWチェーンでは、シーリングは事実上マイニングと同義です。
この場合、特定のリレーチェーンブロックとそれが表すパラチェーンブロックの有効性、可用性、正規性に関して、バリデータから署名されたステートメントを収集することが必要です。
BFTコンセンサスアルゴリズムの基礎となる仕組みは、今回のテーマからは外れています。
その代わりに、コンセンサスを生み出すステートマシンを想定したプリミティブを使用して説明することにします。
最終的には、Tangaora [9]（Raft[16]のBFT版）、Tendermint [11]、HoneyBadgerBFT [14]などの有望なBFT合意アルゴリズムに触発されると予想している。
このアルゴリズムは、複数のパラチェーンについて並行して合意に達する必要があるため、通常のブロックチェーンの合意形成メカニズムとは異なります。
我々は、いったんコンセンサスが成立すれば、そのコンセンサスを参加者の誰もが提供できる反論の余地のない証明に記録できると仮定している。
また、プロトコルの不正行為は、不正行為を行った参加者を含む小さなグループに限定することで、処罰を与える際の巻き添えを最小限に抑えられると想定しています。
この証明は署名されたステートメントという形で、リレーチェーンブロックのヘッダーに、リレーチェーンのステートリールートとトランザクショントリールートをはじめとする他のフィールドと一緒に格納される。
封印処理は、リレーチェーンのブロックとリレーコンテンツの一部を構成するパラチェーンのブロックの両方を扱う単一の合意形成メカニズムの下で行われます。パラチェーンは、サブグループによって個別に「コミット」され、後で照合されることはありません。
この結果、リレーチェーンの処理はより複雑になりますが、システム全体のコンセンサスを一段階で完了させることができ、レイテンシーを最小限に抑え、以下のルーティング処理に役立つ非常に複雑なデータ可用性要件に対応できるようになります。
各参加者のコンセンサスマシンの状態は、単純な（2次元の）表としてモデル化することができる。
各参加者（バリデータ）は、各パラチェーンブロック候補とリレーチェーンブロック候補に関する、他の参加者からの署名付きステートメント（「投票」）の形で、一連の情報を持っている。
この情報は次の2つのデータである。可用性: このバリデータは、このブロックからのイグレス・トランザクション・ポスト情報を持っており、次のブロックのパラチェーン候補を適切に検証できるか。バリデータは1(既知)または0(未知)のいずれかに投票することができる。
一旦1に投票すると、彼らはこのプロセスの残りの間、同じように投票することを約束する。
これを無視した後の投票は処罰の対象となる。
有効性: パラチェーンブロックは有効か、また外部から参照されるデータ(トランザクションなど)はすべて利用可能か。これは、投票対象のパラチェーンに割り当てられたバリデーターにのみ関係する。
彼らは1(有効)、-1(無効)、0(未知)のいずれかに投票することができる。
一旦0以外の値を投票すると、そのプロセスの残りの期間、この方法で投票することを約束される。
これを無視した投票が行われた場合には、処罰の対象となる。
すべての検証者は投票を提出しなければならない。投票は、上記の規則に従って再提出してもよい。
コンセンサスの進行は、各パラチェーンに対する複数の標準的なBFTコンセンサスアルゴリズムが並行して行われるものとしてモデル化することができる。
これらは、比較的少数の悪意ある行為者が一つのパラチェーングループに集中することで妨害される可能性があるため、全体のコンセンサスは、デッドロックからの最悪のシナリオを単に一つ以上の無効なパラチェーンブロック（および責任者への罰）に制限する、バックストップを確立するために存在します。
個々のブロックの有効性に関する基本的なルール（正規のリレーから参照される唯一のパラチェーン候補となることについて、検証者の集合が全体としてコンセンサスを得ることができるもの）。- その有効者の少なくとも3分の2が肯定的な投票を行い、否定的な投票を行わないこと。
有効性について、肯定的な投票が少なくとも1件、否定的な投票が少なくとも1件あった場合、例外状態が発生し、バリデータ全体の投票により、悪意あるパーティがいるか、偶発的にフォークが発生したかを判断しなければならない。
有効・無効の他に、第3の種類の投票が認められている。これは両方に投票することと等しく、ノードが相反する意見を持っていることを意味する。
これはノードの所有者が同意しない複数の実装を実行しているためであり、プロトコルに曖昧さがある可能性を示している。
すべての有効回答者の票を数えた後、負けた意見が勝った意見の票の少なくともある小さな割合（パラメータ化される；最大で半分、おそらく大幅に少ない）を持っていれば、それは偶然のパラチェーンフォークであると仮定し、パラチェーンは合意プロセスから自動的に停止されます。
そうでなければ、悪意ある行為とみなし、反対意見に投票していた少数派を罰する。
結論は正統性を証明する署名の集合である。
その後、リレーチェーンブロックを封印し、次のブロックを封印する処理を開始することができる。

6.5.リレーブロックの封印のための改良点。
この封印方式はシステムの動作を強力に保証するものであるが、各パラチェーンの鍵情報は全バリデータの3分の1以上が利用可能であることが保証されていなければならないため、特に優れたスケールアウトを実現するものではない。
つまり、チェーンが増えれば増えるほど、各バリデーターの責任範囲は大きくなる。
オープンコンセンサスネットワークにおけるデータの可用性は本質的に未解決の問題であるが、バリデータ・ノードにかかるオーバーヘッドを軽減する方法はある。
その一つは、バリデータはデータの可用性に責任を持たなければならないが、実際にデータを保存、通信、複製する必要はないことを認識することである。
データをコンパイルするコレーターに関連する（あるいは全く同じ）二次的なデータサイロが、バリデータの利子や収入の一部を支払って、可用性を保証するタスクを管理することができるかもしれない。
しかし、これによって中間的なスケーラビリティは確保できるかもしれないが、根本的な問題は解決しない。一般に、チェーンを増やすとバリデータを追加する必要があるため、継続的なネットワークリソース消費（特に帯域幅）はチェーンの二乗とともに増加し、長期的には耐えられない性質となる。
結局のところ、コンセンサスネットワークが安全であるとみなされるためには、必要な帯域幅はバリデータの総量×入力情報の総量のオーダーになるという基本的な制限に頭をぶつけ続けることになりそうです。
これは、信頼されていないネットワークでは、データストレージのタスクを多くのノードに適切に分散させることができないためであり、処理という極めて分散可能なタスクとは別個のものである。

6.5.1.Introducing Latency.
この規則を緩和する一つの方法は、即時性の概念を緩和することである。
33%+1 のバリデータが、即時ではなく最終的にのみ利用可能かどうかを判断する投票を行うことで、指数関数的なデータ伝搬をうまく利用し、データ交換のピークを均等にすることができる。
合理的な等式は、（証明されていないが）次のとおりである。(1) レイテンシ = 参加者 × チェーン現在のモデルでは、処理を分散させるために、システムの規模はチェーンの数に比例する。各チェーンは少なくとも1人の検証者を必要とし、可用性の証明は検証者の一定の割合で固定されるので、参加者も同様にチェーンの数とともに増加する。
結局、以下のようになる。(つまり、システムが成長するにつれて、必要な帯域幅と、ネットワーク上で利用可能性が判明するまでの待ち時間が、その2乗で増加することになる（これは、最終的に利用可能になるまでのブロック数としても特徴づけられる）。
これは実質的な成長要因であり、顕著な障害となることが判明し、リレーチェーンのツリーを介した投稿の多段ルーティングのためにいくつかの「ポルカドット」を階層に構成するなど、「非フラット」パラダイムを強いられるかもしれません。

6.5.2.市民参加。
もう一つの可能な方向は、マイクロ苦情システムを通じて、このプロセスへの一般市民の参加を得ることである。
漁師と同様、利用可能性を主張する検証者を取り締まる外部の関係者がいてもよい。
彼らの仕事は、そのような利用可能性を示すことができないと思われる人を見つけることである。
そうすることで、彼らは他のバリデータに対して苦情を申し立てることができる。
PoWまたはステイクドボンドを使用して、システムがほとんど役に立たなくなるシビル攻撃を緩和することができる。

6.5.3.Availability 保証人。
最後の方法は、第二の保証付きバリデータを “可用性保証者 “として指名することである。
これらのバリデータは、通常のバリデータと同様に結合され、同じバリデータから選択することもできる(ただしその場合は、少なくともセッションごとに、長期間にわたって選択することになる)。
通常のバリデータと異なり、パラチェーン間の切り替えは行わず、1つのグループを形成し、すべての重要なチェーン間データが利用可能であることを証明する。
これには、参加者とチェーンの間の等価性を緩和する利点がある。
基本的に、チェーンは（元のチェーン検証者セットとともに）成長することができるが、参加者、特にデータ利用可能性証言に参加する者は、少なくとも亜線形で、かなり一定に保たれる可能性がある。

6.5.4.Collator Preferences.
このシステムの重要な側面の1つは、任意のパラチェーンのブロックを作成するコレーターの健全な選択があることを保証することです。
もし単一のコレーターがパラチェーンを支配した場合、外部データの利用可能性の欠如の可能性が少なくなるので、いくつかの攻撃がより実行しやすくなる。
1つのオプションは、さまざまなコレーターを支持するために、擬似ランダムなメカニズムで人為的にパラチェーンブロックの重み付けをすることです。
まず、コンセンサスメカニズムの一部として、バリデータが “重い “と判断したパラチェーンブロック候補を支持することを要求する。
同様に、バリデータが最も重いブロックを提案するようにインセンティブを与えなければならない。これは、報酬の一部を候補の重さに比例させることで実現できる。
照合者が自分の候補がコンセンサスの勝利候補として選ばれる妥当で公平な機会を与えられるように、我々はパラチェーンブロック候補の特定の重みを、各照合者に関連したランダム関数で決定するようにする。
例えば、照合人のアドレスと、ブロックが作成される時点に近いところで決定される暗号的に安全な疑似乱数との間のXOR距離尺度をとります（想定上の「当たり券」）。
これにより、各コレーター（より具体的には各コレーターのアドレス）は、自分の候補ブロックが他のすべてのブロックに「勝つ」ランダムなチャンスを効果的に得ることができます。
1人の照合者が勝ち組チケットに近いアドレスを「採掘」して、各ブロックのお気に入りになるというシビル攻撃を軽減するために、照合者のアドレスに何らかの慣性を持たせることになります。
これは、そのアドレスに基準額の資金を持つことを要求するのと同じくらい簡単なことかもしれません。
よりエレガントなアプローチとしては、当選チケットへの近さを、当該住所に駐車されている資金の額で重み付けすることでしょう。
まだモデル化はされていないが、このメカニズムにより、非常に小さなステークホルダーでも照合者として貢献できる可能性は十分にある。

6.5.5.過重なブロック
バリデータセットが危険にさらされた場合、有効ではあるが、実行と検証に膨大な時間を要するブロックを作成し、提案する可能性がある。
これは問題である。というのも、バリデータ・グループは、例えば大きな素数の因数分解など、ある特定の情報がすでに知られていてショートカットできる場合を除き、非常に長い実行時間を要するブロックを合理的に作成することが可能だからである。
もし一人の照合者がその情報を知っていれば、他の照合者が古いブロックの処理に追われている間、自分の候補を受理してもらうのに明らかに有利になる。
私たちはこのようなブロックをオーバーウェイトと呼んでいる。
このようなブロックを提出し検証するバリデータに対する保護は、大部分が無効なブロックに対するものと同じであるが、さらに注意点がある。ブロックの実行にかかった時間（つまりオーバーウェイトであるかどうか）は主観的であるので、不正行為に関する投票の最終結果は、基本的に3つの陣営に分かれる。
この場合、3分の2以上の人が、ある制限（たとえばブロック間の総許容時間の50％）内でそのブロックを実行できると宣言します。
もうひとつは、そのブロックが間違いなくオーバーウェイトであるというもので、これは3分の2以上が、そのブロックを制限時間内に実行できないと宣言した場合です。
最後の可能性は、検証者間の意見がほぼ等しい場合である。
この場合、我々は相応の罰則を選択することができる。
バリデータがいつオーバーウエイトのブロックを提案するかを予測できるようにするために、バリデータは各ブロックのパフォーマンスに関する情報を公開することを義務づけるのが賢明であろう。
十分な期間にわたって、これによって、バリデータは自分の処理速度を、審査する仲間に比べて相対的にプロファイルすることができるはずである。

6.5.6. コレーターの保険
PoWネットワークとは異なり、コレーターのブロックの有効性を確認するには、その中のトランザクションを実際に実行しなければならない。
悪意のあるコレーターが無効または過重なブロックをバリデータに送り、バリデータを悲しませ (リソースを浪費させ)、潜在的に大きな機会損失を与える可能性がある。
これを軽減するために、我々はバリデータ側の簡単な戦略を提案する。
第一に、バリデータに送信されるパラチェーンブロック候補は、資金を持つリレーチェーンアカウントから署名されていなければならない。
第二に、そのようなブロック候補は、口座の資金量（上限あり）、コレーターが過去に提案したブロックの数（過去の罰は言うまでもない）、および前述の当選チケットへの近接度の組み合わせ（例：乗算）によって優先順位を決定されるべきである。
この上限は、バリデータが無効なブロックを送信した場合に支払われる懲罰的賠償金と同じであるべきである。
コレーターが無効または過重なブロック候補をバリデータに送信することを抑制するため、バリデータは次のブロックに、不正行為を主張する違反ブロックを含む取引を行うことができる。この場合、不正行為を行ったコレーターの口座の資金の一部または全部を、被害を受けたバリデータに送金する効果がある。
この種の取引は、コレーターが処罰前に資金を持ち出せないようにするため、他の取引より優先される。
損害賠償として送金される金額は、まだモデル化されていない動的なパラメータであるが、悲劇の度合いを反映するために、おそらくバリデータブロック報酬の割合になるだろう。
悪意のあるバリデータがコレーターの資金を恣意的に没収するのを防ぐため、コレーターは、少額の保証金を支払う代わりに、ランダムに選ばれたバリデータの陪審員に、バリデータの判断を訴えることができる。
陪審員がバリデータに有利な判決を下した場合、保証金は陪審員によって消費される。
そうでない場合、保証金は返還され、バリデータは罰金を科される(バリデータはより高い地位にあるため、罰金はかなり高額になると思われる)。

6.6.Interchain Transaction Routing (チェーン間トランザクションのルーティング)。
インターチェーントランザクションルーティングは、リレーチェーンとそのバリデータの重要な保守作業の1つである。
これは、投稿されたトランザクション(しばしば単に「投稿」と短縮される)が、あるソースパラチェーンから望ましい出力であるところから、他のデスティネーションパラチェーンの信頼要件なしの入力になる方法を管理するロジックである。
私たちは上記の表現を慎重に選びました。特に、このポストを明示的に承認するために、ソースパラチェーンでのトランザクションがあったことを要求しているわけではありません。
私たちがこのモデルに課す唯一の制約は、パラチェーンがブロック処理全体の出力の一部としてパッケージ化された、ブロック実行の結果であるポストを提供しなければならないということです。
これらのポストはいくつかのFIFOキューとして構成され、リストの数はルーティングベースとして知られ、約16になることがあります。
注目すべきは、この数が、マルチフェーズルーティングに頼ることなくサポートできるパラチェーンの量であることです。
当初、ポルカドットはこのような直接ルーティングをサポートしますが、パラチェーンの初期セットをはるかに超えてスケールアウトする手段として、可能なマルチフェーズルーティングプロセス（「ハイパールーティング」）の1つの概要を説明します。
すべての参加者が次の2ブロックn, n + 1のサブグループ化を知っていると仮定する。
要約すると、ルーティングシステムは以下のような段階を踏む。

CollatorS: V alidators[n][S]のメンバーに連絡する。
CollatorS。FOR EACH Subgroup s: V alidators[n][s]の少なくとも1つのメンバーが接触していることを確認する。
CollatorS: FOR EACH subgroup s: egress[n – 1][s][S] が利用可能であると仮定（最後のブロックから ‘S’ へのすべての着信ポストデータ）。
CollatorS: S のブロック候補 b を構成する: (b.header, b.ext, b.proof, b.receipt, b.egress)
CollatorS: 証明情報 proof[S] = (b.header, b.ext, b.proof, b.receipt) を V alidators[n][S] に送信する．
CollatorS: 外部取引データ b.ext を他の Collator や Validator が利用できるようにする。
CollatorS: FOR EACH サブグループ s: V alidators[n + 1][s] ：次のブロックの受信サブグループのメンバーに、退出情報 egress[n][S][s] = (b.header, b.receipt, b.egress[s]) を送る。
V alidatorV : 同一集合のメンバーを次のブロックに事前接続する: N = Chain[n + 1][V ]とし、Chain[n + 1][v] = N となるすべてのバリデータvを接続する。
V alidatorV : このブロックのすべてのデータ入力を照合する。FOR EACH サブグループ s: egress[n – 1][s][Chain[n][V]] を取得し、他のバリデータ v から Chain[n][v] = Chain[n][V] となるようなデータを取得する。
試行の証明のために、ランダムに選ばれた他のバリデータを経由する可能性もある。
V alidatorV : このブロックに対する証明の候補を受け入れる proof[Chain[n][V ]]。
ブロックの有効性を投票する – V alidatorV : 次のブロックのEgressデータの候補を受け入れる。FOR EACH subgroup s, accept egress[n][s][N].
Vote block egress availability; Chain[n + 1][v] = Chain[n + 1][V ]となるように、興味のあるバリデータvに再公開する。
V alidatorV : UNTIL CONSENSUS ここで: egress[n][from][to] はブロック番号 ‘n’ のパラチェーン ‘from’, ‘to’ に向かう投稿の現在の退出キュー情報である。

CollatorS はパラチェーン S のコレーターである。
V alidators[n][s] はブロック番号 n のパラチェーン S に対するバリデータの集合である。
逆に、Chain[n][v] はブロック番号 n.block においてバリデータ v が割り当てられているパラチェーンである。
egress[to] は、あるパラチェーンブロックからの投稿のうち、宛先パラチェーンが to である投稿のイグレスキューである。
コレーターは自分のブロックが正規化されることに基づいて(取引)料金を徴収するので、次のブロックの各宛先に対して、そのサブグループのメンバーに現在のブロックからの退出キューを通知することを保証するインセンティブがある。
バリデータは(パラチェーン)ブロックに関する合意を形成することだけにインセンティブを与えられており、そのため、どのコレーターのブロックが最終的に正規化されるかにはほとんど関心がない。
原理的には、バリデータはあるコレーターに忠誠を誓い、他のコレーターのブロックが正統化される機会を減らすために共謀することができる。しかし、これはパラチェーンのバリデータがランダムに選ばれるため困難であり、合意形成プロセスを阻害するパラチェーンブロックの料金を減額することで対抗することができる。

6.6.1.External Data Availability.
パラチェーンの外部データが実際に利用可能であることを保証することは、ネットワークに作業負荷を分散させることを目的とした分散化システムにおける長年の問題である。
この問題の核心は、可用性の非対話的証明も非可用性の証明も不可能であるため、BFTシステムが外部データの可用性に依存する正しい遷移を適切に検証するためには、システムの許容できるビザンチンノードの最大数＋1が、データが利用可能であると証明しなければならないという、可用性問題である。
ポルカドットのように適切にスケールアウトするシステムでは、このことが問題を引き起こす。もし一定の割合のバリデータがデータの可用性を証明しなければならず、バリデータはデータが利用可能であると主張する前に実際にデータを保存したいと思うとしたら、システムの規模（つまりバリデータの数）に応じて必要な帯域幅やストレージが増加するという問題をどう回避すればよいだろうか。1つの可能な答えは、バリデータ(可用性保証者)を別に用意し、その順番をポルカドット全体のサイズに比例して増加させることである。
これについては6.5.3節で説明する。
また、二次的なトリックもある。
グループとしてのコレーターは、自分が選んだパラチェーンについてすべてのデータが利用可能であることを保証する本質的なインセンティブを持つ。なぜなら、それがなければ、取引手数料を徴収できるブロックをさらに作成することができないからである。
照合人はまた、（パラチェーン・バリデータ・グループのランダムな性質により）様々なグループを形成し、そのメンバーであることは自明でなく、証明も容易である。
したがって、最近の照合人（おそらく直近の数千ブロックの照合人）は、特定のパラチェーンブロックの外部データの利用可能性について、少額の保証金でバリデータを発行することが許可されている。
バリデータは、証言した違反バリデータサブグループに連絡し、データを取得して照合者に返却するか、データがないことを証言して問題を拡大させ(データの提供を直接拒否することは保障金没収の違反となるので、違反バリデータは単に接続を切断するだろう)、追加のバリデータに連絡して同じテストを実行しなければならない。
後者の場合、コレーターのボンドは返却される。
このような利用不能の証言を行えるバリデータの定足数に達したら、それらを解放し、不正を行ったサブグループを処罰し、ブロックを元に戻す。

6.6.2.Posts ルーティング。
各パラチェーンヘッダーはegress-trie-rootを含む。これはrouting-baseビンを含むトライのルートであり、各ビンはegressポストの連結されたリストである。
特定のパラチェーンのブロックが特定の宛先パラチェーンのための特定のイグレスキューを持っていたことを証明するために、パラチェーンバリデータ間でメルクル証明が提供されることがある。
パラチェーンブロックの処理の最初に、当該ブロックに対する他の各パラチェーンのegressキューバウンドは、我々のブロックのingressキューにマージされます。
私たちは、どのパラチェーンブロックのペアにもえこひいきをしない決定論的な処理を実現するために、強い、おそらくCSPR9のサブブロック順序を仮定しています。
コレーターは新しいキューを計算し、パラチェーンのロジックにしたがって出口キューを排出します。
入庫キューの内容は、パラチェーンブロックに明示的に書き込まれます。
これは主に2つの目的があります。まず、パラチェーンを他のパラチェーンから分離して信頼できる形で同期させることができるということです。
バリデータおよびコレータは、キューのデータを特別に取得することなく、次のブロックを処理することができます。
ブロック処理の終了時にパラチェーンの受信キューが閾値を超えている場合、リレーチェーン上で飽和とマークされ、それがクリアされるまで、それ以上のメッセージは配信されないかもしれない。
パラチェーンブロックの証明において、照合器の動作の忠実性を示すために、メルクル証明が使用される。

6.6.3.講評です。
この基本的な仕組みに関連する小さな欠陥として、ポストボム攻撃があります。
これは、すべてのパラチェーンが特定のパラチェーンに可能な限り最大量のポストを送信するものである。
これはターゲットのイングレスキューを一度に縛るが、標準的なトランザクションDoS攻撃以上のダメージは与えられない。
うまく同期された悪意のないコレーターとバリデーターのセットで通常通り動作させると、N個のパラチェーン、 N×M個のバリデーター、パラチェーンあたりL個のコレーターについて、ブロックごとの総データ経路を以下のように分解することができる。バリデータ M -1+L+L: パラチェーンセットの他のバリデータに対してM -1、パラチェーンブロックの候補を提供する各コレーターに対してL、前のブロックのイグレスペイロードを必要とする次のブロックの各コレーターに対して 2つ目のLが必要である。
(後者は、コレーターがそのようなデータを共有する可能性が高いので、実際には最悪の場合の操作に近い)。コレータ。M +kN: Mは関連する各パラチェーンブロックバリデータへの接続、kNは次のブロックの各パラチェーンバリデータグループのサブセット(および場合によっては優先コレータ)への egressペイロードのシードである。
このように、ノードあたりのデータパス経路は、システム全体の複雑さに応じて直線的に増加する。
これは合理的ですが、システムが数百または数千のパラチェーンにスケールアップすると、より低い複雑さの成長率と引き換えに、いくつかの通信レイテンシが吸収されるかもしれません。
この場合、ストレージバッファとレイテンシを導入する代償として、瞬時経路の数を減らすために、マルチフェーズルーティングアルゴリズムが使用されるかもしれない。

6.6.4.Hyper-cube Routing.
ハイパーキューブルーティングは、ほとんどが上述の基本的なルーティングメカニズムの拡張として構築できるメカニズムである。
基本的には、パラチェーンやサブグループノードの数でノードの接続性を成長させるのではなく、パラチェーンの対数でだけ成長させるのである。
ポストが最終的に配送されるまでに、複数のパラチェーンのキューを経由することがあります。
ルーティング自体は決定論的で単純です。
パラチェーンの総数ではなく、ルーティングベース(b)となる。
これはパラチェーンの数が変わると固定され、代わりにルーティング指数(e)が上げられることになります。
このモデルでは、メッセージ量はO(b e )で増え、経路は一定で、レイテンシ（配送に必要なブロック数）はO(e)となります。
経路のモデルはe次元の超立方体で、立方体の各辺にはb個の可能な位置がある。
各ブロックは、1つの軸に沿ってメッセージをルーティングする。
ラウンドロビン方式で軸を交互に配置することで、最悪でもeブロックの配送時間を保証しています。
パラチェーン処理の一部として、イングレスキューで見つかった外国行きのメッセージは、現在のブロック番号（したがってルーティング次元）が与えられると、適切なイグレスキューのビンに直ちにルーティングされます。
このプロセスは、配信ルート上の各ホップに対して追加のデータ転送を必要とするが、これは、データペイロード配信の何らかの代替手段を使用し、ポストの完全なペイロードではなく、参照のみをポストトリに含めることによって軽減され得る問題自体である。
4つのパラチェーン、b＝2、e＝2を有するシステムに対するこのようなハイパーキューブルーティングの例は、以下のとおりである。フェーズ0では、各メッセージMについて

sub0: もしMdest∈{2, 3}ならsendTo(2) else keep
sub1: もしMdest∈{2, 3}ならsendTo(3)else keep
sub2: もしMdest∈{0, 1} ならば sendTo(0) else keep
sub3: if Mdest ∈ {0, 1} then sendTo(1) else keep フェーズ1、各メッセージMについて。
sub0: もしMdest∈{1, 3} ならばsendTo(1) else keep
sub1: もしMdest∈{0, 2} ならばsendTo(0) else keep
sub2: もしMdest∈{1, 3} ならばsendTo(3) else keep
sub3: if Mdest ∈ {0, 2} then sendTo(2) else keep

ここでの2次元は、宛先インデックスの最初の2ビットと考えるとわかりやすい。最初のブロックでは、上位のビットだけが使われる。
2番目のブロックは低次のビットを扱います。
両方が (任意の順番で) 起これば、ポストはルーティングされます。

6.6.5.Maximising Serendipity (セレンディピティの最大化)
基本提案の変更点として、c 2 – c個のバリデータを固定し、各サブグループにc-1個のバリデータを配置することが考えられる。
ブロックごとに、パラチェーン間のバリデータを非構造的に再配置するのではなく、各パラチェーンサブグループで、各バリデータを次のブロックの異なるパラチェーンサブグループに割り当てる。
これにより、任意の2ブロック間で、任意の2組のパラチェーンについて、パラチェーン担当を入れ替えた2人のバリデータが存在するという不変性が得られます。
これは可用性の絶対的な保証にはならないが(たとえ善良なバリデータであっても、 1人のバリデータがオフラインになることはある)、それでも一般的なケースを最適化することは可能である。
このアプローチには複雑な点がないわけではない。
パラチェーンを追加すると、バリデータセットを再編成する必要がある。
さらに、バリデータの数はパラチェーン数の2乗に比例するため、最初は非常に少ないが、やがて増えすぎ、50パラチェーン程度で手に負えなくなる。
これらはいずれも根本的な問題ではない。
最初のケースでは、バリデータセットの再編成はいずれにせよ定期的に行わなければならないものである。
バリデータセットが小さすぎる場合、同じパラチェーンに複数のバリデータが割り当てられ、バリデータの総数が整数倍になってしまう可能性がある。
6.4で議論したハイパーキューブルーティングのような多段階ルーティングメカニズムは、バリデータ集合の大きさを軽減する。
6.4で説明したハイパーキューブルーティングのような多相ルーチングメカニズムは、チェーン数が多い場合に多数のバリデータを必要とすることを緩和するだろう。

6.7.Parachain バリデーション。
バリデータの主な目的は、パラチェーンのブロックが有効であることを、結合されたアクターとして証言することである。これには状態遷移、外部トランザクション、イングレスキューの待ち行列の実行、イグレスキューの最終状態などが含まれるが、これらに限定されない。
この処理自体はかなり単純である。
バリデータが前のブロックを破棄すると、彼らは自由に次のラウンドのコンセンサスのためのパラチェーンブロック候補を提供する作業を始めることができる。
最初に、バリデータはパラチェーンコレーター(次を参照)またはその共同バリデータの一つを通して、パラチェーンブロックの候補を見つける。
パラチェーンブロック候補のデータには、ブロックのヘッダー、前のブロックのヘッダー、含まれるあらゆる外部入力データ（イーサリアムとビットコインでは、このようなデータはトランザクションと呼ばれるが、原理的には任意の目的のために任意のデータ構造を含むことができる）、イグレスキューデータ、状態遷移正当性を証明する内部データ（イーサリアムではこれは、各取引の実行に必要となる様々な状態/ストレージトライノードになるだろう）などがある。
実験によると、最近のイーサリアムブロックのこの完全なデータセットはせいぜい数百KiBである。
同時に、バリデータは前のブロックの遷移に関する情報を取得しようとするが、その際、最初は前のブロックのバリデータから、後にデータの可用性に署名したすべてのバリデータから取得する。
バリデータはこのような候補ブロックを受け取ると、ローカルでその検証を行う。
この検証プロセスはパラチェーンクラスのバリデータモジュールに含まれており、ポルカドットのあらゆる実装に対して書かなければならないコンセンサス重視のソフトウェアモジュールである(原理的には、C言語のABIを持つライブラリにより、単一の「参照」実装のみを持つことで安全性を適切に低減した上で、単一のライブラリを実装間で共有することが可能であるが…）。
このプロセスは前のブロックのヘッダーを取り、そのハッシュが記録されるべき最近合意されたリレーチェーンブロックを通してその身元を確認する。
親ヘッダーの有効性が確認されると、特定のパラチェーンクラスの検証関数が呼び出されるかもしれません。
これは、いくつかのデータフィールド(だいたい先にあげたもの)を受け取り、ブロックの有効性を宣言する単純なブール値を返す単一の関数である。
このような検証関数の多くは、まず親ブロックから直接得られるヘッダーフィールドをチェックします (例: 親ハッシュ、数値など)。
続いて、取引や投稿を処理するために必要な内部データ構造を生成する。
イーサリアムのようなチェーンでは、トランザクションの完全な実行に必要なノードがトライデータベースに格納されることになる。
他の種類のチェーンでは、他の準備メカニズムがあるかもしれません。
それが終わると、イングレスポストと外部トランザクション（または外部データが表すもの）は、チェーンの仕様に従ってバランスを取りながら実行されます。
(賢明なデフォルトは、外部トランザクションが処理される前に、すべてのイングレスポストの処理を要求することかもしれないが、これはパラチェーンのロジックが決定することである)。この処理により、一連の egress post が作成され、それらが本当に照合者の候補と一致するかどうかが検証される。
最後に、適切に入力されたヘッダーが、候補者のヘッダーと照合されます。
候補ブロックが完全に検証されると、バリデータはそのヘッダーのハッシュを投票し、必要な検証情報をすべてそのサブグループの共同バリデータに送信できるようになる。

6.7.1.パラチェーンコレーター。
パラチェーンコレーターは、現在のブロックチェーンネットワークにおける採掘者のタスクの多くを果たす非結合オペレーターである。
彼らは特定のパラチェーンに特化している。
パラチェーンを運用するためには、リレーチェーンと完全に同期したパラチェーンの両方を維持する必要があります。
完全同期」の正確な意味は、パラチェーンのクラスによって異なりますが、常にパラチェーンのイングレスキューの現在の状態が含まれます。
Ethereumの場合、少なくとも直近の数ブロックのMerkle-treeデータベースを維持することも含まれますが、アカウントの存在、家族情報、ログ出力、ブロック番号の逆引きテーブルなどのブルームフィルターを含む他のさまざまなデータ構造も含まれるかもしれません。
2つのチェーンを同期させることに加えて、トランザクションキューを維持し、パブリックネットワークから適切に検証されたトランザクションを受け入れることによって、トランザクションを「漁る」必要があります。
キューとチェーンがあれば、ブロックごとに選ばれた検証者（リレーチェーンが同期しているため、その身元はわかっている）のために新しい候補ブロックを作成し、有効性の証明などのさまざまな補助情報とともにピアネットワーク経由で送信することができる。
その際、リレーチェーンは含まれる取引に関連するすべての手数料を徴収する。
この仕組みには、さまざまな経済学が存在する。
照合人の数が過剰で競争が激しい市場では、取引手数料をパラチェーン・バリデータと共有することで、特定の照合人のブロックを含めるインセンティブを与えることが可能であろう。
同様に、照合人によっては、バリデータにとってより魅力的なブロックにするために、支払うべき手数料を引き上げることさえあるかもしれない。
この場合、より高い手数料を支払う取引は待ち行列を回避し、より早くチェーンに組み入れられるという自然な市場が形成されるはずである。

6.8.ネットワーキング
イーサリアムやビットコインのような伝統的なブロックチェーンにおけるネットワーキングは、むしろシンプルな要件を持っています。
すべてのトランザクションとブロックは、単純な無方向性ゴシップでブロードキャストされます。
同期は、特にイーサリアムではより関与していますが、実際にはこのロジックは、いくつかのリクエストとアンサーメッセージタイプの周りで解決するプロトコル自体よりも、ピア戦略に含まれていました。
Ethereum は devp2p プロトコルで現在のプロトコルに進歩をもたらし、多くのサブプロトコルを単一のピア接続上で多重化し、同じピアオーバーレイで多くの p2p プロトコルを同時にサポートできるようにしましたが、プロトコルの Ethereum 部分はまだ比較的単純で、p2p プロトコルは QoS サポートなどの重要機能が欠けておりまだ未完成のままです。
悲しいことに、よりユビキタスな「Web 3」プロトコルを作ろうという願いはほとんど失敗し、これを使用するプロジェクトはイーサリアムのクラウドセールから明確に資金を得たものだけとなりました。
ポルカドットの要件は、むしろより実質的なものです。
ポルカドットには、完全に統一されたネットワークではなく、それぞれが異なる要件を持ついくつかのタイプの参加者がいて、その参加者が特定のデータについて会話する傾向があるネットワーク「アベニュー」があります。
つまり、より構造化されたネットワーク・オーバーレイと、それをサポートするプロトコルが必要になる可能性が高いのです。
さらに、新しい種類の「チェーン」のような将来の追加を容易にするための拡張性は、それ自体が新しいオーバーレイ構造を必要とするかもしれません。
ネットワークプロトコルがどのように見えるかについての詳細な議論は、このドキュメントの範囲外ですが、いくつかの要求分析は合理的です。
我々は、ネットワーク参加者を3つのサブセットのそれぞれ2つのセット（リレーチェーン、パラチェーン）に大別することができる。
また、パラチェーンの参加者は、他のパラチェーンの参加者とは対照的に、自分自身の間での会話にのみ興味があることを述べることができます。

リレーチェーン参加者。
検証者。パラチェーンごとにサブセットP[s]に分割されたP
可用性保証者。A（プロトコルの基本形ではValidatorで表現されることがある）
リレーチェーンクライアント M（各パラチェーンセットのメンバーは、Mのメンバーである傾向があることに注意）
パラチェーン参加者(Parachain participants)
パラチェーンコレーター(Parachain Collators) C[0]、C[1]、…。
パラチェーンフィッシャーマン。f[0]、f[1]、…。
パラチェーンの依頼人。S[0], S[1], ….
パラチェーンライトクライアント: L[0], L[1], …
一般に、これらの集合のメンバー間で行われる傾向のある通信の特定のクラスに名前を付ける。- P | A <-> P | A: バリデータ/ギャランティのフルセットは、合意を得るためにうまく接続されている必要がある。
P[s] <-> C[s] | P[s]。パラチェーングループのメンバーであるバリデータは、ブロック候補を発見し共有するために、他のメンバーやそのパラチェーンのコレーターとゴシップを交わす傾向がある。
A <-> P[s] | C | A: 各利用可能性保証者は、割り当てられたバリデータから、コンセンサスに敏感なチェーン間データを収集する必要がある。また照合者は、利用可能性保証者に自分のブロックを宣伝することで、コンセンサスの可能性を最適化することができる。
また、コレーターは、アベイラビリティ保証人にそれを宣伝することで、自分のブロックのコンセンサスの機会を最適化することができる。いったんデータが揃えば、他の保証人にそのデータを配布し、コンセンサスを促進することができる。
P[s] <-> A｜P[s’]: パラチェーン検証者は、直前の検証者または利用可能性保証者から、追加の入力データを収集する必要がある。
F[s] <-> P: 報告の際、釣り人はどの参加者にもクレームをつけることができる。
M <-> M | P | A: 一般的なリレーチェーンクライアントは、バリデータと保証人からデータを払い出す。
S[s] <-> S[s] | P[s] | A: パラチェーンクライアントはバリデータ/ギャランティからデータを払い出す。
L[s] <-> L[s] | S[s]: パラチェーンライトクライアントは、フルクライアントからデータを払い出す。

効率的なトランスポートメカニズムを保証するために、イーサリアムのdevp2pのような「フラットな」オーバーレイネットワークは、各ノードがそのピアの適合性を（非恣意的に）区別しないので、適しているとは思えません。
合理的に拡張可能なピアの選択と発見のメカニズムがプロトコルに含まれる必要があり、また適切な種類のピアが適切なタイミングで「セレンディピティに」接続されるように積極的な計画と先読みが必要でしょう。
適切にスケールアウトしたマルチチェーンの場合、コレーターはその時点で選出されたバリデーターに継続的に再接続するか、バリデーターの一部と継続的に契約を結び、そのバリデーターにとって役に立たない時間の大部分において切断されないようにする必要がある。
また、コレーターは当然ながら、合意に敏感なデータの迅速な伝達を保証するために、可用性保証者セットへの1つ以上の安定した接続を維持しようとする。
可用性を保証する者は、互いに、またバリデータ（コンセンサスとコンセンサスに重要なパラチェーンデータを保証するため）、いくつかのコレーター（パラチェーンデータのため）、いくつかの漁師とフルクライアント（情報を分散するため）との安定した接続を維持することを主に目指すことになる。
バリデータは他のバリデータ、特に同じサブグループに属するバリデータと、パラチェーンブロックの候補を提供してくれるコレーターを探す傾向があります。
フィッシャーマンや一般的なリレーチェーンやパラチェーンクライアントは、通常バリデータやギャランティとの接続を維持しようとしますが、それ以外のノードには自分と同じようなノードをたくさん探します。
パラチェーンライトクライアントも同様に、他のパラチェーンライトクライアントだけでなく、パラチェーンのフルクライアントに接続することを目指します。

6.8.1.ピア・チャーン（Peer Churn）の問題。
基本プロトコル案では、パラチェーン遷移を検証するために割り当てられた検証者がランダムに選出されるため、これらのサブセットの各々はブロックごとに常にランダムに変化する。
これは、異なる（非ピアの）ノードが相互にデータを渡す必要がある場合に問題となります。
ホップ距離(したがって最悪の場合の遅延)がネットワークサイズの対数で増加するだけになるように、かなり分散された、よく接続されたピアネットワークに依存するか(ここではKademlia様プロトコル[13]が役に立つでしょう)、ノードの現在の通信ニーズを反映したピアセットを保つために必要な接続交渉を行うための長いブロック時間を導入しなければなりません。
長いブロックタイムをネットワークに強制すると、特定のアプリケーションやチェーンに使えなくなる可能性があります。
完璧に公平で接続されたネットワークであっても、規模が大きくなると、関心のないノードが自分にとって無用なデータを転送することになり、帯域幅の大幅な浪費につながります。
両方の方向から解決策を講じることもできるが、待ち時間を最小化するための合理的な最適化は、パラチェーンバリデータセットの変動を制限し、一連のブロック間(たとえば、15個のグループ)のみメンバーシップを再割り当てすることであろう。
この場合、4秒間のブロックタイムでは、1分間に1回しかコネクションを変更しないことになる）、または、一度に1人ずつ変更するなど、段階的にメンバーを入れ替える（たとえば、各パラチェーンに15人のバリデータが割り当てられると、平均して完全にユニークなセットまで1分かかることになる）。
ピア解約の量を制限し、パラチェーンセットの部分的な予測可能性によって有利なピア接続が事前に行われるようにすることで、各ノードが恒久的にセレンディピティなピアの選択を維持できるようにすることができるのです。

6.8.2.Path to an Effective Network Protocol（効果的なネットワークプロトコルへの道）。
最も効果的で合理的な開発努力は、独自のプロトコルを開発するよりも、既存のプロトコルを利用することに重点を置くことでしょう。
Ethereumのdevp2p [22], IPFSのlibp2p [1], GNUのGNUnet [4]など、いくつかのP2Pの基本プロトコルが存在し、それらを利用したり補強したりすることが可能です。
これらのプロトコルの完全なレビューと、特定の構造的保証、動的なピアステアリング、拡張可能なサブプロトコルをサポートするモジュール式ピアネットワークの構築に対するそれらの関連性は、このドキュメントの範囲をはるかに超えていますが、ポルカドットの実装において重要なステップとなるでしょう。

7.プロトコルの実用性

7.1.インターチェーントランザクションの支払い。
Ethereumのgasのような全体的な計算リソース計算フレームワークの必要性をなくすことによって、非常に多くの自由とシンプルさが得られますが、これは重要な問題を提起します：gasなしでは、あるパラチェーンはどうやって他のパラチェーンが計算を行うことを強制するのを避けるのでしょうか？あるチェーンが他のチェーンにトランザクションデータをスパムするのを防ぐために、トランザクション・ポスト・イングレスキューのバッファに頼ることができる一方で、トランザクション処理のスパムを防ぐためにプロトコルが提供する同等のメカニズムはありません。
これはより高いレベルに任された問題である。
チェーンは受信するトランザクションポストデータに任意のセマンティクスを付けることができるので、計算を開始する前に対価を支払わなければならないことを保証することができる。
イーサリアム・セレニティが提唱するモデルと同様に、バリデータが特定の量の処理リソースを提供するのと引き換えに支払いを保証することを可能にするパラチェーン内の「ブレークイン」契約を想像することができる。
この資源は、ガスのようなもので測定されるかもしれないが、主観的な実行時間やビットコインのような定額制のモデルなど、まったく新しいモデルもあり得るだろう。
それ自体では、オフチェーンの呼び出し元が、ブレイクイン契約によって認識される何らかの価値メカニズムを利用できると容易に仮定できないため、これはあまり有益ではありません。
しかし、ソースチェーンに二次的な「ブレイクアウト」契約を想定することは可能である。
この2つの契約は一緒になってブリッジを形成し、互いを認識し、価値同等性を提供する。
(それぞれが利用できるステーキングトークンは、支払いの残高を清算するために使用できる)。このような別のチェーンに呼び出すことは、このブリッジを経由してプロキシすることを意味します。これは、宛先パラチェーンに必要な計算リソースを支払うために、チェーン間の価値伝達を交渉する手段を提供することになります。

7.2.Additional Chains.
パラチェーンの追加は比較的安価な操作であるが、無料ではない。
パラチェーンが増えるということは、パラチェーンあたりのバリデータが少なくなり、最終的には平均結合度が低下して、バリデータの数が多くなることを意味する。
パラチェーンを攻撃する際の強制コストはフィッシャーマンによって軽減されるが、バリデーターが増えれば、基本的な合意方法の仕組みから、より高いレイテンシーを強いられることになる。
さらに、各パラチェーンは、過度な検証アルゴリズムでバリデータを悲しませる可能性がある。
このように、新しいパラチェーンの追加には、バリデータやステークホルダー・コミュニティが引き出す何らかの「価格」が存在することになります。
このようなチェーン市場には、次のようなものが追加される可能性がある。- 参加するために（トークンをロックしたり燃やしたりして）支払う純貢献がゼロのチェーン（例：コンソーシアムチェーン、ドージェチェーン、アプリ専用チェーン） – 他で得ることが難しい特定の機能を追加することでネットワークに本質的価値をもたらすチェーン（例：機密性、内部拡張性、サービスタイアップ）。
基本的に、ステークホルダーのコミュニティは、金銭的またはリレーに機能的なチェーンを追加したいという願望を通じて、子チェーンを追加するインセンティブを得る必要があります。
新たに追加されるチェーンは、中期的または長期的な価値提案を損なうリスクなしに新しいチェーンの実験ができるように、削除の通知期間が非常に短くなることが想定されます。

8.まとめ

既存のブロックチェーンネットワークと下位互換性を持つ、スケーラブルで異種混合のマルチチェーンプロトコルを構築するための方向性を概説しました。
このようなプロトコルの下では、参加者は賢明な自己利益のために、標準的なブロックチェーンの設計から生じる既存のユーザーに対する典型的なコストなしに、非常に自由に拡張できるシステム全体を作成するために働きます。
私たちは、参加者の性質、経済的インセンティブ、参加者が関与しなければならないプロセスなど、このアーキテクチャの大まかな概要を説明しました。
私たちは基本設計を特定し、その長所と限界について議論しました。それに応じて、これらの限界を緩和し、完全にスケーラブルなブロックチェーンソリューションに向けてさらに前進する可能性がある、さらなる方向性を示しています。

8.1.Missing Materialと未解決の質問。
ネットワークフォークは、プロトコルの多様な実装から常に可能性があります。
そのような例外的な状態からの回復については議論されていません。
ネットワークが最終的にゼロにならない期間を持つことを考えると、リレーチェーンのフォークから回復することは大きな問題ではないはずですが、コンセンサスプロトコルに慎重に統合する必要があります。
債券の没収と逆に報酬の提供については深く検討されていない。
現在、我々は勝者総取りで報酬を与えることを想定しているが、これは漁師にとって最適なインセンティブモデルとは言えないかもしれない。
短時間のコミット-レヴェルのプロセスにより、多くの漁師が賞品を要求することができ、より公平な報酬の分配が可能になるが、このプロセスは不正行為の発見におけるさらなる遅延をもたらす可能性がある。

8.2.Acknowledgement.
この原稿を漠然とした体裁に仕上げてくれた校正者たちに大いに感謝する。
特に、Peter Czaban, Bj¨orn Wagner, Ken Kappler, Robert Habermeier, Vitalik Buterin, Reto Trinkler そして Jack Petersson。
Marek Kotewicz と Aeron Buchanan は特に言及に値します。
また、その他にも多くの方々にお世話になりました。
すべての誤りは私自身のものです。
コンセンサスアルゴリズムの初期研究を含むこの研究の一部は、Innovate UKプログラムのもと、英国政府から資金提供を受けたものである。