今日、私は正直に少し腰を据えて考える必要があった @Dusk のコンセンサス詳細を見つけました。

多くの人は「クォーラム（定足数）」を聞くと、十分なバリデータが同意した時点で仕事は基本的に終わったと思いがちです。

しかし、プロトコルが必要としている以上に、さらに多くのバリデータが同意したらどうなるでしょう？

それが、ちょっと変な小さな問題を生みます。

たとえばネットワークが必要とする投票数が一定だとして、より大きなグループが有効なアテステーション（承認）を提出したとします。すると、その決定に紐づけられうる可能性のあるグループが複数存在することになります。

そしてここで $DUSK ブロック証明書が面白くなってきます。

証明書は次のブロックに運ばれ、直前のブロックのアテステーションを記録します。さらに重要なのは、ネットワークに定義済みの投票者セットを与えることです。

これは小さな技術的ディテールに聞こえるかもしれませんが、次に何が起こるかを見て初めて、その意味が分かります。

その投票者セットは、報酬とペナルティを算出する際に使えます。

つまりプロトコルは、単に次に答えようとしているわけではありません。

「十分な投票は得られたか？」

それに加えて、次にも答える必要があります。

「受け入れられた決定の一部として実際に数えられる投票はどれか？」

これはかなり筋の通った解くべき問題だと思います。

もし 100 人のバリデータが参加したとしても、クォーラムが必要とするのが 70 だけなら、後から報酬とペナルティのロジックが「結局どの 70 が効いたのか」を当てにいくようなことはしたくありません。

証明書は、ネットワークに固定された参照点を与えます。

ただし、私がさらに興味深いと思ったもう一つの面があります。

お金やペナルティがその投票者セットに依存する以上、そのセットの選び方そのものが、コンセンサス設計において重要な要素になります。

もはや単なる台帳管理ではありません。

そこで今、トレードオフ（交換条件）を見ています。

もしかすると、証明書は参加が最低ラインを超えるときに、Dusk コンセンサスをより説明責任のあるものにするのかもしれません。

あるいは、どの投票者を「正本（canonical）」とみなすかを決める際に、複雑さを少し移しているだけなのかもしれません。

それが必ずしも欠陥だとは思いません。

システムがどう動くのかを判断する前に、理解しておきたい種類のディテールなだけです。

クォーラムが要求する以上に多くのバリデータが投票するとき、固定された正本の投票者セットを望みますか？ それとも、報酬ロジックをより柔軟に保ちたいですか？

#dusk


Dusk のブロック証明書のアプローチについて、どう思いますか？