スマートコントラクト監査：監査の基礎知識

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

目次

  1. はじめに
  2. 前提
    　1. 分散型金融（DeFi）は自己責任
    　2. DeFi業界の発展にはスマートコントラクト監査の精度向上が必須
    　3. スマートコントラクト監査における監査観点
    　4. スマートコントラクトのリスク精査におけるチェック項目例
  3. おわりに
    参考文献

1. はじめに

2017年から2018年にかけて、ブロックチェーン技術を基盤にした分散型金融（DeFi）が急速に進化しました。特に2020年のDeFi Summer以降、多くの革新的なプロダクトが市場に登場し、投資家に高いリターンを提供する一方で、スマートコントラクトのセキュリティリスクも増大しています。実際、最近では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. おわりに

本レポートでは、DeFiの発展とスマートコントラクト監査の必要性について考察し、特に自己責任の重要性や監査の観点を整理しました。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/