# 安全なジレンマの詳細な分析:警備員はバベルの契約塔を再建できるか?2025年2月21日、暗号通貨業界は史上最も深刻な資産管理危機に直面しました。ある取引プラットフォームのオンチェーンマルチシグウォレットが標的攻撃を受け、約15億ドルの資産が"合法的な署名"の取引によって静かに流出しました。その後のオンチェーン分析によると、攻撃者は精密なソーシャルエンジニアリング攻撃を通じてマルチシグ権限を取得し、SafeコントラクトのdeleGatecall機能を利用して悪意のあるロジックを埋め込み、最終的にマルチシグ検証メカニズムを回避し、資金を匿名アドレスに移転させました。この事件は残酷な現実を暴露しています："マルチシグ"は"絶対的な安全"を意味するものではなく、Safeマルチシグウォレットのような安全メカニズムであっても、追加の防護措置が欠如している場合、攻撃されるリスクが依然として存在します。これはSafeマルチシグウォレットに対する最初の攻撃事例ではありません。昨年、2つのプラットフォームがそれぞれ2.3億ドルと5,000万ドルの損失を被り、同様の攻撃手法に直面しました。Safeマルチシグウォレットの攻撃事件は以下の技術的な同源性を示しています：* 過度に署名メカニズムに依存：安全責任をすべて秘密鍵の管理に委ねる。* ダイナミックディフェンスの欠如：取引実行前のリアルタイムリスクスキャンが不足している。* 権限管理の粗粒度：deleGatecallなどの高リスク操作に対してホワイトリストメカニズムが構築されていない。この一連の出来事の核心的な問題は、Safe契約自体にあるのではなく、全体システムの統合プロセスにおける安全上のリスク、特にフロントエンドの検証段階にあります。これにより、私たちは以下のことを考える必要があります：Safeの追加の安全措置メカニズムを通じて、マルチシグウォレットの保護能力をどのように強化できるか？! [安全なジレンマを深く掘り下げる:警備員はバベルのコンパクトな塔を再建できるか? ](https://img-cdn.gateio.im/social/moments-7abedb36995e926e2ebaa369f26de7d0)## セーフSafeは、複数の署名(Multi-Sig)ウォレットで、高価値の資産とデジタル通貨の安全な保管と移転を管理するために主に使用されます。去中心化資産管理のインフラストラクチャとして、それは複数の当事者による協調検証メカニズムを通じて資金操作の安全性を確保し、単一の管理者またはハッカーが単一障害点を利用して悪意のある操作を行うのを防ぎます。DAOガバナンス、企業資金の保管、去中心化ファンドプールなどのシナリオで広く使用されています。この契約はSafeチームによって開発され、現在の業界標準のオンチェーン資産管理ソリューションです。契約はEIP-712標準を採用して構造化データの署名を実現し、取引データの安全性と検証可能性を向上させています。### コア用途* 資金安全管理：契約により、複数の事前に設定された所有者(Owners)が共同で取引を確認しなければならず、これにより単一の誤りや悪意のある操作を効果的に防止し、資金の安全を確保します。* 取引の実行と管理：内蔵のマルチシグ検証メカニズムを通じて、契約は署名閾値条件を満たす場合に外部送金、他の契約の呼び出し、または複雑なビジネスロジックの処理を実行でき、トークンとネイティブコインの支払いおよび手数料の補償をサポートします。* モジュール化拡張：契約はモジュール化設計を採用しており、複数の管理モジュール（OwnerManager、ModuleManager、GuardManager、FallbackManagerなど）を継承および組み合わせることで、その機能を柔軟かつ拡張しやすくし、さまざまなアプリケーションシーンにカスタマイズされたサポートを提供します。### 関数解析execTransaction関数は、マルチシグネチャ検証を経た取引を実行します。* 取引のユニークなハッシュ値を計算する（取引パラメータ、nonceなどを組み合わせる）；* すべての署名の有効性を検証し、各署名が合法的な所有者または事前に承認されたアドレスからのものであることを確認します；* ターゲットアドレスのビジネスロジックを呼び出し、トランザクション実行後にイベントを通じて成功または失敗の状態を記録します；* 柔軟なガス料金の処理をサポートし、補償の支払い時に取引コストを正確に計算します。checkContractSignatures 関数と checkNSignatures 関数は、トランザクションまたはメッセージの署名データを検証します。* EOAアカウントの署名、コントラクト署名(EIP-1271)、及び事前承認されたハッシュをそれぞれ処理する；* 所有者の順序に従って署名が並べられていることを確認し、各署名が有効なアドレスからのものであることを確認して、リプレイ攻撃や署名の改ざんを防ぎます。getTransactionHash関数は、署名検証とリプレイ攻撃を防ぐための取引ハッシュを生成します。* EIP-712標準を利用して取引データを構造化ハッシュする；* インラインアセンブリを使用してメモリ操作を最適化し、計算効率を向上させる；* 現在のnonce値を組み合わせて、各取引のユニーク性を確保します。handlePayment関数は、取引プロセス中のガス補償支払いを処理します。* 実際に消費されたガス料金と基本料金に基づいて支払い金額を計算します；* ETHおよび他のトークンでの支払いをサポートし、手数料の補償が正確であることを保証します。onBeforeExecTransactionは内部仮想フック関数で、execTransaction関数が実行される前に呼び出されます。この関数の設計目的は、Safeコントラクトを継承するサブコントラクトが取引実行前にカスタムロジック処理を行えるようにすることです。受け取るパラメータセットには、次のものが含まれます：* to：対象アドレス - 取引が呼び出すコントラクトまたはアカウントのアドレス* value：イーサリアム値 - 取引に送信されるイーサリアムの数量* data：データペイロード - 関数セレクターとパラメーターを含む呼び出しデータ* operation: 操作の種類 - CALL か DELEGateCALL かを判別します。* safeTxGas：取引ガス制限 - 取引実行のために予約されたガスの数* baseGas：基本ガス - 取引の実行に依存しないガスコスト* gasPrice:ガス価格 - 取引手数料の補償を計算するために使用されるガス価格* gasToken：ガス代币 - 取引手数料を支払うためのトークンアドレス* refundReceiver: Refund Receiver - 取引手数料の払い戻しを受け取るアドレス* signatures：署名コレクション - 所有者の取引に対する署名データマルチシグウォレット契約は、その厳格なセキュリティ設計と柔軟なモジュール構造により、デジタル資産管理に高効率かつ安全なソリューションを提供し、取引の初期化から最終実行までの全プロセスの安全管理を実現し、ブロックチェーンの安全管理において重要なツールとなっていますが、同様に注意が必要なのは、被害者の多くがハードウェアウォレットを使用して署名を行っていることです。一部のハードウェアデバイスは構造化データの署名表示が不十分であり、ユーザーが短時間で取引データを正確に認識できない可能性が高く、"ブラインド署名"のリスクを引き起こすことがあります。この現象に対処するために、ハードウェアとそのデータ表示効果を最適化するだけでなく、マルチコンファーム、スマートヒント、署名検証ツールの強化などの手段を探ることによって、ブラインド署名による安全リスクをさらに低減することができます。! [安全なジレンマを深く掘り下げる:警備員はバベルのコンパクトな塔を再建できるか? ](https://img-cdn.gateio.im/social/moments-e4f0b0daf2f48ba716dc7fdddcfdabec)## セーフガードSafe合約は1.3.0バージョンで導入された重要なセキュリティ機能 - Safe Guardメカニズム。このメカニズムは、標準のn-out-of-mマルチシグネチャスキームに追加の制限条件を提供し、取引の安全性をさらに強化することを目的としています。Safe Guardの核心的な価値は、取引実行の異なる段階でセキュリティチェックを行うことができる点です。* 取引前チェック(checkTransaction)：Guardメカニズムは、取引が実行される前に、取引のすべてのパラメータをプログラム的にチェックし、取引が事前に設定されたセキュリティルールに準拠していることを確認します。* 取引後の(checkAfterExecution)：取引の実行が完了した後、Guardは追加のセキュリティ検証を行い、取引実行後のSafeウォレットの最終状態が期待通りであるかを確認します。### アーキテクチャ分析Safeにおいて、マルチシグトランザクションは一般的にexecTransaction関数を介して実行されます。Safe Guardが有効な場合、ユーザーがマルチシグトランザクションを実行すると、SafeコントラクトはGuardコントラクトのcheckTransaction関数を呼び出してトランザクションの前チェックを実行します。そして、マルチシグトランザクションの実行が完了した後、SafeコントラクトはGuardコントラクトのcheckAfterExecution関数を呼び出してトランザクションの実行結果をチェックします。SafeコントラクトがGuardメカニズムを介してマルチシグトランザクションの事前検査を実行する際、そのcheckTransaction関数はターゲットコントラクトアドレス、呼び出し方法、実行データ（例：deleGatecall）、オーナー署名情報、Gas設定および支払い情報を含む完全なトランザクションコンテキストデータを受け取ります。このメカニズムにより、開発者はマルチディメンションのリスク管理戦略を実現できます。たとえば、コントラクトホワイトリスト管理（相互作用可能なアドレスを制限）、関数レベルの権限管理（危険な関数選択子を無効にする）、トランザクション頻度制限、資金の流れに基づく動的ルールなどです。Guard戦略を適切に構成することで、攻撃者がコントラクトレイヤーを利用して攻撃するのを効果的に阻止できます。最近のセキュリティ事件が続出する中で、各方面がマルチシグウォレット契約の安全性にますます注目しています。ハードウェアウォレットプロバイダーは、類似のリスクの再発を防ぐために、Safe契約の解析と防護能力の強化を呼びかけています。ある取引プラットフォームの事件を受けて、多くのプロジェクトがSafe契約に焦点を当て、Guardメカニズムに基づくアップグレードや拡張のソリューションを探求し始めました。その中には、Guardメカニズムに基づく革新的なアプリケーションもあり、Safeマルチシグウォレットの上に構築された中間層の安全ソリューションを提供し、基盤資産とユーザー資産の間に追加の安全保障を提供しています。その核心的な役割は、Safeマルチシグ取引に関与するターゲット契約、呼び出し方法、実行データ、オーナー署名情報、支払い情報、ガス情報をcheckTransaction関数に渡すことで、取引の極めて細かい粒度のチェックを実現することです。これには、ホワイトリスト契約の呼び出し、ホワイトリスト関数の操作、ホワイトリスト転送対象、取引頻度などの権限管理が含まれます。注目すべきは、Safe自体はGuardの管理とコールバック機能のみを提供し、実際のマルチシグトランザクションのチェックロジックはユーザー自身が実装する必要があり、その安全性はGuardの実装の質に依存するということです。一部のソリューションはこの考え方を拡張し、各Vaultに専用のGuardianを設定して許可されたターゲットアドレスと操作権限を指定し、許可されたコントラクトを指定し、許可された関数操作を定義し、ACL検証の要件という三つの権限制御要素を実現しています。同時に、分離されたガバナンスメカニズムを採用し、Vault Guardianが実行を担当し、Governorがガバナンス権限を管理することで、Guardianに問題が発生しても、ユーザー資産を保護するために迅速に是正措置を講じることができます。同様の設計理念は他のプロジェクトのセキュリティモジュールにも適用されており、重要な操作をインターセプトし、ホワイトリストメカニズムを利用してモジュールのインストール、フックの設定、バリデーターの管理などの高リスク操作を精密に制御することで、信頼されたコントラクトのみがシステムに追加されることを保証し、ウォレットに持続的な安全保障を提供しています。ある取引プラットフォームのイベント攻撃チェーンにおいて、Safeコントラクトが合理的に構成されたGuardメカニズムを展開している場合、攻撃者がexecTransactionを通じて発起した悪意のあるdeleGatecallは、プリチェック段階で複数のポリシーによって遮断されます：GuardのcheckTransaction関数は最初にdeleGatecallの操作タイプを認識し、禁止ルールをトリガーします（例えばoperationを単なる呼び出しに制限することを強制）。次に、dataフィールドを解析して非常規コントラクトアドレス及び高リスク関数セレクターを検出し、プリセットされたコントラクトホワイトリスト及び関数ブラックリストポリシーを通じて直接トランザクションをロールバックします。最終的に「ポリシー遮断 → 論理阻止」の防御システムを形成し、ストレージ改ざんと資金移転パスを完全に遮断します。! [安全なジレンマを深く掘り下げる:警備員はバベルのコンパクトな塔を再建できるか? ](https://img-cdn.gateio.im/social/moments-4947f64f2aa4163ee644b6f8e911c6f8)全体的に言えば、Safeは1.3.0バージョン以降にのみGuard機能を提供していますが、Guardは非常に細かいマルチシグトランザクションのチェックを提供することができます。しかし、ユーザーがGuard機能を使用する際にはかなりのハードルがあります。彼らは自分でGuardチェックロジックを実装する必要があり、粗雑または欠陥のあるGuard実装はユーザーがSafeウォレットのセキュリティを向上させるのに役立たない可能性があります。したがって、Guard実装のセキュリティ監査は必要です。疑いの余地なく、安全で適切なGuard実装はSafeウォレットのセキュリティを大幅に向上させることができます。## 結論と展望ある取引プラットフォームが攻撃を受けた事件は、セキュリティインフラのタイムリーな更新の重要性を浮き彫りにしました。このプラットフォームはv1.1.1（<1.3.0）バージョンのSafeコントラクトを使用しており、これは彼らがGuardメカニズムという重要なセキュリティ機能を使用できないことを意味します。もしこのプラットフォームが1.3.0以上のSafeコントラクトにアップグレードし、資金を受け取るためのホワイトリストアドレスを指定し、厳格なコントラクト関数ACL検証を実施する適切なGuardメカニズムを実装していれば、この損失を回避できたかもしれません。これはあくまで仮定ですが、将来の資産セキュリティ管理に重要な示唆を提供しています。Safe Guardメカニズムは、デジタル資産の金庫に取り付けられたスマートセキュリティシステムのようなもので、その効果はルール設計の厳密性と実施の質に依存します。ますます精巧な攻撃手段に直面して、私たちは必要です：* 自動化検証：自動化された取引検証メカニズムを構築する* ダイナミックポリシー調整：脅威インテリジェンスに基づいてセキュリティポリシーをリアルタイムで調整* 多層防御：複数のセキュリティメカニズムを組み合わせてデプス防御システムを構築* 継続的監査：Guardの実装に対する定期的なセキュリティ監査未来のデジタル資産管理は、スマートコントラクトになるでしょう。
Safe Guardメカニズム：マルチ署名ウォレットの安全アーキテクチャを再構築する新しい方向性
安全なジレンマの詳細な分析:警備員はバベルの契約塔を再建できるか?
2025年2月21日、暗号通貨業界は史上最も深刻な資産管理危機に直面しました。ある取引プラットフォームのオンチェーンマルチシグウォレットが標的攻撃を受け、約15億ドルの資産が"合法的な署名"の取引によって静かに流出しました。その後のオンチェーン分析によると、攻撃者は精密なソーシャルエンジニアリング攻撃を通じてマルチシグ権限を取得し、SafeコントラクトのdeleGatecall機能を利用して悪意のあるロジックを埋め込み、最終的にマルチシグ検証メカニズムを回避し、資金を匿名アドレスに移転させました。
この事件は残酷な現実を暴露しています："マルチシグ"は"絶対的な安全"を意味するものではなく、Safeマルチシグウォレットのような安全メカニズムであっても、追加の防護措置が欠如している場合、攻撃されるリスクが依然として存在します。これはSafeマルチシグウォレットに対する最初の攻撃事例ではありません。昨年、2つのプラットフォームがそれぞれ2.3億ドルと5,000万ドルの損失を被り、同様の攻撃手法に直面しました。Safeマルチシグウォレットの攻撃事件は以下の技術的な同源性を示しています：
この一連の出来事の核心的な問題は、Safe契約自体にあるのではなく、全体システムの統合プロセスにおける安全上のリスク、特にフロントエンドの検証段階にあります。これにより、私たちは以下のことを考える必要があります：Safeの追加の安全措置メカニズムを通じて、マルチシグウォレットの保護能力をどのように強化できるか？
! 安全なジレンマを深く掘り下げる:警備員はバベルのコンパクトな塔を再建できるか?
セーフ
Safeは、複数の署名(Multi-Sig)ウォレットで、高価値の資産とデジタル通貨の安全な保管と移転を管理するために主に使用されます。去中心化資産管理のインフラストラクチャとして、それは複数の当事者による協調検証メカニズムを通じて資金操作の安全性を確保し、単一の管理者またはハッカーが単一障害点を利用して悪意のある操作を行うのを防ぎます。DAOガバナンス、企業資金の保管、去中心化ファンドプールなどのシナリオで広く使用されています。この契約はSafeチームによって開発され、現在の業界標準のオンチェーン資産管理ソリューションです。契約はEIP-712標準を採用して構造化データの署名を実現し、取引データの安全性と検証可能性を向上させています。
コア用途
関数解析
execTransaction関数は、マルチシグネチャ検証を経た取引を実行します。
checkContractSignatures 関数と checkNSignatures 関数は、トランザクションまたはメッセージの署名データを検証します。
getTransactionHash関数は、署名検証とリプレイ攻撃を防ぐための取引ハッシュを生成します。
handlePayment関数は、取引プロセス中のガス補償支払いを処理します。
onBeforeExecTransactionは内部仮想フック関数で、execTransaction関数が実行される前に呼び出されます。この関数の設計目的は、Safeコントラクトを継承するサブコントラクトが取引実行前にカスタムロジック処理を行えるようにすることです。受け取るパラメータセットには、次のものが含まれます：
マルチシグウォレット契約は、その厳格なセキュリティ設計と柔軟なモジュール構造により、デジタル資産管理に高効率かつ安全なソリューションを提供し、取引の初期化から最終実行までの全プロセスの安全管理を実現し、ブロックチェーンの安全管理において重要なツールとなっていますが、同様に注意が必要なのは、被害者の多くがハードウェアウォレットを使用して署名を行っていることです。一部のハードウェアデバイスは構造化データの署名表示が不十分であり、ユーザーが短時間で取引データを正確に認識できない可能性が高く、"ブラインド署名"のリスクを引き起こすことがあります。この現象に対処するために、ハードウェアとそのデータ表示効果を最適化するだけでなく、マルチコンファーム、スマートヒント、署名検証ツールの強化などの手段を探ることによって、ブラインド署名による安全リスクをさらに低減することができます。
! 安全なジレンマを深く掘り下げる:警備員はバベルのコンパクトな塔を再建できるか?
セーフガード
Safe合約は1.3.0バージョンで導入された重要なセキュリティ機能 - Safe Guardメカニズム。このメカニズムは、標準のn-out-of-mマルチシグネチャスキームに追加の制限条件を提供し、取引の安全性をさらに強化することを目的としています。Safe Guardの核心的な価値は、取引実行の異なる段階でセキュリティチェックを行うことができる点です。
アーキテクチャ分析
Safeにおいて、マルチシグトランザクションは一般的にexecTransaction関数を介して実行されます。Safe Guardが有効な場合、ユーザーがマルチシグトランザクションを実行すると、SafeコントラクトはGuardコントラクトのcheckTransaction関数を呼び出してトランザクションの前チェックを実行します。そして、マルチシグトランザクションの実行が完了した後、SafeコントラクトはGuardコントラクトのcheckAfterExecution関数を呼び出してトランザクションの実行結果をチェックします。
SafeコントラクトがGuardメカニズムを介してマルチシグトランザクションの事前検査を実行する際、そのcheckTransaction関数はターゲットコントラクトアドレス、呼び出し方法、実行データ（例：deleGatecall）、オーナー署名情報、Gas設定および支払い情報を含む完全なトランザクションコンテキストデータを受け取ります。このメカニズムにより、開発者はマルチディメンションのリスク管理戦略を実現できます。たとえば、コントラクトホワイトリスト管理（相互作用可能なアドレスを制限）、関数レベルの権限管理（危険な関数選択子を無効にする）、トランザクション頻度制限、資金の流れに基づく動的ルールなどです。Guard戦略を適切に構成することで、攻撃者がコントラクトレイヤーを利用して攻撃するのを効果的に阻止できます。
最近のセキュリティ事件が続出する中で、各方面がマルチシグウォレット契約の安全性にますます注目しています。ハードウェアウォレットプロバイダーは、類似のリスクの再発を防ぐために、Safe契約の解析と防護能力の強化を呼びかけています。ある取引プラットフォームの事件を受けて、多くのプロジェクトがSafe契約に焦点を当て、Guardメカニズムに基づくアップグレードや拡張のソリューションを探求し始めました。その中には、Guardメカニズムに基づく革新的なアプリケーションもあり、Safeマルチシグウォレットの上に構築された中間層の安全ソリューションを提供し、基盤資産とユーザー資産の間に追加の安全保障を提供しています。その核心的な役割は、Safeマルチシグ取引に関与するターゲット契約、呼び出し方法、実行データ、オーナー署名情報、支払い情報、ガス情報をcheckTransaction関数に渡すことで、取引の極めて細かい粒度のチェックを実現することです。これには、ホワイトリスト契約の呼び出し、ホワイトリスト関数の操作、ホワイトリスト転送対象、取引頻度などの権限管理が含まれます。
注目すべきは、Safe自体はGuardの管理とコールバック機能のみを提供し、実際のマルチシグトランザクションのチェックロジックはユーザー自身が実装する必要があり、その安全性はGuardの実装の質に依存するということです。一部のソリューションはこの考え方を拡張し、各Vaultに専用のGuardianを設定して許可されたターゲットアドレスと操作権限を指定し、許可されたコントラクトを指定し、許可された関数操作を定義し、ACL検証の要件という三つの権限制御要素を実現しています。同時に、分離されたガバナンスメカニズムを採用し、Vault Guardianが実行を担当し、Governorがガバナンス権限を管理することで、Guardianに問題が発生しても、ユーザー資産を保護するために迅速に是正措置を講じることができます。同様の設計理念は他のプロジェクトのセキュリティモジュールにも適用されており、重要な操作をインターセプトし、ホワイトリストメカニズムを利用してモジュールのインストール、フックの設定、バリデーターの管理などの高リスク操作を精密に制御することで、信頼されたコントラクトのみがシステムに追加されることを保証し、ウォレットに持続的な安全保障を提供しています。
ある取引プラットフォームのイベント攻撃チェーンにおいて、Safeコントラクトが合理的に構成されたGuardメカニズムを展開している場合、攻撃者がexecTransactionを通じて発起した悪意のあるdeleGatecallは、プリチェック段階で複数のポリシーによって遮断されます：GuardのcheckTransaction関数は最初にdeleGatecallの操作タイプを認識し、禁止ルールをトリガーします（例えばoperationを単なる呼び出しに制限することを強制）。次に、dataフィールドを解析して非常規コントラクトアドレス及び高リスク関数セレクターを検出し、プリセットされたコントラクトホワイトリスト及び関数ブラックリストポリシーを通じて直接トランザクションをロールバックします。最終的に「ポリシー遮断 → 論理阻止」の防御システムを形成し、ストレージ改ざんと資金移転パスを完全に遮断します。
! 安全なジレンマを深く掘り下げる:警備員はバベルのコンパクトな塔を再建できるか?
全体的に言えば、Safeは1.3.0バージョン以降にのみGuard機能を提供していますが、Guardは非常に細かいマルチシグトランザクションのチェックを提供することができます。しかし、ユーザーがGuard機能を使用する際にはかなりのハードルがあります。彼らは自分でGuardチェックロジックを実装する必要があり、粗雑または欠陥のあるGuard実装はユーザーがSafeウォレットのセキュリティを向上させるのに役立たない可能性があります。したがって、Guard実装のセキュリティ監査は必要です。疑いの余地なく、安全で適切なGuard実装はSafeウォレットのセキュリティを大幅に向上させることができます。
結論と展望
ある取引プラットフォームが攻撃を受けた事件は、セキュリティインフラのタイムリーな更新の重要性を浮き彫りにしました。このプラットフォームはv1.1.1（<1.3.0）バージョンのSafeコントラクトを使用しており、これは彼らがGuardメカニズムという重要なセキュリティ機能を使用できないことを意味します。もしこのプラットフォームが1.3.0以上のSafeコントラクトにアップグレードし、資金を受け取るためのホワイトリストアドレスを指定し、厳格なコントラクト関数ACL検証を実施する適切なGuardメカニズムを実装していれば、この損失を回避できたかもしれません。これはあくまで仮定ですが、将来の資産セキュリティ管理に重要な示唆を提供しています。
Safe Guardメカニズムは、デジタル資産の金庫に取り付けられたスマートセキュリティシステムのようなもので、その効果はルール設計の厳密性と実施の質に依存します。ますます精巧な攻撃手段に直面して、私たちは必要です：
未来のデジタル資産管理は、スマートコントラクトになるでしょう。