💻 computer science

Assessing Vulnerability in Smart Contracts: The Role of Code Complexity Metrics in Security Analysis

本研究は、個々のソフトウェア複雑度指標はSolidityスマートコントラクトにおける特定の脆弱性と低い相関しか示さない一方で、それらを集合的に分析することは安全なコードと脆弱なコードを効果的に判別できることを実証しており、脆弱なコントラクトは一貫して高い平均複雑度スコアを示す。

原著者： Masoud Jamshidiyan Tehrani

公開日 2026-01-26

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Masoud Jamshidiyan Tehrani

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

スマートコントラクトは、ブロックチェーン上に構築された、自動で実行される「自動販売機」のようなものだと想像してください。お金を入れてボタンを押せば、自動的にスナックが出てきます。一度動かし始めたら、後から機械の内部ギア（歯車）を変更することはできません。これは「不変（イミュータブル）」だからです。もしギアに欠陥があれば、ハッカーはその中にあるお金をすべて盗むことができてしまい、新しい機械を作り直さない限り、修正する方法はありません。

この論文は、機械がデプロイ（実戦投入）される前に、それらの「壊れたギア」を見つけ出す試みについてのものです。研究者たちは、シンプルな問いを投げかけました。「自動販売機の設計図がいかに複雑であるかを見るだけで、その機械が壊れやすいかどうかを判断できるだろうか？」

以下に、日常的な比喩を用いた彼らの調査結果の解説をまとめます。

1. 核となる考え方：複雑さは「レッドフラッグ（警告信号）」である

研究者たちは、コードがいかに「乱雑」または「複雑」かを測定するための21種類の異なる指標を調査しました。これらの指標は、以下のようなものを測定するものだと考えてください。

SLOC（ソース行数）： 説明書のページ数はどのくらいか？
ネスト（入れ子構造）： 「もし〜ならば、次はこの動作をする」という箱の中に、さらに箱がいくつ重なっているか？（ロシアのマトリョーシカのようなもの）。
結合度（カップリング）： その機械が動作するために、他のいくつの機械と通信する必要があるか？

調査結果： 彼らは、**「乱雑な設計図は、壊れた機械を意味する」**ということを発見しました。
ハッキングされた（脆弱性があった）コントラクトを調べたところ、それらの設計図は、安全なコントラクトの設計図よりも、ほぼ例外なく複雑で、長く、そして絡み合っていました。

2. 「水晶玉」の問題（個別の指標）

研究者たちは、単一の特定の測定値によってハックを予測できるかどうかを検証しました。

比喩： 車のカップホルダーの数だけを見て、その車が衝突事故を起こすかどうかを予想しようとするようなものです。
結果： それはあまりうまくいきませんでした。単一の指標（例えば、単に行数を数えるだけなど）では、完璧な「水晶玉」にはなり得ませんでした。行数だけを見たとしても、「これは絶対にハッキングされる」と確実に断言することはできませんでした。関連性はありましたが、それは弱いものでした。

3. 「チームプレー」による成功（組み合わせた指標）

しかし、すべての測定値をまとめて見たとき、景色は非常に明確になりました。

比喩： スープが塩辛いかどうかを判断するのに、塩の瓶を味わうだけでは不十分ですが、スープ全体を味わえば、それがどれほど塩辛いかを正確に知ることができます。
結果： 単一の指標では不十分でしたが、指標を組み合わせることで、安全なコントラクトと危険なコントラクトを区別することが非常にうまくできました。「脆弱な」コントラクトは、安全なものと比較して、あらゆる面において一貫して高いスコア（より多くの行数、深いネスト、より多くの接続）を示していました。

4. 驚くべき例外

「複雑さ＝危険」というルールに反するものが3つありました。

コメント（CLOC）： 安全なコントラクトには、より多くのコメント（プログラマーがコードを説明するために書いたメモ）がありました。脆弱なコントラクトには、コメントが少なかったのです。
- 教訓： 設計図にメモを書き込むことは、機械を安全に保つのに役立つようです。
子孫（NOD）： 安全なコントラクトには、より多くの「子孫（派生した、あるいは子供となるコントラクト）」が存在しました。脆弱なものは、それらが少なかったです。
パラメータ： 脆弱なコントラクトは、平均して入力（パラメータ）の数がわずかに少ない傾向にありました。

