スマートコントラクト監査の現在地

Ledefiリサーチ事業部
DeFi（分散型金融）
TwitterFacebookHatena BookmarkLine

目次

  1. はじめに
  2. 前提
    2.(1) 分散型金融（DeFi）は自己責任
    2.(2) DeFi業界の発展にはスマートコントラクト監査の精度向上が必須
    2.(3) スマートコントラクト監査における監査観点
    2.(4) スマートコントラクトのリスク精査におけるチェック項目例
  3. スマートコントラクト監査の現在地
    3.(1) ベスト・プラクティスの誕生
    3.(2) コア部分のライブラリ化（OpenZeppelin：スマコン開発のオープンソースライブラリ）
    3.(3) バグ・バウンティプログラムが充実化（Immunefi：バグ・バウンティプラットフォーム）
    3.(4) コード監査会社の台頭
    3.(5) 高度なテスト手法を活用した自動化ツールの登場
  4. おわりに
    参考文献

1. はじめに

2017年から2018年にかけてブロックチェーンやスマートコントラクト技術を用いた分散型金融（以下、DeFi）が生まれて以降、2020年のDeFi Summer等を経て多くのDeFiプロダクトが市場に出てきている。それらのプロダクトの中には上手く運用戦略を立てることで高いリターンを獲得できるプロダクトがある一方で、スマートコントラクトへのハッキング等による損失リスクを孕んでいるプロダクトも多く存在する。実際に、今年の7月末にはCurveでの大規模なハッキング事件も起きており、DeFiプロダクトに対するスマートコントラクト監査の必要性が多方面で叫ばれている。そこで、本レポートではDeFiにおけるスマートコントラクト精査における現状を纏めた。

2. 前提

2.(1) 分散型金融（DeFi）は自己責任

DeFiにおけるスマートコントラクト監査の現在地に話を進める前に、本章では前提となる背景知識について解説する。そもそも、DeFiプロダクトのバグによってハッキングが多発するからといって、なぜユーザーがプロダクトのリスクを精査する必要が出てきたのだろうか。

これは、DeFiが分散型の構造を目指していることと深く関係がある。DeFiプロダクトの挙動は全てコードに定義されており、コードが公開されていて情報の非対称がないため、利用の是非は顧客自身に任せるという考え方が通ってしまうのである。例えば、Uniswapなどのプロダクトにバグがあり、利用者の資産が毀損した場合であっても、プロダクト側は責任を取らない。そのため、各DeFiプロダクトのリスクは、利用者自身で精査しなければならない。

精査項目には、ビジネスモデル、ガバナンスなど様々[1]だが、「Code is Law」のブロックチェーン領域においては、特にシステムリスク（以下、スマートコントラクトリスク）精査の重要度が高い。ブロックチェーンのスマートコントラクトのコードは、公開されており誰でもコードを監査でき、高い透明性を提供する。

自然言語で制定される既存の法的な契約では、柔軟性があるため、その解釈に大きな曖昧さを残す。例えば、裁判所の判断で通常よりも刑を軽くする情状酌量などの裁量による柔軟性などがある。一方でスマートコントラクトではルールがコードとして記述され、これらのコードではあらゆる条件分岐が事前に網羅的に明確に定義されている必要がある。そして、これらの作業は大変なコストを要する。また、利用者はコードで規定されたルールを理解し正しさを検証する必要があるが、多くの利用者にとってこれらの精査は既存のビジネス上の法的な契約書の内容確認以上に難しい。

2.(2) DeFi業界の発展にはスマートコントラクト監査の精度向上が必須

前項の最後では、多くの人がDeFiプロダクトのスマートコントラクトリスクを精査することが難しいという事を述べた。では、現状、優秀なコード監査会社がスマートコントラクトを監査すればスマートコントラクトリスクが完璧に防げるかというと、そうとも言い切れない。実際に、図1のようにDeFiやブリッジ でハッキングされた被害総額は約1兆円にのぼっており、2023年以降にもまだ相当額のハッキングが起きてしまっている。

