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

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

目次

  1. はじめに
  2. スマートコントラクト監査の現在地
    　1. ベスト・プラクティスの誕生
    　2. コア部分のライブラリ化（OpenZeppelin：スマコン開発のオープンソースライブラリ）
    　3. バグ・バウンティプログラムが充実化（Immunefi：バグ・バウンティプラットフォーム）
    　4. コード監査会社の台頭
    　5. 高度なテスト手法を活用した自動化ツールの登場
  3. おわりに
    参考文献

1. はじめに

DeFiの成長とともに、スマートコントラクト監査の重要性はますます高まっています。技術の進化に伴い、監査手法やベスト・プラクティスも洗練されてきました。しかし、依然としてハッキングやバグのリスクが存在する中で、どのようにして安全性を確保していくのかが問われています。具体的には、コア部分のライブラリ化やバグ・バウンティプログラムの充実、そして高度な自動化ツールの導入などが進んでいます。本レポートでは、現在のスマートコントラクト監査の状況を探り、業界全体の課題と進展を明らかにします。

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

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

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

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

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

2.(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である

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

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

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

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

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

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

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

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

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

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

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

3. おわりに

本レポートでは、スマートコントラクト監査の現状を探り、業界におけるベスト・プラクティスや新たな手法について分析しました。特に、バグ・バウンティプログラムや自動化ツールの導入が、監査の効率性と精度を高めていることが明らかになりました。とはいえ、スマートコントラクトは依然として攻撃者に狙われやすく、その安全性は常に問われています。今後もリスクを理解し、慎重な運用を心掛けることが重要です。

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

参考文献

[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].