昨夜、Duskのホワイトペーパーをもう一度読み直したところ、コンセンサス（合意）セクションで足が止まりました。Duskは、無許可のまま、委員会ベースのプルーフ・オブ・ステーク（PoS）にSuccinct Attestationを用いています。必要な最小ステークは1,000 DUSKで、現在のエポックは2,160ブロックです。各ラウンドは最大50回の反復を実行でき、委員会は64クレジットを持つため、投票の権限は「1人1票」ではなく、クレジットに応じて重み付けされます。

興味深かったのは、しきい値構造です。Validは2/3が必要ですが、Invalid、NoCandidate、またはNoQuorumは、1/2 + 1の過半数に到達できます。16回の失敗した反復の後、プロトコルは緊急モードに入ることができ、これがライブネス（稼働継続性）とフォークリスクのトレードオフに関する疑問を投げかけています。

インセンティブ設計も目を引きました。80%はブロックジェネレーター、10%は投票委員会、10%はDuskに配分されます。ジェネレーターの80%は、70%が固定で、さらに含まれた投票に連動する10%の変動部分で構成されています。二重投票のような重大な不正は、ハード・スラッシング（強制没収）を引き起こし得ます。

次に、MoonlightとPhoenixによってアーキテクチャがより明確になりました。公開アカウントベースのトランザクションと、UTXOスタイルのノートの違い、Merkleツリー、nullifier、そしてZK証明です。

それでも気になっています。ステークに重み付けしたクレジット配分は、集中リスクを生み得るのでしょうか？また、バリデータ障害が起きた場合に、緊急モードはどれほど堅牢なのでしょうか？#dusk $DUSK @Dusk