一方で、DeFiの仕組み自体は既存金融における取引コストを削減し得るのではないかという期待もあり、各国の金融機関が挙ってDeFiの仕組みを活用したPoCを行っている[2]。今後、こういったユースケースを実装していく際には、スマートコントラクト監査の精度向上がますます必要になってくるという事である。

図1.ハッキングされた合計額 出所：DeFiLlama

2.(3) スマートコントラクト監査における監査観点

では、DeFiのスマートコントラクト監査ではどういった観点で見ているのだろうか。様々な観点で分析する必要があるが、以下で、大きく3つに分けてそれぞれの精査項目を紹介する。

  1. 内在的リスク精査：スマートコントラクト特有のプログラミング言語仕様やコンパイラに潜む脆弱性に加え、スマートコントラクトならではであるロック処理やアクセス制御、フォールバック、など特殊条件における意図しない動作に対応する必要がある。例えば、バッファオーバーフローによるバグなどが挙げられる。
  2. 外在的リスク精査：DeFiプロダクトは、複数コントラクトで1つのサービスとして提供されることが多い。またこの時、外部コントラクトも自身のサービスの一部として再利用できる。複数コントラクトが相互依存しているため、外部サービスの影響を受ける。例えば、オラクル攻撃などが挙げられる。
  3. ドメイン知識を用いたプロダクト精査：DeFiプロダクトは、様々な金融商品を提供している。これらのスマートコントラクトを監査するためには、エンジニアリングの知識に加えて、金融知識を要する。金融プロダクトには、貸付/借入・デリバティブ（オプション・スワップ）などがある。

2.(4) スマートコントラクトのリスク精査におけるチェック項目例

前項でスマートコントラクト監査における精査項目を見てきたが、実際に利用者が確認すべき箇所はどこになるのだろうか。以下にチェック項目の一例と、その項目をチェックする背景を説明する。

<チェック項目>

  • 監査会社による監査
    • 監査内容は十分になされているか。監査項目は各社により異なるため
    • 監査済コードが正しくデプロイされているか。監査会社による監査済のコードがデプロイされていないケースがあるため
  • バグ・バウンティプログラムの有無とその履歴
    • DeFiプロダクトの運営組織がセキュリティ担保に投資している方が、脆弱性が発見される確率は高まるため
  • 過去の脆弱性とその解決状況
    • 過去の脆弱性が未解決なままデプロイされているケースがあるため
  • コードはセキュリティー・ベストプラクティスが適用されているか
    • リエントランシー攻撃／バッファオーバーフロー攻撃への対応が必要であるため
  • コードのセキュリティーテストがどこまでカバーしているか（AuditレポートやGitHubを基に）
    • セキュリティーテストのカバー領域が狭い事があるため
  • プロダクトは仕様通りに挙動するか
    • プロダクトの仕様通りにコードが挙動することを最終確認するため

3. スマートコントラクト監査の現在地

ここまでスマートコントラクト監査に関する前提知識を解説してきたが、本章ではそういったスマートコントラクト監査の現在地を、動向などに触れつつ簡単に解説していく。

3.(1) ベスト・プラクティスの誕生

まず、ここ数年の大きなハッキング事例を元に得た知見が、ベスト・プラクティスとしてまとめられている。脆弱性の紹介から、スマートコントラクトのコードの書き方まで、幅広くベスト・プラクティスがまとめられている。

  1. Ethereum Foundation - SMART CONTRACT SECURITY [3]
  2. Conensys - Ethereum Smart Contract Security Best Practices [4]
  3. SWS - Smart Contract Weakness Classification [5]

3.(2) コア部分のライブラリ化（OpenZeppelin：スマコン開発のオープンソースライブラリ）

次に、オープンソースのライブラリの登場について解説する。言ってしまえば、”よく使われる規格が同じコードは、オープンソースのライブラリ内にある監査済のコードを使いましょう”ということである。

スマートコントラクトの開発において、アカウントやトークンに関する仕様は、Ethereum Request for Comments（以下、ERC）としてEthereum Foundationにより定義されている。有名なものにFTトークンのERC20、NFTトークンのERC721、またSemi FTトークンのERC1155、などがある。これら仕様に従った実装案がOpenZeppelinによりまとめられており、開発者はOpenZeppelinのソースコードを利用することで実装が可能となる[5]。

