スマートコントラクト監査

スマートコントラクトは特殊なソフトウェアです。資金を直接保有し、誰でも調べられる公開の場で動き、一度デプロイされると変更が難しいか、不可能です。見落とされた1行が、攻撃者に1回のトランザクションでプロトコルの資金を抜き取らせることもあります。監査は、ローンチ前の主要な防御策です。攻撃者より先に、専門家がコードを読むのです。

監査人が見る点

• ロジックのエラー：書かれたとおりには動くものの、意図どおりには動かないコード。たとえば、報酬を二重に支払ってしまう計算式など。
• アクセス制御：本来は管理者に限定すべきなのに、誰でも呼び出せてしまう関数。
• リエントランシー：外部呼び出しによって、最初の呼び出しが終わる前に攻撃者が関数に再び入り込めてしまう問題。2016年の The DAO ハッキングの原因となったバグです。
• 価格操作：1回のトランザクション内で動かせる価格を信頼してしまうロジック。多くの場合、脆弱なオラクルを介して起こります。
• 経済設計：すべての行が書かれたとおりに動いていても、資金力のある参加者が悪用できてしまうインセンティブ。

監査人は、手作業のレビューと自動化ツールを組み合わせ、さらに近年では形式検証も取り入れています。形式検証とは、コードが書面の仕様を満たしていることを数学的に証明する手法です。

2つの監査モデル

従来型の監査会社による監査では、少人数のセキュリティエンジニアのチームが決められた期間にわたってコードベースを調べ、報告書を提出します。コンペティション型の監査では、多数の独立したリサーチャーが同時に同じコードをレビューし、見つけた問題に応じて報酬を受け取ります。2つのモデルは異なる種類の問題を見つけやすいため、プロトコルは両方を使うことがよくあります。

監査報告書の読み方

まず対象範囲を見ましょう。どのコントラクトか、どのバージョンのコードか、どの期間か。バージョン1の監査は、バージョン2についてはほとんど何も語りません。次に、指摘事項を深刻度ごとに読みます。Critical と High の指摘は資金の損失につながる可能性があり、Medium は通常、特定の条件が必要で、Low と Informational はコードの衛生面に関するものです。それぞれの指摘について、修正済み、認識済み、異議ありのいずれとされているか、そして修正内容が改めてレビューされたかを確認してください。

シンプルな例

ある報告書に、High の指摘が1件挙がっています。端数処理のエラーによって、ユーザーが入れた額よりもわずかに多く出金でき、それを何千回ものトランザクションで繰り返せばボールトの資金を抜き取れる、というものです。チームはローンチ前に修正し、監査人が修正を確認します。外部の誰も、そのバグについて耳にすることはありません。これが監査が役目を果たしたということであり、表紙のロゴよりも指摘事項のセクションのほうが重要な理由です。

リスクと限界

監査はスナップショットです。レビュー後にコードは変わり、新しいコントラクトがそれとやり取りし、攻撃手法は進化します。DeFi で大きな被害を出したエクスプロイトの中には、監査済みのプロトコルを襲ったものもあり、多くは対象範囲外のコードや、複数のプロトコルの相互作用を突いたものでした。また、監査では、鍵の管理方法や準備金の中身といった、システムのオフチェーン部分を評価できません。だからこそ、監査はいくつかある層のひとつとして使うときに真価を発揮します。ローンチ後もリサーチャーに報酬を出し続けるバグバウンティ、稼働中のトランザクションを見守るランタイム監視、そして資産そのものについての準備金証明です。

Tori Finance のスマートコントラクトは、Sherlock と Nethermind による監査を受けています。監査はセキュリティの層のひとつであり、Hypernative によるランタイム監視、Accountable による準備金証明と組み合わされています。