ここ数日、私は@Dusk のことを何度も何度も思い返してしまっています。注目を集めやすい派手な出来事があるからではなく、プロジェクトの中のもっと静かな部分が、ずっと私の考えを引きつけ続けているからです。
8月16日のインシデントで私が評価しているのは、チームの対応の速さです。資金の流れを止めるために素早く動き、影響を受けたアドレスを差し替え、さらにWebウォレットのブロックリストにそれらのアドレスを追加しました。インシデント後の対応としては、かなり見慣れた手順です。
しかし、インシデント後に新しいアドレスを確認してみて、なかなか興味深い点がありました。システムを試すような小さな取引が使われているのではなく、ほとんどが完全に静止していたのです。埃のような残骸もない、テストの形跡もない、誰かがシステムの反応を確かめようとしている気配もありませんでした。1週間以上、そのアドレスは黙ったままで、ブリッジはオフラインのまま維持されていました。
エクスプロイトのあとで私がいちばん際立たせて考えるのは、脆弱性が起きたことそのものよりも、#dusk がその後に何を選んだかです。彼らはユーザーの需要に合わせてブリッジを素早く復旧できたかもしれません。ですが、その代わりにすべてを停止したままにしました。新しいアドレスには一切手が加えられていません。誰も彼らに待つよう強制したわけではないのに、それでも、別の安全層を得る代わりに、より不便な選択を選んだのです。
正直なところ、これを「良いリスク管理」なのか「単に復旧が遅い」なのか、まだラベルを貼りたい気持ちはありません。たぶん答えはその中間にあるのかもしれません。より確かなのは、インシデント後にはオンチェーンの追加活動がほとんどなく——そして、その沈黙自体が、かなり注目に値するということです。
このデータを追っている人がいるのか気になります。インシデントのあと、各ブリッジは実際にオンラインに戻るまで、通常どれくらい「沈黙」した状態が続くのでしょうか? その沈黙期間こそが、チームが本当にどのようにリスク管理へ取り組むのかを見抜く、もっとも分かりやすい手がかりの一つになり得るのかもしれません。$DUSK $BMT $FOREST
8月16日のインシデントで私が評価しているのは、チームの対応の速さです。資金の流れを止めるために素早く動き、影響を受けたアドレスを差し替え、さらにWebウォレットのブロックリストにそれらのアドレスを追加しました。インシデント後の対応としては、かなり見慣れた手順です。
しかし、インシデント後に新しいアドレスを確認してみて、なかなか興味深い点がありました。システムを試すような小さな取引が使われているのではなく、ほとんどが完全に静止していたのです。埃のような残骸もない、テストの形跡もない、誰かがシステムの反応を確かめようとしている気配もありませんでした。1週間以上、そのアドレスは黙ったままで、ブリッジはオフラインのまま維持されていました。
エクスプロイトのあとで私がいちばん際立たせて考えるのは、脆弱性が起きたことそのものよりも、#dusk がその後に何を選んだかです。彼らはユーザーの需要に合わせてブリッジを素早く復旧できたかもしれません。ですが、その代わりにすべてを停止したままにしました。新しいアドレスには一切手が加えられていません。誰も彼らに待つよう強制したわけではないのに、それでも、別の安全層を得る代わりに、より不便な選択を選んだのです。
正直なところ、これを「良いリスク管理」なのか「単に復旧が遅い」なのか、まだラベルを貼りたい気持ちはありません。たぶん答えはその中間にあるのかもしれません。より確かなのは、インシデント後にはオンチェーンの追加活動がほとんどなく——そして、その沈黙自体が、かなり注目に値するということです。
このデータを追っている人がいるのか気になります。インシデントのあと、各ブリッジは実際にオンラインに戻るまで、通常どれくらい「沈黙」した状態が続くのでしょうか? その沈黙期間こそが、チームが本当にどのようにリスク管理へ取り組むのかを見抜く、もっとも分かりやすい手がかりの一つになり得るのかもしれません。$DUSK $BMT $FOREST
Infrastructure 🔧
0%
Privacy 🔐
100%
Scaling ⚡
0%
1 投票 • 投票は終了しました