以下に、OpenZeppelinの特徴をまとめた。

  1. 再利用可能なコード：基本的なスマートコントラクトの機能（トークン管理、アクセス制御、数値計算など）の再利用可能なコードを提供。開発者は独自のコードをゼロから書くのではなく、安全に検証されたコードを利用可能
  2. セキュリティ監査：定期的に監査会社によるコード監査を受けている。開発者はそのコードが既知のセキュリティの脆弱性から保護されていることを保証し利用可能
  3. コミュニティのサポート：活発なコミュニティ。新しいセキュリティの脆弱性の発見やベストプラクティスの共有をサポート。2023年10月5日時点でContributorが402人いる
  4. 継続的なアップデート：スマートコントラクトの技術やセキュリティのリスクは常に進化しており、これらの変化に対応するために、定期的にライブラリを更新。2023年10月5日時点でv4.9.3である

3.(3) バグ・バウンティプログラムが充実化（Immunefi：バグ・バウンティプラットフォーム）

次に、バグ・バウンティプログラムについて解説する。バグ・バウンティとは、コントラクトの脆弱性を発見することで報酬をもらう制度のことである。最近ではテストネットにデプロイしたタイミングで、バグ・バウンティを募集し、一定期間経過後、メインネットにデプロイするのが一般的である。最も有名なものとして、Immunefiというプラットフォームがあり、他にもHackerOne、HackenProofなどがある。

最も人気なバグ・バウンティプラットフォームの1つであるImmunefiでは、ホワイトハッカーやセキュリティアナリストがプロジェクトの脆弱性のレビューや修正を行っている。ホワイトハッカーは自身のプログラミングスキルにあわせたバグ・バウンティプログラムを選択し、コードをレビューし、バグレポートを提出して報酬を獲得する事ができる。プロジェクトにとっては、Immunefi上のホワイトハッカーやセキュリティアナリストの知見を借りてセキュリティを強化する事ができる。纏めると、Immunefiの特徴は以下の3点である。

  1. 脆弱性を早期発見する可能性が高まる：多数のセキュリティ専門家がスマートコントラクトを監視するため、脆弱性は本番リリース直前に発見される可能性が高まる
  2. 各ステークホルダへのインセンティブ提供：セキュリティ専門家だけでなく、ハッカーに対しても、脆弱性を発見・報告することで報酬を得る機会を提供する。この金銭的なインセンティブにより、スマートコントラクトの安全性検証に多くのエンジニアを集めることができる
  3. 専門的なフィードバックが得られる：バウンティプログラムを通じて、プロダクトの開発者はセキュリティ専門家からの詳細なフィードバックを受け取る。このフィードバックは、脆弱性の修正やセキュリティのベストプラクティスの適用に役立つ
図2.バウンティプログラム一覧の一部 出所：Immunefi

3.(4) コード監査会社の台頭

コード監査会社は、スマートコントラクトのコードを詳細に検証し、セキュリティの脆弱性、その他の問題点を特定・報告する専門的なサービスを提供する。監査会社によりカバーされる内容は、各社により様々である。また、各項目の深さも異なる。そのため、監査会社を盲目的に信じるのではなく、監査会社に対する精査が必要となる。

また、参考までに、スマートコントラクトのコード監査のプレーヤーとしては、MixBytes [7]、ChainSecurity [8]、Trail of Bits [9] 、PeckShield [10]、OpenZeppelin [11] 、CertiK [12]、SlowMist [13]、Quantstamp [14]等といった企業があげられる。

3.(5) 高度なテスト手法を活用した自動化ツールの登場

