ダスク・ブリッジのマイグレーション・フローを見に行って、「面白い部分」はEVMコントラクトだと期待していました。ところが実際にあったのは、その裏で動いているサイナー(署名者)でした。
マイグレーション用のコントラクト自体はかなり単純でした。ユーザーはERC20またはBEP20のDUSKをロックし、マイグレーションのイベントが発行されます。しかし、そのイベントが魔法のようにネイティブのDUSKを生み出すわけではありません。外部サービスがそれを監視し、ダスク側で資金を再発行する必要がありました。
この違いは、最初に見える以上に重要です。
ダスクのより広いアーキテクチャは、ラップ資産や外部のカストディアンなしで、DuskDSとDuskEVMの間で価値を移せるネイティブ・ブリッジモデルへと向かっていました。それでも、古いマイグレーション経路は依然として、観測したEVMイベントを実際のダスク取引へ変換するための運用上の署名ウォレットに依存していました。
インシデントのデータは、その依存関係を見える形にしています。1月16日、攻撃者がそのウォレットを侵害し、その後盗んだDUSKをブリッジ経路で移動させました。手順には、まず7,880 DUSKのブリッジ、続いてさらに191万DUSKが含まれ、その後、ミティゲーションによって追加の891万DUSK試行が止められました。
私が重要だと感じるのは、単にウォレットが侵害されたという事実だけではありません。
イベントの取り込みと価値の解放が、事実上1つの運用経路で結びついていた点です。スマートコントラクトは決定的であり得る一方で、それを取り巻くシステムは、鍵の管理(カストディ)、サーバの分離、監視、そしてトランザクション処理に依存しています。
イベント取り込みと署名、さらにマイグレーションイベントを永続化されたジョブへ変換する部分を分離する再設計は、したがって単なるセキュリティパッチ以上の意味があります。信頼が置かれる場所そのものが変わります。
これを読んで、ブリッジについて考え方が変わりました。契約は私たちが最初に精査することが多い部分ですが、真の信頼境界は、契約の数層も後ろ、つまり「いつイベントが金銭になるか」を決めるソフトウェアの内部にある可能性があります。
#dusk $DUSK @Dusk
マイグレーション用のコントラクト自体はかなり単純でした。ユーザーはERC20またはBEP20のDUSKをロックし、マイグレーションのイベントが発行されます。しかし、そのイベントが魔法のようにネイティブのDUSKを生み出すわけではありません。外部サービスがそれを監視し、ダスク側で資金を再発行する必要がありました。
この違いは、最初に見える以上に重要です。
ダスクのより広いアーキテクチャは、ラップ資産や外部のカストディアンなしで、DuskDSとDuskEVMの間で価値を移せるネイティブ・ブリッジモデルへと向かっていました。それでも、古いマイグレーション経路は依然として、観測したEVMイベントを実際のダスク取引へ変換するための運用上の署名ウォレットに依存していました。
インシデントのデータは、その依存関係を見える形にしています。1月16日、攻撃者がそのウォレットを侵害し、その後盗んだDUSKをブリッジ経路で移動させました。手順には、まず7,880 DUSKのブリッジ、続いてさらに191万DUSKが含まれ、その後、ミティゲーションによって追加の891万DUSK試行が止められました。
私が重要だと感じるのは、単にウォレットが侵害されたという事実だけではありません。
イベントの取り込みと価値の解放が、事実上1つの運用経路で結びついていた点です。スマートコントラクトは決定的であり得る一方で、それを取り巻くシステムは、鍵の管理(カストディ)、サーバの分離、監視、そしてトランザクション処理に依存しています。
イベント取り込みと署名、さらにマイグレーションイベントを永続化されたジョブへ変換する部分を分離する再設計は、したがって単なるセキュリティパッチ以上の意味があります。信頼が置かれる場所そのものが変わります。
これを読んで、ブリッジについて考え方が変わりました。契約は私たちが最初に精査することが多い部分ですが、真の信頼境界は、契約の数層も後ろ、つまり「いつイベントが金銭になるか」を決めるソフトウェアの内部にある可能性があります。
#dusk $DUSK @Dusk