#dusk $DUSK A セキュリティインシデントは、ロードマップでは決して伝えてくれないことを教えてくれます。システムが実際に壊れたとき、チームがどう振る舞うのか。
1月16日、攻撃者が Dusk のブリッジサービスで使われている署名ウォレットに不正にアクセスしました。重要なのは、Dusk のポストモーテムでは、これはコンセンサスの失敗でも中核プロトコルのエクスプロイトでもなく、ブリッジウォレットの侵害だったと明記されていることです。
私の注意を引いたのは、インシデントそのものではありません。むしろ、その後に起きたことです。
侵害されたウォレットを単に置き換えるのではなく、Dusk はブリッジのアーキテクチャを再設計しました。署名はイベント処理から切り離されました。資金のリリースはイベントの取り込みから切り離されました。新しいシステムでは明示的なトランザクションのライフサイクルを用い、ホットウォレットの露出を減らし、ブリッジホストを強化しています。
「バグを直しました」と言うより、はるかに面白い対応です。
ここでの教訓は $DUSK にとどまりません。ブリッジは長年、暗号インフラで最も悪用されてきた部分です。理由は明確で、1か所に経済的な権限をこれほど集中させているからです。
ブリッジには経済的な権限があります。したがって、その運用設計はセキュリティモデルの一部になります。もし1つの侵害された鍵が行き得る範囲が広すぎるなら、問題はその鍵だけではありません。そもそもその鍵にどれだけの権限をアーキテクチャが与えていたのかが問題なのです。
規制のあるオンチェーン・ファイナンスを目指すプロジェクトにとって、これは特に重要です。機関は、インフラが通常時に機能するかどうかだけでなく、何かがうまくいかなかったときにどうなるのかを、いずれ必ず尋ねてきます。
その点で、私は Dusk の再設計に注目すべきだと思っています。
セキュリティ上の主張は簡単に公表できます。失敗の後にアーキテクチャを変更するのは、ずっと難しい。
それでは、ブロックチェーンがインシデント後にどう応答するかに、これまでに約束したすべてよりも、より重みを置きたいと思いませんか？
@Dusk $DUSK #dusk
$EDEN