#dusk 私はDuskの没収（罰没）メカニズムをもう一度分解してみて、最も誤読されやすいのは「罰の強度」ではなく、そもそも「ソフト罰」と「ハード罰」が別物だという点だと分かりました。公式ドキュメントでは明確に区別されています。ソフト罰は、コンセンサス参加の失敗に対するものです。たとえば、Provisionerが指定時間内にブロックを生成できなかったり、投票しなかったりするケース。ハード罰は、証明可能な悪意の行為に対するものです。同じ高さで署名が競合する提案、または同じコンセンサス鍵が複数のノードで同時に実行されることなど。
両者の結果の違いは非常に大きいです。ソフト罰では、Provisioner資格が$SNDKB 一時停止され、active stakeの一部がlocked stakeに移されます。なお、locked stakeはあくまで誓約者本人のものですが、いったんコンセンサスには参加せず、報酬も発生しません。これは資産がそのまま差し引かれるのとは完全に別です。ハード罰こそが、DUSKの一部を実際に燃やしてしまう（焼き捨てる）のです。
ETHエコシステム出身のユーザーなら、ETH2.0のslashingには直感が働くはずですが、Duskにはその上に「ソフト罰」という緩衝層があります。これは運用担当者に修正の猶予を与えます。ネットワークの揺らぎで投票に間に合わなかったとしても、コインが直接燃やされるわけではありませんが、一時的に「端に寄せられる（席を外す）」ことになります。けれども、故意に悪事を働くなら、それは別問題です。$SPCXB
一般的な$DUSK 保有者にとって、ノードを動かす上で本当に注視すべきなのは利回りではなく、「自分のコンセンサス鍵が唯一の1台のマシンでのみ動いているか」という点です。ドキュメントは何度もこの点を強調していますが、多くの人はクラウドサーバで自動フェイルオーバー（自動切り替え）を入れると便利だと感じています。その結果、古いインスタンスが完全に停止しきらないうちに、新しいインスタンスが起動してしまい、結果として2つのインスタンスが同時に稼働してしまう。これはそのままハード罰を引き起こします。
だから私は、@Dusk 今後運用ダッシュボードで最も示すべきなのはAPYではなく、ノードの健全性、コンセンサス鍵の一意性チェック、そしてソフト罰のリスクがあるかどうかだと思います。誓約者は、万事が起きてからでないとドキュメントを開けません。
#dusk @Dusk