今日はDuskのコンセンサスフローを読み進める中で、見出しのアーキテクチャだけを見ていると見落としやすい細部に引っかかってしまいました。
面白いのは、実際には誰がブロックを提案するかではありません。
そのブロックが、それ以外のネットワーク全体が確信をもって構築していけるものになるまでに、何が起きる必要があるのか——そこです。
Duskでは、コンセンサスプロセスの一部として証明書（certificate）を使います。
証明書が何を意味するのかを考え出すまでは、かなり一般的に聞こえます。
証明書は単なる、ブロックに付随する別のメタデータではありません。
それは、ネットワークの十分な部分がプロトコル上の特定のステップを完了したという、実質的な証拠です。
それによって興味深い依存関係が生まれます。
ブロックの生成は速くできます。
個々のバリデータは素早く応答できます。
しかしネットワークは、証明書が表す集合的な状態を待たなければなりません。
そのため、性能に関する問いは通常のTPS議論とは少し違ってきます。
つまり、
「ある1ノードが何かをどれだけ素早く処理できるか」ではなく——
「十分に独立した参加者が、他の全員が前に進むために必要な証拠を、どれだけ素早く作り出せるか」です。
それによって、私のコンセンサス遅延（latency）の見方が変わりました。
より高速な実行エンジンは役に立ちます。
並列処理は有効です。
ですが、証明書の形成が実際のネットワーク条件下で遅い部分になるのであれば、その下にあるもの全体の理論上の速さは、期待していたほど重要ではなくなります。
これは、ベンチマークのページではさほどワクワクするように見えないアーキテクチャ上の詳細の一つです。
しかし混雑時や、バリデータの性能がばらつく状況では、かなり重要になるのではないかと感じています。
Duskを読むほど、真の性能の物語は「単一の高速なコンポーネント」ではないように思えてきます。
問題なのは、ネットワーク全体が待たされるコンポーネントがどれか、ということです。
#dusk $DUSK @Dusk