PenligentAIがブロックチェーンのスマートコントラクトの脆弱性を自動検出

AIがTOCTOUの二重支出リスクを発見

Time-of-Check-Time-of-Useレースコンディションは、システムの意思決定ポイントとその意思決定が実行される瞬間の間のギャップを埋めるタイミングバグの一種である。ブロックチェーンの決済フローでは、このようなギャップが、1回の有効な購入と二重支払いの分かれ目になることがある。コードが残高を読み取り、後で購入を適用する場合、ほぼ同時にトランザクションを送信したり、並び替えを悪用したりできる攻撃者は、状態の更新が1回しか行われない間に、チェックを2回成功させることができる。これがダブルスペンドTOCTOUの核心である。

ペンリジェントの仕組み

これらの問題を発見するPenligentのアプローチは当て推量ではない。チェックしてから実行する」イディオム（バランスまたはエンタイトルメントが読み込まれ、その後の書き込みでエンタイトルメントカウンタが更新されるコード行）にフラグを立てる静的解析パターンから始めます。これらのフラグが立てられた箇所は、コードパスのコールグラフ、それを呼び出すネットワークエンドポイント、環境仮定（「シングルスレッド更新を仮定する」「次のステップの前にブロック確認を仮定する」など）といったコンテキストを受け取る。Penligentはこのコンテキストをもとに、ステージングエンドポイントに対する非破壊プローブ、利用可能な場合はトランザクショントレースとの相関関係、ほぼ同時のサブミッションでの動作をサンプリングするターゲット並行性テストなど、制御された検証をトリガーします。

具体的には、脆弱なフローは本番環境では次のようになります。 balance[shop_address] == 1_000_000 そしてバイヤーのダイアモンドカウントをインクリメントする。攻撃者は1,000,000 DDCoinのトランザクションを2回実行する。どちらのトランザクションもコミットされる前にチェックが実行されるため、両方のチェックが通過し、ユーザーは2つのダイヤモンドを獲得する一方で、アセットを1ユニットしか消費しない。Penligentは、リクエスト/レスポンスのトレース、トランザクションID、ブロックタイムスタンプ、および観測可能なレースアーティファクトを収集することで証拠を収集し、それらをチェックを実行する静的コードの場所にバインドする。

TOCOTOUの修理方法

ブロックチェーンの文脈でTOCTOUを修正することは、通常、残高チェックと状態変更をアトミックにすることを意味する。伝統的なバックエンドでは、強力な分離レベルとミューテックスを持つデータベース・トランザクションか、リトライを伴う楽観的並行処理スキームを意味する。スマート・コントラクトでは、状態遷移が単一のトランザクションで実行されるようにコントラクトを設計すること、あるいはnoncesやアカウントごとの明示的なシーケンス番号のようなメカニズムを使用して、操作の再生や重複を防ぐことを意味します。以下の安全な擬似コードは、攻撃可能性よりもむしろ原子性と正しさを重視した防御パターンを示している：

# defensive pseudocode: serializable トランザクション内でのアトミック更新
db.transaction(isolation="serializable")：
    if balance[shop_address] >= PRICE：
        balance[shop_address] -= PRICE
        session["your_diamonds"] += 1
    else：
        raise InsufficientBalanceError()

運用面では、トランザクションの送信にnoncesまたは単調カウンターを要求する、APIゲートウェイでの操作の順序を厳密に維持する、同時送信パターンを再構築できるように完全なトレーサビリティを実現する、といった追加的な対策が有効である。レート制限とバッチ処理は、同時実行が悪用される現実的なウィンドウを縮小することもできる。

検出の観点から見ると、Penligentの真価はシグナルの融合にある。静的な指標だけでは多くの偽陽性が発生し、実行時の遠隔測定だけではソースコードとの直接的なつながりがありません。Penligentは、静的コードから発見された情報を、どのエンドポイントがコールされたのか、どのトランザクションIDがオンチェーンで観測されたのか、どの一連のイベントが状態の分岐につながったのか、といった実際の実行エビデンスに結びつけます。その結果、開発者は修正すべき正確なソース行を取得し、運用チームはトランザクションのトレースを取得して取り消しや緩和策を検証し、セキュリティチームは優先順位を付けた改善計画を得ることができます。

このモデルを採用するチームにとって、ワークフローはより速く、より説明責任を果たすことができる。何ヶ月もかけて手作業でトリアージする代わりに、再現可能な証拠と明確な修正パスを得ることができる。プロダクトオーナーは原子性の制約を受け入れなければならず、オペレーションはデプロイメントにおけるトランザクションの分離を保証しなければならず、セキュリティはターゲットを絞った再実行で緩和策を検証しなければならない。

Penligentプロンプトの提案（自然言語）-社内用

Penligentに、あるサービスにおけるTOCTOUスタイルの二重支出のリスクをスキャンさせたい場合、簡潔なプロンプトは次のようになる：

「でペイメントエンドポイントをスキャンする。 https://staging.example.com/create_transaction TOCTOUとダブルスペンドのレースコンディションのため。残高やエンタイトルメントを読み込んでから状態を書き込むコードパスに焦点を当てる。非破壊的な検証サンプルを生成し、並行トランザクションのトレースを関連付け、ソースの場所と優先順位を付けた修正と一緒にエビデンスバンドルを作成する。"

このプロンプトは、Penligentに、静的パターンマッチングと、安全な実行時検証および証拠相関を組み合わせるように指示する。