Duskのプライバシーは、ネットワークがストレスを受けて初めて本当に信頼に値する

自分のPhoenixに対する見方を変えたのは、「見えない＝検証不要」というわけではないと気づいたことです。
シールド取引では、Moonlightのように公開のオブザーバーからは送信者・受信者・金額が見えませんが、それでも取引が状態として受理される前に、ネットワークによる検証が必要です。DuskDSは、その後ブロックを提案し、検証し、承認（ratification）することで決定的なファイナリティを達成します。
通常時、このモデルはかなりコンパクトです。自分がもっと詳しく見たいのは、ネットワークが混雑しているときです。
公開取引と機密取引の両方が同時にシステムへ圧力をかける条件では、コミッティが頻繁に入れ替わり、一部のプロビジョナがリズムについていけなくなります。すると、プライバシーはもはや唯一の論点ではありません。ネットワークは、検証基準を下げることなく、livenessとfinalityを維持しなければならないのです。
自分が妥当だと思う点は、Duskがすべてのエラーを同一視しないことです。任務を見逃したプロビジョナはソフトペナルティの対象になり得ますが、不正であると証明できる行為、たとえば無効な投票や矛盾する署名は、ハードペナルティにつながり得ます。
これが、個別のプライベート取引が順調に動くよりもずっと見応えのあるテストだと思います。
優れたプライバシー・システムは、普段通りに動いているときだけデータを隠せればよいのではありません。ノードが同期から外れ、コミッティが入れ替わり、ネットワーク負荷が急増しても、検証可能性を維持し続けなければなりません。
Duskがこの境界を保てるなら、そのとき初めてプライバシーは、単なるウォレット上の体験ではなく、インフラの特性になります。
@Dusk $DUSK #dusk
$RICE $BTW