5. 開発者にとっての意味

この論文は、複雑さはハックの「原因（ウイルスのようなもの）」ではないものの、非常に大きな声で鳴り響く**「警告サイン」**であることを結論付けています。

比例： もし、絡まった電線、露出したパイプ、そして混乱した間取りを持つ家を見かけたら、それが必ずしも火事になるとは断定できませんが、整然とした配線を持つ家よりも火事になる可能性が高いことは分かります。
アドバイス： 開発者は、コードをシンプルに保つよう努めるべきです。もしコントラクトが複雑になりすぎていると感じたら、それは立ち止まってセキュリティの穴をチェックすべき合図です。また、より多くのコメントを書いてください。データは、ドキュメント化（文書化）されたコードの方が安全であることを示唆しています。

まとめ

この論文は、スマートコントラクトにおいて**「複雑さはリスクの強力な指標である」**ことを証明しています。ハックを予測するために一つの数字だけに頼ることはできませんが、コード全体の「乱雑さ」を見ることで、複雑さを完全に無視する場合よりも、はるかに精度よく危険なコントラクトを見つけ出すことができます。これは、監査人や開発者が、どのコントラクトに最も注意深い検査が必要かを優先順位付けするためのツールとなります。

技術要約：コード複雑性指標によるスマートコントラクトの脆弱性評価

問題提起
Ethereumのようなブロックチェーンプラットフォーム上にデプロイされるスマートコントラクトは、不変（イミュータブル）であり、しばしば高価値の金融取引を扱うため、セキュリティの保証が極めて重要である。基盤となるブロックチェーン自体は安全であるが、スマートコントラクト自体は、プログラマーの過失やコーディングミスに起因する脆弱性を抱える可能性がある。従来の静的解析ツールは、特定の脆弱性のタイプを検出するためにパターンマッチングに依存することが多い。しかし、コードの構造的特性、具体的にはソフトウェアの複雑性が、脆弱な領域を特定するための補完的な指標として機能し得るかという理解が必要である。著者らは、確立されたベストプラクティスから逸脱したコード（すなわち、より高い複雑性を持つコード）は、セキュリティ欠陥にさらされる可能性が高まると仮定しているが、複雑性指標とSolidityスマートコントラクトの脆弱性との間の具体的な関係については、実証的な検証を要する未解決の問題として残されている。

手法
本研究では、21種類の異なるソフトウェア複雑性指標と、Solidityスマートコントラクトにおける脆弱性の存在との関係を分析するために、定量的かつ経験的なアプローチを採用している。

データセット: 本研究では、Etherscanからクロールされた16,239個の個別のコントラクト（脆弱なもの258個、中立的なもの15,981個）からなるLiuらによるデータセットを利用している。脆弱なコントラクトは、Integer Underflow/Overflow、Dangerous Ether Strict Equality、Reentrancy、Timestamp Dependency、Block Number Dependency、Dangerous Delegatecall、Ether Frozen、Unchecked External Callの8つの特定の脆弱性タイプに基づいてラベル付けされている。
指標の抽出: 静的解析ツールであるSolmetを使用して、各コントラクトに対して21の複雑性指標を抽出した。これには、サイズ指標（SLOC、LLOC、CLOC）、構造的指標（NF、WMC、NOS）、ネスト指標（NL、NLE）、継承指標（DIT、NOA、NOD）、結合指標（CBO、NOI、NA）、およびこれらの指標の平均値が含まれる。
統計分析:
- 相関分析: スピアマンの順位相関係数を用いて、指標間の単調な関係を評価し、指標間の冗長性を特定した。
- グループ比較: マン・ホイットニーのU検定を用いて、指標の値の分布が脆弱なコントラクトと中立的なコントラクトの間で有意に異なるかどうかを判定した。
- 効果量: グループ間の差異の大きさを定量化するために、クリフのデルタ（ $\delta$ ）を算出した。
- 信頼区間: 脆弱なグループと中立的なグループの間での、指標の中心的傾向（平均）を比較するために使用した。

