@Dusk_Foundation #dusk $DUSK
以前は、プロジェクトの暗号設計が堅牢なら、それだけで自動的に安全になると思っていました。 しかし、数学がどれほど緻密に組まれていても、最も弱い部分はほぼいつも同じものです。つまり、人間の要因です。
@Dusk チームが1月に、ブリッジ運用に使われていたウォレットに紐づく異常な活動を見つけたとき、今回も同じことが起きていました。 実際のプロトコルの欠陥ではありません。ZK証明でも、シールド送金が壊れたわけでもありません。問題だったのは、責任が重すぎる運用用ウォレットでした。
彼らはすぐにブリッジを停止しました。フローの一部がBinanceに触れた時点で、2つのチームは直接連携して封じ込め、ユーザーの資金には影響が出ませんでした。
私が本当に気にしていたのは、その後のことです...
ここで簡単にできるのは、攻撃された1つの箇所をパッチして「直した」と言うことです。 @Dusk はそれをしませんでした。彼らはブリッジの設計全体を作り直したのです。
コンポーネントを分離し、署名とイベント処理を切り離し、トランザクションの流れを段階ごとに明確化し、単一のホットウォレットが抱える露出の量を減らしました。ウェブウォレット側でも、送信前に既知の不正アドレスをフラグするブロックリストを導入しています。
私にとって本当に重要なのは、この部分です。暗号は完璧でも、その周りの運用レイヤーが弱点になり得ます。こうしたシステムはそういう仕組みです。
暗号の世界では問題は起きます。だからこそ、プロジェクトはストレステストを行い、本番投入前にテストネットを回し、ハッカソンでは人々が積極的に壊そうとします。そうすることで、ビルダーは弱点を見つけ、そこから学べるのです。
質問は、「問題が起きるかどうか」ではありません。「起きたときにどうするか」です。 それに一時的な応急処置でバンドエイドを貼りますか 🩹、それとも一連の外科手術🧑⚕️ を行って、根本の設計を修正しますか？
@Dusk_Foundation は設計上の問題を選びました。 #dusk $SPCX $METAB #DUSKARMY.
以前は、プロジェクトの暗号設計が堅牢なら、それだけで自動的に安全になると思っていました。 しかし、数学がどれほど緻密に組まれていても、最も弱い部分はほぼいつも同じものです。つまり、人間の要因です。
@Dusk チームが1月に、ブリッジ運用に使われていたウォレットに紐づく異常な活動を見つけたとき、今回も同じことが起きていました。 実際のプロトコルの欠陥ではありません。ZK証明でも、シールド送金が壊れたわけでもありません。問題だったのは、責任が重すぎる運用用ウォレットでした。
彼らはすぐにブリッジを停止しました。フローの一部がBinanceに触れた時点で、2つのチームは直接連携して封じ込め、ユーザーの資金には影響が出ませんでした。
私が本当に気にしていたのは、その後のことです...
ここで簡単にできるのは、攻撃された1つの箇所をパッチして「直した」と言うことです。 @Dusk はそれをしませんでした。彼らはブリッジの設計全体を作り直したのです。
コンポーネントを分離し、署名とイベント処理を切り離し、トランザクションの流れを段階ごとに明確化し、単一のホットウォレットが抱える露出の量を減らしました。ウェブウォレット側でも、送信前に既知の不正アドレスをフラグするブロックリストを導入しています。
私にとって本当に重要なのは、この部分です。暗号は完璧でも、その周りの運用レイヤーが弱点になり得ます。こうしたシステムはそういう仕組みです。
暗号の世界では問題は起きます。だからこそ、プロジェクトはストレステストを行い、本番投入前にテストネットを回し、ハッカソンでは人々が積極的に壊そうとします。そうすることで、ビルダーは弱点を見つけ、そこから学べるのです。
質問は、「問題が起きるかどうか」ではありません。「起きたときにどうするか」です。 それに一時的な応急処置でバンドエイドを貼りますか 🩹、それとも一連の外科手術🧑⚕️ を行って、根本の設計を修正しますか？
@Dusk_Foundation は設計上の問題を選びました。 #dusk $SPCX $METAB #DUSKARMY.