スマートコントラクトに使用できるツールや高度な手法が、提供されはじめている。実際に、従来のソフトウェア工学において、一般的に活用されてきた高度なテスト手法も適用されつつある。

  • 静的解析：静的解析は、プログラムを実際に実行せずに分析する方法である。実際の入力データが存在しない状況でコードを調べ、潜在的なセキュリティ違反、ランタイムエラー、および論理的な矛盾を検出できる。数学的な方法を用いて検証する形式的検証と、シンボル値を入力として使用して検証するシンボリック実行の2つのカテゴリに大別される。
  • 動的解析：動的解析は、実際にプログラムを実行し挙動を分析する方法である。ランタイム中に発生するバグや脆弱性を発見する事ができる。ファジングテストなどの、入力データにランダムな変更を加え、ソフトウェアの挙動を検証するテスト手法が有名である。予期しないバグや脆弱性の発見する事ができる。

ただし、ビジネスロジックを明確に漏れなくコードで正確に表現することは大きな挑戦であることが前提であることを認識する必要がある[15]。また、スマートコントラクトの脆弱性を検証する自動化ツールは、DeFiプロダクトの高レベルな脆弱性を網羅的に発見することはできていないという研究結果もでている[16,17]。特に、Chaliasos [17]らの研究によれば、これらのテストツールで検出される脆弱性は全体の34%に過ぎず、カバーされた脆弱性のカテゴリは25%であった。そのため、半自動化ツールや手動テストは、引き続き重要であると考えられる。

4. おわりに

本レポートではDeFiやブリッジでハッキングされた被害総額を元にスマートコントラクトの現状把握をし、スマートコントラクトを利用したビジネスやツールで留意すべき点を見てきた。スマートコントラクト監査は、既存のプログラミング言語解析の高度なテスト手法が提供されつつあり、ブロックチェーンが期待され、発展すればするほどその安全性が問われてくる。スマートコントラクトは常に攻撃者に晒されているため脆弱性がある場合に不正な操作をされる可能性がある。長所だけでなく短所も把握していくことは今後利用する上で大切になってくるだろう。今後の動向にも要注意である。

そして、レポート末尾とはなるが、本レポートを書くにあたり各種レポート[3]を参考にさせて頂いた。改めて御礼申し上げたい。
 

参考文献

[1] S&P Global. (2022). Exploring Crypto And DeFi Risks In Credit Rating. Retrieved from https://www.spglobal.com/_assets/documents/ratings/research/101563051.pdf
[2] BIS. Project Mariana. Retrieved from https://www.bis.org/about/bisih/topics/cbdc/mariana.htm.
[3] Ethereum.org. Smart contract security. Retrieved from https://ethereum.org/am/developers/docs/smart-contracts/security/
[4] Consensys. Ethereum Smart Contract Best Practices. Retrieved from https://consensys.github.io/smart-contract-best-practices/
[5] Swcregistry. Smart Contract Weakness Classification. Retrieved from https://swcregistry.io/
[6] Openzeppelin. Retrieved from https://github.com/OpenZeppelin/openzeppelin-contracts
[7] MixBytes. Retrieved from https://mixbytes.io/audit
[8] Chainsecurity. Retrieved from https://chainsecurity.com/security-audit/zkbob-smart-contracts/
[9] Trail of bits. Retrieved from https://www.trailofbits.com/
[10] PeckShield. Retrieved from https://peckshield.com/
[11] OpenZeppelin. Retrieved from https://www.openzeppelin.com
[12] Certik. Retrieved from https://www.certik.com/
[13] Slowmist. Retrieved from https://www.slowmist.com/service-smart-contract-security-audit.html
[14] Quantstamp. Retrieved from https://quantstamp.com/
[15] Worldbank. Retrieved from https://documents1.worldbank.org/curated/en/177911513714062215/pdf/122140-WP-PUBLIC-Distributed-Ledger-Technology-and-Blockchain-Fintech-Notes.pdf
[16] Kushwaha, S., Joshi, S., Singh, D., Kaur, M., & Lee, H.-N. (2022). Ethereum Smart Contract Analysis Tools: A Systematic Review. IEEE Access, 1-1. https://doi.org/10.1109/ACCESS.2022.3169902
[17] Chaliasos, S., Charalambous, M. A., Zhou, L., Galanopoulou, R., Gervais, A., Mitropoulos, D., & Livshits, B. (2023). Smart Contract and DeFi Security: Insights from Tool Evaluations and Practitioner Surveys. arXiv:2304.02981 [cs.CR].