主な貢献
本論文は、複雑性指標の有用性を評価するために、4つの具体的な研究課題（RQ）に取り組んでいる。

RQ1 (指標の相互依存性): 本研究は、特定の指標間に顕著な冗長性があることを特定した。例えば、SLOCはNOI、NOS、WMC、NFと強く相関している。同様に、ネスト指標（NL、NLE）とその平均値は高い相関を示しており、21の指標すべてが脆弱性検出のために独自の情報を備えているわけではないことを示唆している。
RQ2 (指標と脆弱性の相関): 分析の結果、21の指標すべてが脆弱性の存在と統計的に有意な相関（ $p < 0.05$ ）を示したものの、これらの相関の強さは一般に弱い（係数は主に0.3未満）ことが明らかになった。これは、相関がより強いことが多い従来のプログラミング言語における知見とは対照的である。その結果、単独で強力な予測因子となる指標は存在しない。
RQ3 (識別能力): 個々の相関は弱いものの、マン・ホイットニーのU検定により、すべての指標が脆弱なコードと中立的なコードを統計的に区別できることが確認された（ $p < 0.05$ ）。ほとんどの指標は大きな効果量（例：SLOC、LLOC、NF、WMC、NL、NOS、CBO、NA、NOI）を示しており、これは両グループ間の指標の分布が実質的に異なっていることを示している。
RQ4 (差異の方向性): 本研究では、大部分の指標において、脆弱なコントラクトは中立的なコントラクトよりも一般に高い平均複雑性スコアを示すことが判明した。しかし、脆弱なコントラクトが低い値を示す顕著な例外が3つある。
- CLOC (コメント行): 中立的なコントラクトの方がコメントが多く、ドキュメント化が脆弱性を軽減する可能性を示唆している。
- NOD (子孫数): 脆弱なコントラクトは子孫数が少ない。
- Avg. NUMPAR (平均パラメータ数): 脆弱なコントラクトは、平均してパラメータ数が少ない。

結果と意義
本論文は、複雑性指標は脆弱性の直接的な原因ではなく、**指標（インジケーター）**であると結論付けている。本研究の主な意義は以下の点にある。

集合的な有用性: 個々の指標の予測力は弱いものの、本研究は、複雑性指標を集合的に分析した場合、強力な識別能力を持つことを実証している。これは、自動脆弱性検出ツールにおける補完的な特徴量としての活用を支持するものである。
冗長性の管理: 高い相関を持つ指標（例：SLOC vs WMC vs NF）の特定は、脆弱性予測モデルを非冗長な特徴量のサブセットを選択することで最適化でき、精度を損なうことなく効率を向上させられることを示唆している。
文脈的なニュアメント: 本研究の結果は、従来のソフトウェアと比較したSolidityのユニークな特性を浮き彫りにしている。例えば、コメント密度（CLOC）との逆の関係は、スマートコントラクトの文脈において、ドキュメントの欠如が特定のリスクマーカーであることを示唆している。
実用的な応用: 著者らは、これらの指標を既存の静的解析ツールに統合し、監査作業の優先順位付けを行うことを提案している。複雑性のスコアが高いコントラクトは、より深い手動レビューの対象としてフラグを立てることができ、開発者はネストの最小化、結合の低減、および適切なドキュメント化といったベストプラクティスの遵守にこれらの知見を活用できる。

著者らは、観察された関係は統計的な関連性に過ぎないことを強調し、控えめな立場を維持している。彼らは、高い複雑性がしばしばより大きな「問題領域」（例：複雑なDeFiプロトコルは自然とより多くのコードを必要とする）と相関していることを認めており、これが複雑性指標自体が唯一の因果メカニズムであることよりも、脆弱性リスクの増加を駆動する根本的な要因である可能性があるとしている。今後の課題として、ドメイン固有の層別化や、認知複雑性指標の探索が示唆されている。