スマートコントラクトのリスク：コード、オラクル、ガバナンス、アップグレードキー

ダッシュボード上では、スマートコントラクトのリスクが単一の出来事のように見えることがあります。しかし、その背後では、権利と不変条件の定義、稼働中システムの監査、対応とガバナンスが、それぞれ異なる参加者によって処理される別個の状態変化として存在します。こうした見えにくい引き継ぎの局面で、時間、コスト、リスクが生じます。

スマートコントラクトのリスクとは、コード、依存関係、またはガバナンスによって、ユーザーの期待とは異なる金銭的結果が生じる可能性です。攻撃対象領域には、ビジネスロジック、アクセス制御、算術処理と会計処理、オラクル、トークン、コンポーザビリティ、フロントエンド、秘密鍵、アップグレード、そしてコードを取り巻く法的な約束が含まれます。

監査は、範囲を定めたレビューから得られる証拠であり、保証ではありません。正しいソースコードであっても、異なるパラメーターでデプロイされたり、後からアップグレードされたり、操作されたオラクルと連携したりする可能性があります。不変のコードが変更リスクを抑えるのは、不変の動作と依存関係自体が安全な場合に限られます。

スマートコントラクトのリスクをSecurities.ioの幅広い解説の中に位置づけるには、DeFiスタックのリファレンスモデル、スマートコントラクト監査企業、スマートコントラクトのセキュリティとAIを比較してください。これらのガイドを併せて読むと、発行体、資産、投資家の権利、または運用インフラが変わることで、同じデジタル資産インフラに関する問いがどのように変化するかが分かります。

権利と不変条件の定義から対応とガバナンスまで：スマートコントラクトのリスクの連鎖

「権利と不変条件の定義」では、残高、権限、上限、そして常に満たされなければならない条件を定めます。そこでの成果物は次に「実装とテスト」への入力となり、レビュー済みのコンポーネントを使って、ユニットテスト、統合テスト、プロパティテスト、敵対的テストを行います。この引き継ぎは、スマートコントラクトのリスクを検証する最初の機会です。受け手は、完了した状態変更と、メッセージ、見積もり、または暫定記録とを区別できなければなりません。同じ検証は、その後のすべての矢印で、「対応とガバナンス」によって独立に照合可能な結果が得られるまで必要です。

図を「対応とガバナンス」から逆向きにたどってください。最終状態から、仕様、デプロイ済みのソースコードとバイトコード、テストと監査、パラメーターと管理者ロール、オラクルと依存関係のマップ、監視対象のイベント、インシデント対応、損失配分へとさかのぼり、さらに「運用と監視」で行使される権限、「稼働中システムの監査」で生じるエクスポージャー、「権利と不変条件の定義」で受け入れられる入力へとたどる必要があります。この連鎖が途切れると、意図しない呼び出し元がミント、引き出し、一時停止、またはアップグレードの権限を得ている場合でさえ、アクセス制御のバグが完了済みのトランザクションのように見えることがあります。この逆向きの追跡によって、提供者のラベルやインターフェースの状態ではなく、約束された金銭的不変条件と、それを変え得るコード、データ、ガバナンス上のあらゆる依存関係に焦点を当てた分析を保てます。

スマートコントラクトのリスクにおいて、重要な記録を管理するのは誰か

プロトコル開発者と監査担当者は、運用の流れの異なる側を担います。プロトコル開発者は経済面および技術面のロジックを設計・実装し、監査担当者は範囲を限定したバージョンをレビューして、調査結果を報告します。両者の記録――仕様、コード、テスト、コミット、依存関係、デプロイの記録と、監査範囲、手法、前提、深刻度、修正、残存リスクに関する記録――は、単一ベンダーのデータベースを複製したものではなく、同じ事象について整合している必要があります。オラクルまたは外部プロトコル、ガバナンスと鍵保有者、ユーザーまたはインテグレーターは、それぞれ異なる判断や証拠を加えます。これらの機能を同じものとして扱うと、裁量、流動性、法的責任がどこで関わるのかが見えなくなります。

