#dusk $DUSK

正直、驚いています。5Kの閲覧を得たのに5ポイントのみとは、本当に不公平で、がっかりです。

重い気持ちで今日投稿します…でも投稿の前に、ちょっとスキャルプをどうぞ：

Long $PORTAL 📈
Short $CYS 📉
利益を予約（ブック）するときは、忘れずに感謝してください

当初、@Dusk でスラッシュされたのは「ある意味では1つのこと」を意味すると思っていました：ステークを失ってノードをやり直す。

でも、リカバリーガイドはもっとはっきり線引きしています。

ソフトペナルティは、プロビジョナーの資格を停止させたり、アクティブステークの一部をロックドステークへ移したりできます。そのステークはオペレーターに属したままで、アンステーク可能です。

ハードペナルティは、矛盾する投票やエクイボケーションのような、証明可能な無効なコンセンサス行動に適用されます。ステークの一部は焼失し、再起動や再ステークでも取り戻せません。

その違いが刺さりました。

Duskは、参加の取り逃しと、矛盾した参加を別物として扱います。古いバージョン、延びたダウンタイム、同期不良、あるいはブロックされたネットワークトラフィックは、運用上の失敗を生みえます。矛盾するメッセージへの署名は、プロトコルが無効だったと証明できる振る舞いに踏み込むことになります。

重複キーの警告が、その境界を実用的にします。

同じコンセンサスキーを2つのアクティブノードで動かすと、オペレーターが「2つ目はバックアップだけのはず」と思っていても、両方のマシンが互いに両立しないメッセージへ署名してしまう可能性があります。

リカバリーは、新しいプロビジョナーのポジションを作る前に、バージョン・同期・接続性・キー設定を直すことから始めるのが良いと思います。原因を見つけずに再ステークしても、同じ壊れたセットアップの背後に新しいポジションを置くだけになってしまいます。

また、このモデルは冗長性も慎重に設計しないといけないことを意味します。可用性を高めるために意図したバックアップでも、同じキーでアクティブになってしまうとハード・スラッシングのリスクが発生します。

運用上の失敗とエクイボケーションを分けて、より公平なペナルティにできるのでしょうか？それとも、プロビジョナー運用で最も容赦ないのはコンセンサスキー管理だということになるのでしょうか？
@Duskでのプロビジョナーのスラッシングは、興味深い問いを提起します
バリデータを安全に保つのに、何がより重要ですか？