#dusk $DUSK @Dusk 今週、Duskのホワイトペーパーの目次を読み込んだ（第2/22ページ）。それ以上のものではなく、アウトラインだけでした。ですが、その構造からは何かが見えました。第4章「Transactions（取引）」は2つに分かれています。Moonlight（13ページ）とPhoenix（14ページ）。同一文書内に2つの取引モデル。

ここからは、私が実際に知っていることと、推測していることを正直に切り分けます。TOC（目次）だけから確認できるのは、Duskが同一チェーンのもとで2種類の取引を文書化していることです。私はそれらの章の本文全文を読んでいないため、機械的に（仕組みとして）どう違うのかを確実に検証できません。とはいえ、名称の付け方と一般的な業界パターンから、一方はおそらく透明／口座（アカウント）ベースで、もう一方はプライバシーを重視した設計である可能性が高いと推測しています。これはこの出典から確認できた事実ではなく、仮定です。

TOCで確認できることは他にもあります。コンセンサスは6つの完全な小節（3.1〜3.9、6〜11ページ）に分かれています。すなわち、プロビジョナー（provisioners）、委員会（committees）、アテステーション（attestations）、ソーティション（sortition）、非常モード（emergency mode）、フォールバック（fallback）、ローリング・ファイナリティ（rolling finality）、インセンティブ（incentives）。これはファイナリティだけを見てもかなり密な構造です。目次の範囲では、この設計が大規模な敵対的条件下でテスト済みかどうかは検証できません。そうするには、実際の技術内容、監査、メインネットのデータなどが必要ですが、現時点ではそれらが手元にありません。

だから私の率直な立場はこうです：この論文の構造は、透明な取引と機密な取引の取り扱いを意図的に分離していることを示唆しています。これは規制のある金融ユースケースにとって重要です。しかし、フォールトトレランスや委員会のレジリエンス（耐障害性）についての主張は、独立した検証が必要です。監査、インシデントの履歴、あるいは第三者によるレビュー—それらがない限り、私は「確定した事実」として扱いません。

誰かが、Duskのコンセンサスメカニズムを独立したセキュリティ監査で実際にレビューしたのか、それともまだ未了なのですか？ $TAC.US
$SOON