ガバナンスと鍵保有者の障害は、スマートコントラクトのリスクにおける実務上の説明責任を試す場となります。パラメーターの変更、一時停止、アップグレード、資産の移動が可能です。プロトコル開発者と監査担当者が、役割、定足数、タイムロック、投票、鍵の管理、イベント履歴から、依然として状況を再構成できるかが問われます。コントラクトによってタスクを割り当てることはできますが、顧客への約束、資産、または義務を担う当事者は、外部委託条項を根拠に証拠の代わりとすることはできません。強靱な設計では、代替となる記録と、食い違いを解決する権限を持つ人物を明確にします。

実務におけるスマートコントラクトのリスクの状態変化

1. 権利と不変条件を定義する：スマートコントラクトのリスクにおける初期状態を定める

残高、権限、制限、そして常に満たされなければならない条件を定義します。スマートコントラクトのリスクに関するこの段階では、実装とテストで依拠できる条件を確立します。経済面および技術面のロジックを設計・実装するプロトコル開発者が中心となります。作業記録には、仕様、コード、テスト、コミット、依存関係、デプロイの記録を残します。

ここで見逃してはならない障害は、アクセス制御の不具合です。意図されていない呼び出し元が、トークンの発行、出金、一時停止、またはアップグレードの権限を取得します。この段階をテストするには、同じ時点、範囲、適用条件を用いて結果を記録し、実装とテストに進む前に前提を一つ変更します。スマートコントラクトのリスクにおいて、説明可能な引き継ぎには、誰が承認したか、どの記録が変更されたか、何が取り消し可能なままか、次の参加者が証拠を受け入れなかった場合に誰が損失を負担するかを明記します。

2. 実装とテスト：スマートコントラクトのリスクにおける判断ルールを特定する

レビュー済みのコンポーネントを使用し、単体テスト、統合テスト、プロパティテスト、敵対的テストを実施します。スマートコントラクトのリスクに関するこの段階では、デプロイ済みシステムの監査で依拠できる条件を精査します。範囲を限定したバージョンをレビューし、調査結果を報告する監査担当者が中心となります。作業記録には、監査範囲、手法、前提、深刻度、修正、残存リスクを残します。

ここで見逃してはならない障害は、会計上の不正利用です。丸め処理、再入可能性、シェア価格の設定、または状態の処理順序によって、何もないところから価値が生み出されます。この段階をテストするには、同じ時点、範囲、適用条件を用いて結果を再計算し、デプロイ済みシステムの監査に進む前に前提を一つ変更します。スマートコントラクトのリスクにおいて、説明可能な引き継ぎには、誰が承認したか、どの記録が変更されたか、何が取り消し可能なままか、次の参加者が証拠を受け入れなかった場合に誰が損失を負担するかを明記します。

3. デプロイ済みシステムを監査する：スマートコントラクトのリスクにおけるリスク移転を測定する

ソース、バイトコード、パラメーター、依存関係、鍵、運用上の制御を検証します。スマートコントラクトのリスクに関するこの段階では、運用と監視で依拠できる条件を再配分します。価格、メッセージ、トークン、または流動性を提供するオラクルまたは外部プロトコルが中心となります。作業記録には、情報源、更新、操作への耐性、管理者、インシデントを残します。

ここで見逃してはならない障害は、オラクル操作です。一時的または流動性の低い価格が、借り入れ、スワップ、または清算を左右します。この段階をテストするには、同じ時点、範囲、適用条件を用いて結果に負荷をかけ、運用と監視に進む前に前提を一つ変更します。スマートコントラクトのリスクにおいて、説明可能な引き継ぎには、誰が承認したか、どの記録が変更されたか、何が取り消し可能なままか、次の参加者が証拠を受け入れなかった場合に誰が損失を負担するかを明記します。

4. 運用と監視：スマートコントラクトのリスクに関する正式な記録を照合する

