著者: Artela 中国語ブログ、媒体# 要約再入攻撃は依然として課題であり、既存の防御方法は主にプロトコルのソース コード レベルに焦点を当てており、コントラクトが実行状態に入る前にのみ有効になります。「実行時保護」は DeFi セキュリティの重要な補足であり、「実行結果を保護」し、プロトコルの実行が期待される設計と一致していることを保証することを目的としています。スマート コントラクトは実行時状態の完全なコンテキスト情報にアクセスできないため、EVM の設計は「実行時保護」をサポートしていません。Artela は EVM+Extension 実行層パラダイムを検討し、実行層を強化して再突入攻撃を排除しますArtela は、アスペクト プログラミングを通じてオンチェーンの「ランタイム保護」拡張機能を実装しますAspect を介して Curve コントラクトに対する再入攻撃を防ぐ方法を段階的に示します。# 既存のリスク管理にもかかわらず、リエントランシー攻撃が依然として課題である理由再入攻撃はよく知られた問題であり、多くのリスク管理が導入されていますが、このような攻撃に関連するセキュリティ インシデントは過去 2 年間にわたって発生し続けています。Curve Finance 攻撃 (2023 年 7 月) — Curve は、契約プログラミング言語 Vyper のコンパイルの欠陥により、6,000 万ドルのリエントランシー攻撃を受けました。オリジンプロトコル攻撃 (2022 年 11 月) — 700 万ドルのステーブルコイン プロジェクト オリジン ダラー (OUSD) がリエントランシー攻撃を受けました。サイレン プロトコル攻撃 (2021 年 9 月) — 350 万ドル、AMM プールが再入攻撃を受ける。Cream Finance 攻撃 (2021 年 8 月) - 1,880 万ドル、攻撃者は二次借入の再入可能脆弱性を悪用しました。現在、リエントランシー攻撃の防止はスマートコントラクトのソースコードレベルに重点が置かれており、OpenZeppelinのReentrancyGuardの統合や、事前定義されたセキュリティリスクを回避するためのコントラクトロジックコードのセキュリティ監査の実施などが対策として挙げられている。「ホワイト ボックス」ソリューションとして知られるこのアプローチは、ソース コード レベルで脆弱性を回避し、論理エラーを最小限に抑えることを目的としています。しかし、その主な課題は、未知の隠れた危険に対して防御できないことです。コントラクトをソースコードから実際のランタイムに「変換」するのは、困難なプロセスです。各ステップは開発者にとって予期せぬ問題を引き起こす可能性があり、契約のソース コード自体がすべての潜在的な状況を完全にカバーしていない可能性があります。 Curve の場合、プロトコルのソース コードが正しい場合でも、コンパイラの問題により、最終的な実行とプロトコルの意図した設計との間に不一致が依然として存在する可能性があります。ソース コードおよびコンパイル レベルでのプロトコルのセキュリティに依存するだけでは十分ではありません。ソース コードに問題がないように見えても、コンパイラの問題により脆弱性が予期せず現れる可能性があります。# ランタイム保護が必要ですプロトコルのソース コード レベルに集中し、実行前に有効になる既存のリスク管理対策とは異なり、ランタイム保護では、プロトコル開発者がランタイムの予期せぬ状況に対処するためのランタイム保護ルールと操作を作成する必要があります。これにより、リアルタイムの評価と実行時の実行結果への応答が容易になります。ランタイム保護は、DeFi セキュリティを強化する上で重要であり、既存のセキュリティ対策への重要な追加です。 「ブラック ボックス」方式でプロトコルを保護することで、コントラクト コードの実行を直接妨げることなく、最終的な動作結果がプロトコルの意図した設計と一致することを保証し、セキュリティを強化します。# ランタイム保護の実装における課題残念ながら、スマート コントラクトは完全なランタイム コンテキストにアクセスできないため、EVM 設計はオンチェーンでのランタイム保護をサポートしていません。この課題を克服するにはどうすればよいでしょうか?次の前提条件が必要であると考えられます。トランザクション コンテキスト全体を含む、スマート コントラクト全体のすべての情報へのアクセスを提供する専用モジュール。必要な承認はスマート コントラクトから取得され、必要に応じてトランザクションを元に戻す権利がモジュールに与えられます。スマート コントラクトの実行後、状態がコミットされる前にモジュールの機能が有効になるようにします。EVM は現在、上記の課題に対処する際に限界に直面しており、さらなる革新に対応することができません。モジュラー ブロックチェーンのパラダイムの下では、実行層は EVM を超えるブレークスルーを模索する必要があります。Artela のアイデアは EVM + ネイティブ拡張であり、EVM の WASM ネイティブ拡張レイヤーを構築することで EVM を超えたものを実現します。# アスペクトプログラミングの概要私たちは、ブロックチェーン上のネイティブ スケーリングをサポートする Artela ブロックチェーン用のプログラミング フレームワークである Aspect Programming を開始しました。Aspect は、プログラム可能なネイティブ拡張モジュールであり、スマート コントラクトのモジュラー補足として、実行時にカスタム関数をブロックチェーンに動的に統合し、チェーン上の機能を強化するために使用されます。Aspect の特徴は、ブロックチェーンベースレイヤーのシステムレベル API にアクセスし、トランザクションライフサイクルの各結合ポイントで拡張ロジックを追加できることです。スマート コントラクトは、指定されたアスペクトをバインドして拡張機能をトリガーできます。トランザクションがスマート コントラクトを呼び出すと、トランザクションはコントラクトに関連付けられたアスペクトによっても処理されます。# アスペクトプログラミングがランタイム保護を実装する方法アスペクトは各関数呼び出しの実行状態を記録し、コールバック関数実行中の再入を防ぐことができます。コールバック関数の実行中に再入可能呼び出しが発生すると、Aspect はトランザクションを検出して即座にロールバックし、攻撃者による再入可能性の脆弱性の悪用を防ぎます。このアプローチにより、Aspect は再入攻撃を効果的に排除し、スマート コントラクトのセキュリティと安定性を確保します。アスペクトは、ランタイム保護のための主要なプロパティを実装します。スマート コントラクトの実行後、状態の送信前にトリガー可能: アスペクト モジュールは、スマート コントラクトの実行後、状態の送信前にアクティブ化するように設定できます。完全なトランザクション コンテキスト アクセス: アスペクトは、トランザクション情報全体 (メソッド、パラメーターなど)、コール スタック (実行中のすべての内部コントラクト呼び出し)、状態コンテキストの変更、およびトランザクションによってトリガーされるすべてのイベントを含む、完全なトランザクション コンテキストにアクセスできます。システムコール機能: アスペクトは、必要に応じてシステムコールを実行し、トランザクションリトレースメントを開始できます。スマート コントラクトによるバインドと承認: スマート コントラクトをアスペクトにバインドし、トランザクション処理に参加するためのアクセス許可をアスペクトに付与できます。# 再入保護のためのアスペクトを実装するこの章では、Aspect のランタイム保護をチェーンに実装する方法について説明します。実際の「契約保護インテント」アスペクトは、「preContractCall」と「postContractCall」の結合ポイントにデプロイして、再エントリ攻撃を防ぐことができます。preContractCall: クロスコントラクト呼び出しの実行前にトリガーされます。postContractCall: クロスコントラクト呼び出しの実行後にトリガーされます。再入保護の目的は、通話が完了するまで契約の再入を防止することです。 Aspect を使用すると、トランザクション ライフサイクルのポイントカットに特定のロジックを追加することでこれを実現できます。「preContractCall」ポイントカットでは、Aspect はコントラクト コール スタックを監視します。呼び出しスタックに重複した呼び出しがある場合 (ロックされた呼び出しでの予期しない再入を意味します)、アスペクトは呼び出しをロールバックします。# Curve コントラクトを展開し、再突入攻撃を防止する私たちは、このプロセスをよりわかりやすい方法で再現するために、Curve のモック コントラクトを作成し、リエントラント攻撃を偽造しました。契約コードは以下のとおりです。上記のコントラクトの add\_liquidity と Remove\_liquidity の両方が同じ再エントリ ロック ロックによって保護されていることがわかります。これは、再エントリ保護が正常に機能する場合、保護された関数を変更することによって再エントリすることはできないことを意味します。ロック (たとえば、remove \_liquidity では add\_liquidity を呼び出します)。上記のコントラクトを vyper コンパイラ 0.2.15、0.2.16、または 0.3.0 でコンパイルします (これらのバージョンには再入保護に関する既知の問題があります)。次に、上記の被害者コントラクトをデプロイし、次のコントラクトで攻撃します。実際の攻撃をシミュレートするために、このコントラクトの攻撃メソッドは、フォールバック関数を通じて、remove\_liquidity メソッドから add\_liquidity に再入しようとします。実際に再入が発生した場合は、RemoveLiquidity イベントの前に AddLiquidity イベントが記録されることが受信確認で確認できます。次に、Aspect を使用して、攻撃を受けているコントラクトを保護しましょう。次の操作を行う前に、次の手順を完了してください。1. アスペクトのデプロイ2. 被害者契約をアスペクトと結び付けるAspect の操作に慣れていない場合は、まず開発者ガイドを確認してください。上記を行った後、攻撃メソッドを再度呼び出して、操作が成功するかどうかを確認してみましょう。動画 (記事の最後にある元のリンクを表示できます) から、リエントラント トランザクションが元に戻されたことがわかります。これは、アスペクトが被害者のコントラクトをリエントリー攻撃から正常に保護していることを意味します。＃ 結論はCurve に対する最近の攻撃は、どのプロトコルも 100% 完全に安全ではないことを改めて証明しました。プロトコルのソース レベルおよびコンパイル レベルでのセキュリティに焦点を当てるだけでは十分ではありません。ソース コードに問題がないように見えても、コンパイラの問題により脆弱性が予期せず現れる可能性があります。DeFi のセキュリティを強化するには、実行時の保護が重要になります。 「ブラック ボックス」方式でプロトコルを保護し、プロトコルの実行が意図した設計と一貫していることを保証することで、実行時の再侵入攻撃を効果的に防ぐことができます。私たちは Curve コントラクトをフォークし、最近のリエントランシー攻撃を完全にシミュレートし、プロセス全体をよりわかりやすい方法で再現しました。オンチェーンのランタイム保護への新しいアプローチとしてアスペクト プログラミングを使用し、アスペクトで被害者のコントラクトを保護する方法を段階的に示します。私たちの目標は、Curve のような DeFi プロトコルが被害を受ける可能性のある再入攻撃を根絶し、それによって DeFi 空間全体のセキュリティを強化することです。アスペクト プログラミングを使用すると、開発者はセキュリティ分野でオンチェーン ランタイム保護を実現できるだけでなく、インテント、JIT、オンチェーン オートメーションなどの前例のない革新的なユース ケースも可能になります。さらに、Cosmos SDK に基づくこの一般的なフレームワークは、Artela ブロックチェーンをサポートするだけでなく、他のブロックチェーンもサポートして、独自の実行レイヤーに基づいてネイティブ拡張機能を構築します。
Runtime Protection は DeFi チェーン上のリスク管理保護を実現します
著者: Artela 中国語ブログ、媒体# 要約
再入攻撃は依然として課題であり、既存の防御方法は主にプロトコルのソース コード レベルに焦点を当てており、コントラクトが実行状態に入る前にのみ有効になります。
「実行時保護」は DeFi セキュリティの重要な補足であり、「実行結果を保護」し、プロトコルの実行が期待される設計と一致していることを保証することを目的としています。
スマート コントラクトは実行時状態の完全なコンテキスト情報にアクセスできないため、EVM の設計は「実行時保護」をサポートしていません。
Artela は EVM+Extension 実行層パラダイムを検討し、実行層を強化して再突入攻撃を排除します
Artela は、アスペクト プログラミングを通じてオンチェーンの「ランタイム保護」拡張機能を実装します
Aspect を介して Curve コントラクトに対する再入攻撃を防ぐ方法を段階的に示します。
既存のリスク管理にもかかわらず、リエントランシー攻撃が依然として課題である理由
再入攻撃はよく知られた問題であり、多くのリスク管理が導入されていますが、このような攻撃に関連するセキュリティ インシデントは過去 2 年間にわたって発生し続けています。
Curve Finance 攻撃 (2023 年 7 月) — Curve は、契約プログラミング言語 Vyper のコンパイルの欠陥により、6,000 万ドルのリエントランシー攻撃を受けました。
オリジンプロトコル攻撃 (2022 年 11 月) — 700 万ドルのステーブルコイン プロジェクト オリジン ダラー (OUSD) がリエントランシー攻撃を受けました。
サイレン プロトコル攻撃 (2021 年 9 月) — 350 万ドル、AMM プールが再入攻撃を受ける。
Cream Finance 攻撃 (2021 年 8 月) - 1,880 万ドル、攻撃者は二次借入の再入可能脆弱性を悪用しました。
現在、リエントランシー攻撃の防止はスマートコントラクトのソースコードレベルに重点が置かれており、OpenZeppelinのReentrancyGuardの統合や、事前定義されたセキュリティリスクを回避するためのコントラクトロジックコードのセキュリティ監査の実施などが対策として挙げられている。
「ホワイト ボックス」ソリューションとして知られるこのアプローチは、ソース コード レベルで脆弱性を回避し、論理エラーを最小限に抑えることを目的としています。しかし、その主な課題は、未知の隠れた危険に対して防御できないことです。
コントラクトをソースコードから実際のランタイムに「変換」するのは、困難なプロセスです。各ステップは開発者にとって予期せぬ問題を引き起こす可能性があり、契約のソース コード自体がすべての潜在的な状況を完全にカバーしていない可能性があります。 Curve の場合、プロトコルのソース コードが正しい場合でも、コンパイラの問題により、最終的な実行とプロトコルの意図した設計との間に不一致が依然として存在する可能性があります。
ソース コードおよびコンパイル レベルでのプロトコルのセキュリティに依存するだけでは十分ではありません。ソース コードに問題がないように見えても、コンパイラの問題により脆弱性が予期せず現れる可能性があります。
ランタイム保護が必要です
プロトコルのソース コード レベルに集中し、実行前に有効になる既存のリスク管理対策とは異なり、ランタイム保護では、プロトコル開発者がランタイムの予期せぬ状況に対処するためのランタイム保護ルールと操作を作成する必要があります。これにより、リアルタイムの評価と実行時の実行結果への応答が容易になります。
ランタイム保護は、DeFi セキュリティを強化する上で重要であり、既存のセキュリティ対策への重要な追加です。 「ブラック ボックス」方式でプロトコルを保護することで、コントラクト コードの実行を直接妨げることなく、最終的な動作結果がプロトコルの意図した設計と一致することを保証し、セキュリティを強化します。
ランタイム保護の実装における課題
残念ながら、スマート コントラクトは完全なランタイム コンテキストにアクセスできないため、EVM 設計はオンチェーンでのランタイム保護をサポートしていません。
この課題を克服するにはどうすればよいでしょうか?次の前提条件が必要であると考えられます。
トランザクション コンテキスト全体を含む、スマート コントラクト全体のすべての情報へのアクセスを提供する専用モジュール。
必要な承認はスマート コントラクトから取得され、必要に応じてトランザクションを元に戻す権利がモジュールに与えられます。
スマート コントラクトの実行後、状態がコミットされる前にモジュールの機能が有効になるようにします。
EVM は現在、上記の課題に対処する際に限界に直面しており、さらなる革新に対応することができません。モジュラー ブロックチェーンのパラダイムの下では、実行層は EVM を超えるブレークスルーを模索する必要があります。
Artela のアイデアは EVM + ネイティブ拡張であり、EVM の WASM ネイティブ拡張レイヤーを構築することで EVM を超えたものを実現します。
アスペクトプログラミングの概要
私たちは、ブロックチェーン上のネイティブ スケーリングをサポートする Artela ブロックチェーン用のプログラミング フレームワークである Aspect Programming を開始しました。
Aspect は、プログラム可能なネイティブ拡張モジュールであり、スマート コントラクトのモジュラー補足として、実行時にカスタム関数をブロックチェーンに動的に統合し、チェーン上の機能を強化するために使用されます。
Aspect の特徴は、ブロックチェーンベースレイヤーのシステムレベル API にアクセスし、トランザクションライフサイクルの各結合ポイントで拡張ロジックを追加できることです。スマート コントラクトは、指定されたアスペクトをバインドして拡張機能をトリガーできます。トランザクションがスマート コントラクトを呼び出すと、トランザクションはコントラクトに関連付けられたアスペクトによっても処理されます。
アスペクトプログラミングがランタイム保護を実装する方法
アスペクトは各関数呼び出しの実行状態を記録し、コールバック関数実行中の再入を防ぐことができます。コールバック関数の実行中に再入可能呼び出しが発生すると、Aspect はトランザクションを検出して即座にロールバックし、攻撃者による再入可能性の脆弱性の悪用を防ぎます。このアプローチにより、Aspect は再入攻撃を効果的に排除し、スマート コントラクトのセキュリティと安定性を確保します。
アスペクトは、ランタイム保護のための主要なプロパティを実装します。
スマート コントラクトの実行後、状態の送信前にトリガー可能: アスペクト モジュールは、スマート コントラクトの実行後、状態の送信前にアクティブ化するように設定できます。
完全なトランザクション コンテキスト アクセス: アスペクトは、トランザクション情報全体 (メソッド、パラメーターなど)、コール スタック (実行中のすべての内部コントラクト呼び出し)、状態コンテキストの変更、およびトランザクションによってトリガーされるすべてのイベントを含む、完全なトランザクション コンテキストにアクセスできます。
システムコール機能: アスペクトは、必要に応じてシステムコールを実行し、トランザクションリトレースメントを開始できます。
スマート コントラクトによるバインドと承認: スマート コントラクトをアスペクトにバインドし、トランザクション処理に参加するためのアクセス許可をアスペクトに付与できます。
再入保護のためのアスペクトを実装する
この章では、Aspect のランタイム保護をチェーンに実装する方法について説明します。
実際の「契約保護インテント」アスペクトは、「preContractCall」と「postContractCall」の結合ポイントにデプロイして、再エントリ攻撃を防ぐことができます。
preContractCall: クロスコントラクト呼び出しの実行前にトリガーされます。
postContractCall: クロスコントラクト呼び出しの実行後にトリガーされます。
再入保護の目的は、通話が完了するまで契約の再入を防止することです。 Aspect を使用すると、トランザクション ライフサイクルのポイントカットに特定のロジックを追加することでこれを実現できます。
「preContractCall」ポイントカットでは、Aspect はコントラクト コール スタックを監視します。呼び出しスタックに重複した呼び出しがある場合 (ロックされた呼び出しでの予期しない再入を意味します)、アスペクトは呼び出しをロールバックします。
Curve コントラクトを展開し、再突入攻撃を防止する
私たちは、このプロセスをよりわかりやすい方法で再現するために、Curve のモック コントラクトを作成し、リエントラント攻撃を偽造しました。契約コードは以下のとおりです。
上記のコントラクトの add_liquidity と Remove_liquidity の両方が同じ再エントリ ロック ロックによって保護されていることがわかります。これは、再エントリ保護が正常に機能する場合、保護された関数を変更することによって再エントリすることはできないことを意味します。ロック (たとえば、remove _liquidity では add_liquidity を呼び出します)。
上記のコントラクトを vyper コンパイラ 0.2.15、0.2.16、または 0.3.0 でコンパイルします (これらのバージョンには再入保護に関する既知の問題があります)。
次に、上記の被害者コントラクトをデプロイし、次のコントラクトで攻撃します。
実際の攻撃をシミュレートするために、このコントラクトの攻撃メソッドは、フォールバック関数を通じて、remove_liquidity メソッドから add_liquidity に再入しようとします。実際に再入が発生した場合は、RemoveLiquidity イベントの前に AddLiquidity イベントが記録されることが受信確認で確認できます。
次に、Aspect を使用して、攻撃を受けているコントラクトを保護しましょう。次の操作を行う前に、次の手順を完了してください。
アスペクトのデプロイ
被害者契約をアスペクトと結び付ける
Aspect の操作に慣れていない場合は、まず開発者ガイドを確認してください。
上記を行った後、攻撃メソッドを再度呼び出して、操作が成功するかどうかを確認してみましょう。
動画 (記事の最後にある元のリンクを表示できます) から、リエントラント トランザクションが元に戻されたことがわかります。これは、アスペクトが被害者のコントラクトをリエントリー攻撃から正常に保護していることを意味します。
＃ 結論は
Curve に対する最近の攻撃は、どのプロトコルも 100% 完全に安全ではないことを改めて証明しました。プロトコルのソース レベルおよびコンパイル レベルでのセキュリティに焦点を当てるだけでは十分ではありません。ソース コードに問題がないように見えても、コンパイラの問題により脆弱性が予期せず現れる可能性があります。
DeFi のセキュリティを強化するには、実行時の保護が重要になります。 「ブラック ボックス」方式でプロトコルを保護し、プロトコルの実行が意図した設計と一貫していることを保証することで、実行時の再侵入攻撃を効果的に防ぐことができます。
私たちは Curve コントラクトをフォークし、最近のリエントランシー攻撃を完全にシミュレートし、プロセス全体をよりわかりやすい方法で再現しました。オンチェーンのランタイム保護への新しいアプローチとしてアスペクト プログラミングを使用し、アスペクトで被害者のコントラクトを保護する方法を段階的に示します。私たちの目標は、Curve のような DeFi プロトコルが被害を受ける可能性のある再入攻撃を根絶し、それによって DeFi 空間全体のセキュリティを強化することです。
アスペクト プログラミングを使用すると、開発者はセキュリティ分野でオンチェーン ランタイム保護を実現できるだけでなく、インテント、JIT、オンチェーン オートメーションなどの前例のない革新的なユース ケースも可能になります。さらに、Cosmos SDK に基づくこの一般的なフレームワークは、Artela ブロックチェーンをサポートするだけでなく、他のブロックチェーンもサポートして、独自の実行レイヤーに基づいてネイティブ拡張機能を構築します。