バグバウンティ

稼働中のスマートコントラクトは、いつでも誰かを招き入れているようなものです。資金を抱え、欠陥があれば、いずれ誰かが探しに来ます。バグバウンティは、欠陥を見つけた人に正当で報酬のある報告の手段を与えることでインセンティブを変え、攻撃するよりも開示するほうが得になるようにします。

バグバウンティの仕組み

プログラムは、対象範囲（どのコントラクト、ウェブサイト、システムが含まれるか）、ルール、報酬表を公開します。問題を見つけたリサーチャーは、再現できるだけの詳細を記した非公開の報告を提出します。チームは問題を確認して修正し、深刻度に応じた報酬を支払います。一般的なルールでは、実際のユーザー資金に対するテストを禁じ、修正されるまで問題を非公開にしておくことを求め、既知の問題や盗まれた鍵を前提とする攻撃は対象外とされます。

報酬の決め方

報酬は通常、深刻度の段階に沿って決まります。資金の直接的な損失につながりうる Critical の問題には上位の報酬が設定され、リスクにさらされる価値に連動した上限が設けられることもよくあります。High、Medium、Low と段階が下がるにつれて、報酬は小さくなります。その背景には経済的な理屈があります。攻撃者が奪える額に比べて報酬が小さければ、誘惑に駆られる発見者も出てくるため、DeFi の本格的なプログラムは高額になりうる報酬を用意しています。報酬の大きさと同じくらい重要なのが、迅速かつ公正に支払うことです。リサーチャーは、どのチームがプログラムを誠実に運営しているかを覚えているからです。

シンプルな例

あるリサーチャーが、ボールトの出金関数がまれなエッジケースでユーザーに有利な方向に端数処理されることに気づきます。1回のトランザクションの中でこれを何度も繰り返せば、そのエラーで少しずつボールトの資金を抜き取れる可能性があります。彼女は手順を非公開で報告書にまとめます。チームはバグを再現し、影響を受ける関数を一時停止し、修正をリリースし、High の報酬を支払います。資金は失われず、修正が反映されたあとに問題は公開されます。

バグバウンティと監査の違い

スマートコントラクト監査は、雇われたチームがある時点で行う、日程と範囲の決まったレビューです。バグバウンティには終わりがありません。プログラムが続く限り誰でも調べることができ、支払いは成果次第です。監査が主に力を発揮するのはローンチ前ですが、バウンティはその後、コードが稼働して実際の資金がかかっている間も、注意を向けてもらうための対価を払い続けます。ランタイム監視は、トランザクションをリアルタイムで見守ることで3つ目の層を加えます。

リスクと限界

バウンティが機能するのは、攻撃者より先にリサーチャーがバグを見つけ、しかも報酬がその時間に見合う場合だけです。対象範囲も重要です。掲載されたコントラクト以外の問題は対象にならないことがあり、それによって注意がほかへ向いてしまうこともあります。支払いが遅いプログラムや、正当な指摘に異議を唱えるプログラムは、リサーチャーのコミュニティの信頼を失います。また、バウンティはそれ自体で何かを修正するわけではありません。チームは迅速に対応する必要があり、報告されたあと、安全に修正するまでに時間がかかるバグもあります。プログラムが存在するという事実だけでは、その質はほとんどわかりません。報酬の上限額よりも、対象範囲、ルール、そして支払いの実績のほうが多くを教えてくれます。

Tori Finance は独自の社内バグバウンティプログラムを運営しており、コードの脆弱性を責任ある形で報告したリサーチャーに報酬を支払います。このプログラムはスマートコントラクト監査やランタイム監視とは別のもので、コードが稼働している間、レビューが続く状態を保ちます。