価値、異常、オラクル、特権的な操作、依存関係の変更を監視します。スマートコントラクトのリスクに関するこの段階では、対応とガバナンスで依拠できる条件を照合します。パラメーターの変更、一時停止、アップグレード、資産の移動が可能なガバナンスと鍵保有者が中心となります。作業記録には、役割、定足数、タイムロック、投票、鍵の管理、イベント履歴を残します。

ここで見逃してはならない障害は、依存先の障害です。トークン、ブリッジ、プール、またはチェーンが、前提とは異なる挙動を示します。この段階をテストするには、同じ時点、範囲、適用条件を用いて結果を比較し、対応とガバナンスに進む前に前提を一つ変更します。スマートコントラクトのリスクにおいて、説明可能な引き継ぎには、誰が承認したか、どの記録が変更されたか、何が取り消し可能なままか、次の参加者が証拠を受け入れなかった場合に誰が損失を負担するかを明記します。

5. 対応とガバナンス：スマートコントラクトのリスクの最終的な結果を検証する

開示された権限のもとで、一時停止、アップグレード、補償、移行を行うか、不変性を受け入れます。スマートコントラクトリスクのこの段階では、記録された結果が依拠し得る条件を確定します。コードと依存関係へのエクスポージャーを受け入れるため、ユーザーまたはインテグレーターが中心的な役割を担います。作業記録には、アドレス、バージョン、許可設定、トランザクションのシミュレーション、制限、退出方法を残す必要があります。

ここで異議を唱えなかった場合に生じるのが、緊急キーの悪用です。復旧手段が攻撃経路になったり、危機時に利用できなくなったりします。この段階を検証するには、同じ時点、範囲、適用条件に基づいて結果を証明し、記録された結果を確定する前に前提を一つ変更します。スマートコントラクトリスクにおいて、説明責任を果たせる引き継ぎでは、誰が承認したのか、どの記録が変更されたのか、何が引き続き取り消し可能なのか、次の参加者が証拠を受け入れなかった場合に誰が損失を負担するのかを明らかにします。

スマートコントラクトリスクで混同されやすい3つの状態

コードリスクとは、実装が意図された不変条件に違反する、またはエッジケースを適切に処理できないことです。一方、オラクルおよびコンポジションリスクとは、個々のコードは正しくても、誤った価格、メッセージ、トークンの挙動、または外部状態に依存していることです。ガバナンスおよびアップグレードリスクでは、さらに第三の条件として、特権を持つ主体がレビュー後に挙動、パラメーター、または資産を変更できることが加わります。この区別が重要なのは、2人のユーザーに同じような確認表示が見えていても、保有する権利、直面するタイミング、依存する機関が異なる場合があるためです。スマートコントラクトリスクを比較する際は、状態ごとに、基準となる記録と損失を負担する主体を明示することが有用です。

コードリスク、オラクルおよびコンポジションリスク、ガバナンスおよびアップグレードリスクを、金額、時間、消費された流動性、可逆性、法的請求権、残余損失という共通の基準で比較します。スマートコントラクトリスクでは、より迅速なラベル付けが、より確定的な状態を意味するとは限りません。また、報告上のリターンがより安定していても、経済的リスクが小さいとは限りません。単一の測定枠組みを用いれば、タイミングや会計上の違いを、実質的な改善と誤認せずに済みます。

スマートコントラクトリスクがもたらすコスト、インセンティブ、バランスシートへの影響

セキュリティへの支出は、トークン価格やマーケティング上の注目度ではなく、最大価値と不可逆性に応じて拡大すべきです。監査、形式手法、モニタリング、バグ報奨金は、それぞれ対象範囲の異なる補完的な対策です。

コンポーザビリティは、コントラクトが流動性やサービスを再利用できるため、ネットワーク価値を生み出します。一方で、依存関係の連鎖による相関リスクも生じます。オラクルやトークンの障害が起きると、ガバナンスが対応する前に、多数のプロトコルへ波及する可能性があります。

アップグレード可能性があれば、欠陥の修正や環境への適応が可能になりますが、ユーザーはガバナンスリスクに対するプレミアムを負担します。タイムロック、構成の多様なマルチシグ、権限の限定、上限設定、透明性の高いイベント記録により、管理者の存在を否定することなく、そのプレミアムを抑えられます。

スマートコントラクトリスクが顕在化する箇所と、最初に検証すべきこと

• アクセス制御の不具合：意図しない呼び出し元が、発行、引き出し、一時停止、またはアップグレードの権限を取得します。介入して権限と不変条件を明確にし、プロトコル開発者が通常の義務を引き続き負うなかで、コードリスクが上記の意味を保っているかを検証します。
• 会計処理の悪用：丸め処理、リエントランシー、シェア価格の設定、または状態の処理順序によって、何もないところから価値が生じます。介入して実装とテストを行い、監査人が通常の義務を引き続き負うなかで、オラクルおよびコンポジションリスクが上記の意味を保っているかを検証します。
• オラクル操作：一時的、または流動性の低い価格が、借り入れ、スワップ、または清算を左右します。介入してデプロイ済みシステムを監査し、オラクルまたは外部プロトコルが通常の義務を引き続き負うなかで、ガバナンスおよびアップグレードリスクが上記の意味を保っているかを検証します。
• 依存関係の障害：トークン、ブリッジ、プール、またはチェーンが想定とは異なる動作をする。ガバナンス担当者と鍵保有者が通常の責務を果たし続けるなかで、運用・監視を中断し、そのうえで、コードリスクが依然として上記の意味を持つかを確認する。
• 緊急用鍵の悪用：復旧手段が攻撃経路になったり、危機の際に利用できなくなったりする。ユーザーまたはインテグレーターが通常の責務を果たし続けるなかで、対応・ガバナンスを中断し、そのうえで、オラクルリスクと構成リスクが依然として上記の意味を持つかを確認する。

有効なスマートコントラクトリスクのストレステストでは、アクセス制御の不具合とオラクル操作を組み合わせ、個別に検証するだけにとどめない。デプロイ済みシステムの監査を凍結または遅延させ、ガバナンス担当者と鍵保有者を利用できない状態にし、ユーザーまたはインテグレーターに、アドレス、バージョン、承認済み利用枠、トランザクションのシミュレーション、制限、退出手段をもとに結果を照合させる。対応・ガバナンスによって説明可能な状態が一つに定まり、オラクルリスクと構成リスクに関わる権利が保たれ、中断前に定められたルールに基づいて不足分が割り当てられる場合に限り、設計は合格となる。

事例で追う：スマートコントラクトリスクの事象を最初から最後までたどる

ある融資コントラクトは監査済みだが、担保価格は流動性の低い単一のプールから取得している。攻撃者は一時的にそのプールの価格を動かし、担保の実際の価値を超える額を借り入れ、オラクルが価格を修正する前に資金を引き揚げる。融資コードは記述どおりに正確に実行されたが、オラクルへの信頼と流動性に関する前提が安全でなかったため、システムは機能しなかった。堅牢なレビューでは、依存関係の全体像をモデル化し、操作可能な担保へのエクスポージャーに上限を設ける。

この事例は、実装・テストで制御される前提を変更するか、オラクルまたは外部プロトコルが提供する証拠を取り除くことで、反証できる。変更の影響を、デプロイ済みシステムの監査、運用・監視、対応・ガバナンスの各段階を通じて追跡し、入力から見出しとなる結果へと一足飛びに進んではならない。仕様、デプロイ済みのソースコードとバイトコード、テストと監査、パラメーターと管理者権限、オラクルと依存関係のマップ、監視対象のイベント、インシデント対応、損失の配分から、新たなスマートコントラクトリスクの結果を再現できない場合、そのプロセスは文書化されていない判断または記録に依存している。

スマートコントラクトリスクがいま重要な理由

形式検証、継続的な監視、バグ報奨金、モジュールの分離、ウォレットシミュレーションの改善により、スマートコントラクトのセキュリティは向上している。一方、アップグレード可能なプロキシとクロスチェーンの依存関係は、ガバナンスリスクを拡大させる。最も有用な開示では、デプロイ済みコード、特権的な権限、オラクルの経路、価値の上限、損失配分の計画を、ユーザーが検証できる言葉で明示する。

スマートコントラクトリスクから得られる、長く通用する教訓は、権利と不変条件の明確化と、対応・ガバナンスは同じ出来事ではないということだ。その間に行われる判断が、約束された金融上の不変条件と、それを変え得るコード、データ、ガバナンス上の依存関係すべてを左右する一方、プロトコル開発者とユーザーまたはインテグレーターが把握できる記録の範囲は異なる場合がある。自動化は、こうした判断の検証コストを下げるなら有益だが、緊急用鍵の悪用を見えにくくする単一のステータスに判断を押し込めるなら危険である。

スマートコントラクトリスクを裏付ける証拠

スマートコントラクトリスクを裏付ける主な資料は、NISTサイバーセキュリティフレームワーク、BIS：DeFiの金融安定性リスク、CFTC技術諮問委員会のDeFi報告書である。これらは相互に補完する層として読むとよい。すなわち、ルールと定義、制度または市場の構造、そして実際の主張を検証するために必要な運用上の証拠である。いずれも、前述の製品文書、アカウント、取引記録の代わりとして扱うべきではない。

スマートコントラクトリスクを信頼する前に尋ねるべきこと

• 実装・テストに進む前に、プロトコル開発者は仕様、コード、テスト、コミット、依存関係、デプロイを証明できるか。
• 監査人とガバナンス担当者・鍵保有者の意見が食い違った場合、どの記録が判断の根拠となるか。
• デプロイ済みシステムの監査段階で生じたエクスポージャーの資金を誰が拠出し、またはその損失を誰が負担するのか。
• 法的・経済的な観点から、オラクルリスクと構成リスクはコードリスクとどう異なるのか。
• 対応・ガバナンスに至る前に、システムは会計処理を悪用する攻撃をどのように検知するのか。
• オラクルまたは外部プロトコルが利用できない場合、あるいはその証拠が古くなっている場合、何が起きるのか。
• 独立したレビュアーは、仕様、デプロイ済みのソースコードとバイトコード、テストと監査、パラメーターと管理者権限、オラクルと依存関係のマップ、監視対象のイベント、インシデント対応、損失の配分に照らして、結果を照合できるか。

スマートコントラクトリスクについては、「プラットフォームが処理する」といった表現を、明示されたアカウント、コントラクト、タイムスタンプ、承認ルール、責任を負う組織に置き換える。完全な回答であれば、レビュアーは対応・ガバナンスから権利と不変条件の明確化までさかのぼり、各記録の管理者を特定し、例外が発生する前に誰が損失を負担するかを算出できるはずだ。

スマートコントラクトリスクの根幹をなす原則

スマートコントラクトのリスクを最も明確に把握するには、想定される財務上の不変条件と、それを変え得るコード、データ、ガバナンス上のあらゆる依存関係を、5つの運用段階にわたって追跡し、仕様、デプロイ済みのソースコードとバイトコード、テストと監査、パラメーターと管理者権限、オラクルと依存関係のマップ、監視対象のイベント、インシデント対応、損失配分に照らして結果を検証する必要があります。フロー図は何が変わるのかを説明し、参加者の表は誰がその変更を承認できるのかを示します。3状態の比較によって性質の異なる主張が混同されるのを防ぎ、障害マップによって信頼度をどこで引き下げるべきかが分かります。これらを組み合わせることで、真の改善と、目立ちにくい層へ移された摩擦やリスクとを見分けられます。

スマートコントラクトのリスクに関する主要な一次資料

• NISTサイバーセキュリティフレームワーク
• BIS：DeFiがもたらす金融安定性へのリスク
• CFTC技術諮問委員会によるDeFi報告書