スマートコントラクトセキュリティ

スマートコントラクトセキュリティとは？

スマートコントラクトセキュリティとは、ユーザー資産を保護し、意図どおりに動作するよう、ブロックチェーン上のスマートコントラクトを設計、作成、テスト、監査、デプロイ、監視、アップグレードする取り組みです。

スマートコントラクトはブロックチェーン上に保存されるコードであり、ルールの実行、資産の移動、権限管理、ユーザーや他のコントラクトとの連携を行えます。

公式のEthereumスマートコントラクトのドキュメントでは、スマートコントラクトはブロックチェーンに保存され、トランザクションによってトリガーされると実行されるプログラムであると説明されています。

スマートコントラクトセキュリティが重要なのは、コントラクトがトークン、NFT、ステーキングポジション、レンディング市場、ボールト、トレジャリー、ブリッジ、ガバナンスシステムなど、価値ある暗号資産を管理する可能性があるためです。

通常のソフトウェアのバグはサービス停止を引き起こす場合がありますが、スマートコントラクトのバグは取り戻せない資産損失につながる可能性があります。

スマートコントラクトセキュリティは、問題が見つかった後にコードを修正するだけではありません。

プロトコル設計から始まり、デプロイ後も継続するライフサイクル全体のプロセスです。

安全なスマートコントラクトには、慎重なアーキテクチャ、安全なコーディングパターン、強力なテスト、独立したレビュー、安全なデプロイ、リアルタイム監視、明確な緊急対応手順が必要です。

簡単に言えば、スマートコントラクトセキュリティとは、ブロックチェーンアプリケーションをバグ、エクスプロイト、誤用、ガバナンス上の失敗、安全でないユーザー操作から守ることです。

スマートコントラクトセキュリティが重要な理由

ブロックチェーンのトランザクションは通常、公開され、自動で実行され、承認後に取り消すことが難しいため、スマートコントラクトセキュリティは重要です。

スマートコントラクトに脆弱性がある場合、世界中の攻撃者がコードを調査し、弱点を検証し、トランザクションでエクスプロイトを実行できる可能性があります。

脆弱なコントラクトは迅速に移動できる流動的な資産を保有している場合があるため、暗号資産アプリケーションは特に魅力的な攻撃対象となります。

公式のSolidityセキュリティに関する考慮事項では、新たな落とし穴が継続的に現れるため、スマートコントラクトのセキュリティガイダンスが完全になることはないと警告されています。

これは、スマートコントラクトセキュリティが絶えず変化する対象であることを示しています。

新しいトークン標準、DeFi設計、ブリッジモデル、アカウントシステム、ロールアップ、アップグレードパターンは、新たな攻撃対象領域を生み出す可能性があります。

スマートコントラクトセキュリティは、ユーザーの信頼にとっても重要です。

ユーザーはコードのすべての行を読むとは限りませんが、リスクを抑えるために、開発者、監査人、ツール、ウォレット、公開検証を信頼しています。

安全なコントラクトでも、管理者鍵の管理不備、オラクルデータの操作、アップグレード権限の侵害があれば失敗する可能性があります。

つまり、スマートコントラクトセキュリティには、技術的なコードの安全性と運用上のセキュリティの両方が必要です。

スマートコントラクトセキュリティの仕組み

スマートコントラクトセキュリティは、コード、設計、権限、データソース、デプロイプロセスが悪用される可能性を減らすことで機能します。

このプロセスは、最初のコードを書く前の脅威モデリングから始まります。

脅威モデリングでは、どの資産がリスクにさらされているか、誰が攻撃可能か、どの前提を信頼しているか、障害がどのような形で起きるかを検討します。

開発者はその後、安全なパターン、最小限の複雑性、明確な権限、検証済みの前提に基づいてコントラクトを作成します。

テストでは、通常のケース、エッジケース、敵対的なケースにおける想定どおりの動作と障害時の動作を確認します。

静的解析ツールは、既知の危険なパターンをコードから検出します。

ファジングと不変条件テストでは、多数の生成入力に対する予期しない動作を探します。

システムが十分に重要で、プロパティが明確に定義されている場合、形式検証により特定のプロパティを証明できます。

手動監査では、アーキテクチャ、コード、ビジネスロジック、経済性、デプロイ前提をレビューします。

デプロイ後は、監視とインシデント対応により異常な動作を迅速に検出し、対処できます。

一般的なスマートコントラクトの脆弱性

一般的なスマートコントラクトの脆弱性には、アクセス制御の不備、リエントランシー、オラクル操作、ロジックエラー、入力検証不足、未チェックの外部呼び出し、フラッシュローン攻撃、算術ミス、安全でない乱数、サービス拒否、プロキシのアップグレード性に関する不備などがあります。

OWASP Smart Contract Top 10 for 2026では、アクセス制御の脆弱性、ビジネスロジックの脆弱性、価格オラクル操作、フラッシュローンを利用した攻撃、入力検証不足、未チェックの外部呼び出し、算術エラー、リエントランシー攻撃、整数オーバーフロー・アンダーフロー、プロキシのアップグレード性に関する脆弱性などを主要カテゴリーとして挙げています。

この一覧は、スマートコントラクトセキュリティが有名な1種類のバグだけに限定されないことを示しているため有用です。

本来制限すべき関数が公開されているために、プロトコルが失敗する可能性があります。

オラクル価格を操作できるために、プロトコルが失敗する可能性があります。

アップグレードによってストレージレイアウトが変わるために、プロトコルが失敗する可能性があります。

ビジネスロジックが不公平な一連の操作を許すために、プロトコルが失敗する可能性があります。

緊急機能が1つの鍵に過大な権限を与えるために、プロトコルが失敗する可能性があります。

優れたセキュリティレビューでは、既知のパターンとプロジェクト固有のリスクの両方を探します。

最も危険なバグは、多くの場合、プロトコル固有の設計に適合するものです。

アクセス制御

アクセス制御とは、誰が機密性の高いスマートコントラクト機能を呼び出せるかを決めることです。

公式のOpenZeppelinアクセス制御のドキュメントでは、アクセス制御により、トークンのミント、提案への投票、送金の凍結、その他の重要な操作を実行できる者を管理できると説明されています。

アクセス制御のバグにより、攻撃者が無制限にトークンをミントしたり、トレジャリーを流出させたり、プロトコルを停止したり、手数料を変更したり、コントラクトをアップグレードしたり、ユーザー資金を移動したりできる可能性があります。

基本的なアクセス制御モデルでは、オーナーアドレスを使用する場合があります。

より高度なモデルでは、ロール、マルチシグウォレット、タイムロック、DAOガバナンス、緊急評議会、分離された運用権限を使用する場合があります。

優れたアクセス制御は、最小権限の原則に従います。

最小権限とは、各ロールには必要な権限だけを与え、それ以上は与えないことです。

ユーザーは重要なルールを変更できる者を知る必要があるため、アクセス制御は透明であるべきです。

コントラクトの計算が正しくても、隠された1つの管理者鍵が資産を盗めるなら安全ではありません。

アクセス制御は、実際のスマートコントラクトシステムにおいて最も重要なセキュリティ層となる場合が多くあります。

リエントランシー

リエントランシーは、コントラクトが自身の状態を安全に更新する前に外部コントラクトを呼び出し、外部コントラクトが予期しない順序で最初のコントラクトを再度呼び出せる場合に発生します。

Solidityのセキュリティドキュメントでは、リエントランシーを既知の落とし穴として説明し、より安全なインタラクションパターンを推奨しています。

典型的なリエントランシーの問題では、元の残高が減額される前に繰り返し出金できる可能性があります。

現代のリエントランシーは、トークンフック、コールバックシステム、関数間フロー、読み取り専用リエントランシー、複雑なDeFi統合を通じても発生する可能性があります。

一般的な防御策は、Checks-Effects-Interactionsパターンです。

このパターンでは、最初に要件を確認し、次に内部状態を更新し、最後に外部コントラクトを呼び出します。

別の防御策として、保護された関数へのネストされた呼び出しをブロックするリエントランシーガードがあります。

ただし、リエントランシーガードは正しい会計処理の代替にはなりません。

開発者はすべての外部呼び出しを特定し、呼び出されたコントラクトが悪意ある動作をした場合に何が起こり得るかを検討する必要があります。

ユーザーは、出金、コールバック、複雑なトークン連携を扱う未監査コントラクトに注意する必要があります。

オラクル操作

オラクル操作は、スマートコントラクトが攻撃者によって歪められる可能性のある外部データに依存する場合に発生します。

公式のEthereumオラクルのドキュメントでは、スマートコントラクトは自力でオフチェーン情報に直接アクセスできないため、オラクルが外部データへのアクセスを提供すると説明されています。

DeFiでは、担保価値、強制決済、スワップ、償還、決済額を決定する可能性があるため、価格オラクルが特に重要です。

プロトコルが流動性の薄いプールを唯一の価格ソースとして使用する場合、攻撃者は一時的に価格を操作し、不正なデータを信頼するコントラクトから利益を得る可能性があります。

フラッシュローンは、攻撃者が1回のトランザクションで大量の流動性を借りられるため、オラクル操作を容易にする可能性があります。

より安全なオラクル設計では、分散型データフィード、時間加重価格、サーキットブレーカー、妥当性チェック、遅延メカニズム、複数の独立したソースを使用する場合があります。

Chainlink Price Feedsのドキュメントでは、価格フィードは分散化された独立ノードオペレーターによって多数のデータソースから集約されたデータであると説明されています。

強力なオラクルシステムであっても、慎重な統合が必要です。

開発者は、小数点桁数、古いデータ、シーケンサーの状態、更新頻度、フォールバック時の動作を確認する必要があります。

誤ったデータにより、正しいコードでも有害な結果を生じ得るため、オラクルセキュリティはスマートコントラクトセキュリティの一部です。

ビジネスロジックの脆弱性

ビジネスロジックの脆弱性は、コードが記述された指示に従っていても、その指示が意図しない経済的結果を許す場合に発生します。

コントラクトはコンパイルされ、基本的なテストに合格し、正常に見える可能性があるため、これらのバグは構文エラーより検出が難しい場合があります。

レンディングプロトコルが担保を過大評価する可能性があります。

ステーキングコントラクトが部分出金後の報酬を誤って計算する可能性があります。

ガバナンスシステムが不公平な方法で票を集計する可能性があります。

ボールトが、他の入金者に不利な価格でユーザーの入出金を許す可能性があります。

ビジネスロジックのセキュリティには、プログラミング言語だけでなく金融モデルの理解が必要です。

開発者は、常に真でなければならない条件を表す不変条件を記述する必要があります。

例として、総シェアと資産が一致すること、ユーザーが残高を超えて出金しないこと、準備金がマイナスにならないことなどがあります。

ビジネスロジックのレビューは、スマートコントラクト監査に暗号資産経済学の専門知識が必要な理由の一つです。

入力検証

入力検証とは、関数パラメーターを使用する前に、それが許容可能かを確認することです。

スマートコントラクトは、無効なアドレス、不可能な数量、期限切れの締切、誤った配列長、権限のない呼び出し元、古い署名、安全でない設定値を拒否する必要があります。

検証が欠けると、資金ロック、不正な会計処理、誤った承認、統合の失敗、攻撃経路につながる可能性があります。

たとえば、オラクルアドレスを受け取る関数は、ガバナンス承認なしにゼロアドレスや信頼できないアドレスを許可すべきではありません。

スワップ関数は、不利な執行からユーザーを守るため、最小出力量と締切パラメーターを検証する必要があります。

トークン関数は、ミントまたはバーンの前に権限を検証する必要があります。

入力検証は明示的に行い、データがシステムに入る箇所の近くに配置する必要があります。

適切な検証はエラーメッセージとデバッグの改善にも役立ちます。

ただし、攻撃者はプロジェクトのフロントエンドを使わずに関数を直接呼び出せるため、検証によって誤った安心感を持つべきではありません。

すべてのpublic関数およびexternal関数は、攻撃の入口として扱う必要があります。

未チェックの外部呼び出し

未チェックの外部呼び出しは、コントラクトが別のコントラクトを呼び出したり価値を送信したりする際、呼び出しが成功したかを適切に確認しない場合に発生します。

外部呼び出しは、revert条件、ガス制限、関数の欠落、fallbackの動作、悪意あるコードなど、多くの理由で失敗する可能性があります。

外部呼び出しが失敗したにもかかわらず成功したとコントラクトが仮定すると、内部会計処理が誤る可能性があります。

未チェックの呼び出しは、報酬支払いシステム、トークン送転送、ブリッジメッセージにおける失敗を隠す可能性もあります。

開発者は戻り値を確認し、失敗条件を明確に処理する必要があります。

一部のトークンコントラクトは単純な標準例どおりに動作しないため、安全な送金ラッパーは互換性リスクの軽減に役立つ場合があります。

外部呼び出しは最小限に抑え、順序を慎重に設計する必要があります。

ユーザー資金が関わる場合、コントラクトは未知の外部動作に依存すべきではありません。

外部呼び出しが必要な場合、開発者は成功を前提とするのではなく、失敗を前提に設計する必要があります。

未チェックの外部呼び出しは、不確実性を隠れた状態破損に変えるため危険です。

算術エラー

算術エラーは、コントラクトが数量、手数料、シェア、報酬、債務、担保、価格を誤って計算する場合に発生します。

Solidity 0.8.xでは、ほとんどのオーバーフローとアンダーフローに対してデフォルトでチェック付き算術演算が導入されましたが、算術上の安全性が自動的に解決されたわけではありません。

公式のSolidityドキュメントでは、コンパイラは時間とともに進化するため、現行のコンパイラバージョンを使用し、言語変更を理解することが推奨されています。

現代の算術ミスには、丸め、精度損失、小数点桁数の不一致、スケーリング係数、演算順序、送金手数料付きトークンの動作、シェア換算式などが関係することが多くあります。

小さな丸めミスでも、攻撃者が操作を何度も繰り返せる場合は重大になる可能性があります。

DeFiプロトコルは、極端な値、ゼロ値、最大値、小額入金、大口入金、通常と異なるトークンの小数点桁数をテストする必要があります。

会計上の不変条件は継続的にテストする必要があります。

unchecked算術ブロックはガス効率のために有用な場合がありますが、開発者が安全性を証明できる場合にのみ使用すべきです。

算術セキュリティは、オーバーフロー防止だけに関するものではありません。

すべての金融計算がプロトコルの意図した経済性に一致することを確保することです。

フラッシュローン攻撃

フラッシュローン攻撃は、1回のトランザクション内で一時的に借りた流動性を使い、プロトコルの前提を操作する攻撃です。

フラッシュローンはアービトラージ、強制決済、資本効率を支援できるため、本質的に悪意あるものではありません。

プロトコルが攻撃者は大量の一時的資本にアクセスできないと仮定する場合に、危険になります。

フラッシュローンは、オラクル操作、ガバナンス攻撃、流動性プール操作、報酬ファーミングのエクスプロイトを増幅する可能性があります。

安全なプロトコルは、攻撃者が短期間に大量の資本へアクセスできると想定すべきです。

防御策には、堅牢なオラクル、時間加重データ、担保チェック、投票遅延、流動性の妥当性チェック、慎重な会計処理が含まれる場合があります。

開発者は、借入流動性がなければ攻撃が高価になるという前提に基づくセキュリティ設計を避けるべきです。

テストには、攻撃者が想定以上の資本を持つシナリオを含める必要があります。

フラッシュローン対策の大部分は、資本が一時的に豊富であっても正しく動作するプロトコルを設計することにあります。

フラッシュローンに脆弱なプロトコルは、通常、より深い設計上の前提に脆弱性があります。

安全でない乱数

安全でない乱数は、コントラクトが予測可能または操作可能な値を、ランダムであるかのように使用する場合に発生します。

乱数は、ゲーム、宝くじ、NFT公開、抽選、バリデーター選出、報酬配分で重要です。

ブロックデータを乱数として直接使用することは、バリデーターやブロックビルダーが一部の値に影響を与えたり予測したりできる可能性があるため、安全ではない場合があります。

攻撃者は有利な条件を確認した後に関数を呼び出すタイミングを選ぶ可能性もあります。

安全な乱数には、リスクにさらされる価値に適した設計を使用する必要があります。

システムに応じて、commit-revealスキーム、検証可能なランダム関数、遅延公開、信頼できる乱数ネットワークなどの手法が考えられます。

乱数は、セキュリティ上重要な依存関係としてレビューすべきです。

乱数が弱いゲームは、攻撃者にとって予測可能な報酬支払いシステムになり得ます。

乱数が弱いNFT公開では、不公平な特性選択が可能になる場合があります。

暗号資産では、攻撃者が公開データを観察できる一方で、すべてのノードが同じ結果に到達する必要があるため、乱数の扱いは困難です。

サービス拒否

スマートコントラクトにおけるサービス拒否とは、攻撃者が通常のユーザーまたはプロトコル機能の正常な動作を妨げられる状態を指します。

コントラクトは、無制限ループ、強制revert、ガス消費の大きい操作、ブロックされた出金、ストレージ増加、依存先の障害により、サービス拒否の影響を受ける可能性があります。

たとえば、報酬支払い関数が大規模なリスト内のすべてのユーザーをループ処理する場合、リストが大きくなりすぎると実行不能になる可能性があります。

1人の受取人がrevertして一括支払い全体をブロックできる場合、システム全体が停止する可能性があります。

プルペイメントパターンでは、ユーザーが個別に出金できるようにすることで、一部のサービス拒否リスクを軽減できます。

コントラクトは、1回のトランザクションで無制限の数のユーザーを処理する必要がないよう設計すべきです。

開発者は状態が増加した場合のガス使用量をテストする必要があります。

また、重要なフローに対して緊急退出手段と障害分離を設計する必要があります。

サービス拒否は直接資金を盗まない可能性がありますが、資金を凍結したりプロトコル運用を妨げたりする場合があります。

可用性はスマートコントラクトセキュリティの一部です。

tx.originのリスク

認可にtx.originを使用することは、危険なスマートコントラクトパターンです。

tx.originに関するSolidityセキュリティの考慮事項では、認可にtx.originを使用しないよう警告されています。

tx.originはトランザクションを開始した元の外部所有アカウントを指し、msg.senderは直前の呼び出し元を指します。

悪意あるコントラクトはユーザーを誘導して自身を呼び出させ、その後、tx.originが依然としてユーザーを指す別のコントラクトを呼び出す可能性があります。

対象コントラクトがtx.originを信頼する場合、悪意あるコントラクトは意図された認可を回避できる可能性があります。

コントラクトは通常、代わりにmsg.senderと明示的な権限チェックを使用すべきです。

メタトランザクション、アカウント抽象化、プロキシ、リレイヤーでは呼び出し元の識別がより複雑になる可能性があるため、開発者は注意する必要があります。

認可は、実際の信頼モデルに基づいて設計する必要があります。

呼び出し元チェックの単純な近道が、重大な脆弱性になる可能性があります。

tx.originのリスクは、ブロックチェーンの実行コンテキストが重要である理由を示す典型例です。

署名とリプレイのリスク

署名リスクは、ユーザーが再利用、誤解、または意図しないコンテキストで適用され得るメッセージに署名する場合に発生します。

スマートコントラクトでは、permit、ガスレス承認、注文、投票、請求、ブリッジ、アカウント権限のために署名がよく使われます。

リプレイ攻撃は、有効な署名が複数回再利用されたり、別のチェーン、コントラクト、コンテキストで再利用されたりする場合に発生します。

適切な署名設計には、nonce、期限、チェーンID、コントラクトアドレス、ドメイン分離、明確な型付きデータが含まれます。

ユーザーは、理解できないメッセージに署名しないようにすべきです。

開発者は、無害に見えて強力な操作を許可する曖昧なメッセージを避けるべきです。

可能な場合、ウォレットは読みやすい署名情報を表示すべきです。

プロトコルは使用済み署名を無効化し、クロスチェーンでのリプレイを防止する必要があります。

以前の署名が後から操作を許可できる場合、トランザクションがユーザーによって直接署名される必要はないため、署名セキュリティは重要です。

コントラクトが受け入れるよう設計されている場合、署名済みメッセージは署名済みトランザクションと同じほど強力になり得ます。

トークン標準のリスク

トークン標準のリスクは、コントラクトがすべてのトークンが同じように動作すると仮定する場合に発生します。

一部のトークンは送金手数料を徴収し、残高をリベースし、boolean値を返さず、送金を停止し、アドレスをブラックリスト化し、フックを使用し、通常と異なる小数点桁数を持ちます。

すべてのトークンが単純なトークン例のように動作すると仮定するDeFiプロトコルは、非標準的な動作を扱う際に破綻する可能性があります。

NFT標準にも、フック、送転送制限、ロイヤリティ、メタデータ変更、オペレーター承認が含まれる場合があります。

開発者は理想的なテストトークンだけでなく、通常と異なるトークンの動作でもテストする必要があります。

安全なラッパーは、想定された値を返さないトークンの処理に役立つ場合があります。

プロトコルは、どのトークンをサポートするかとその理由を定義する必要があります。

サポート対象外のトークンを上場すると、会計処理または出金の失敗につながる可能性があります。

ユーザーは、一般的なインターフェースと互換性があることがトークンを無リスクにするわけではないと理解する必要があります。

スマートコントラクトセキュリティには、コントラクトが連携する資産と標準も含まれます。

アップグレード性のリスク

アップグレード性のリスクは、デプロイ後にコントラクトロジックを変更できることから生じます。

公式のEthereumスマートコントラクトのアップグレードに関するドキュメントでは、アップグレードパターンにより、開発者がデプロイ後にコントラクトの動作を変更できると説明されています。

アップグレード性は、バグ修正や機能追加に役立つ場合があります。

一方で、管理者またはガバナンスが安全なロジックを安全でないロジックに置き換えることも可能にします。

プロキシパターンには、ストレージレイアウトの破損、保護されていないinitializer、誤った実装アドレス、管理者鍵の侵害、隠れたロジック変更などの特別なリスクがあります。

アップグレード可能なコントラクト作成に関するOpenZeppelinのガイダンスでは、アップグレード可能なコントラクトを作成する際の重要な注意点が説明されています。

ユーザーは、資金を入金する前に、プロトコルがアップグレード可能かを確認すべきです。

また、誰がアップグレードを管理するか、タイムロックがあるか、各アップグレード後に実装が検証されているかも確認すべきです。

バージョン1の監査がバージョン2を自動的に対象とするわけではありません。

アップグレード性は有用ですが、重要な信頼上の前提です。

初期化のリスク

初期化のリスクは、アップグレード可能なコントラクトが正しく初期化されない場合に発生します。

多くのプロキシシステムでは、コンストラクタは通常の方法でプロキシストレージを初期化しません。

開発者はinitializer関数を使用して、オーナー、ロール、トークン名、設定値、その他の初期状態を設定します。

initializerが開放されたままの場合、攻撃者がコントラクトを初期化して支配権を取得する可能性があります。

reinitializerに問題がある場合、後のアップグレードで重要な権限または設定がリセットされる可能性があります。

直接使用することを意図していない実装コントラクトでは、直接初期化を無効にする必要がある場合があります。

デプロイスクリプトは、初期化が正しい値で正確に1回行われたことを検証する必要があります。

監査人は、初期化と再初期化の経路を慎重にレビューする必要があります。

ユーザーが初期化の詳細を見ることはほとんどありませんが、不適切なinitializerは誰がプロトコルを支配するかを決める可能性があります。

初期化は単なるコーディング上の詳細ではなく、デプロイセキュリティの問題です。

ストレージレイアウトのリスク

ストレージレイアウトのリスクは、アップグレード後のコントラクトが古いストレージを誤って読み書きする場合に発生します。

公式のSolidityストレージレイアウトのドキュメントでは、状態変数がストレージ内でどのように構成されるかが説明されています。

プロキシシステムでは、通常、ストレージはプロキシに残り、ロジックは実装コントラクトで変更されます。

新しい実装が変数の順序または型を不適切に変更すると、古い状態が破損する可能性があります。

残高マッピングが誤って解釈される可能性があります。

オーナーアドレスが上書きされる可能性があります。

準備金の値が無意味になる可能性があります。

アップグレードツールでは、アップグレード前にストレージレイアウトを比較できますが、開発者は引き続き変更を慎重にレビューする必要があります。

ストレージレイアウトは、プロトコルの恒久的なデータ構造の一部として扱うべきです。

新しい関数ロジックが正しく見えても、ストレージのミスによりプロトコルが破綻する可能性があります。

フロントエンドのセキュリティ

スマートコントラクトセキュリティは、ユーザーが操作するフロントエンドにも依存します。

安全なコントラクトでも、ウェブサイトが侵害され、ユーザーに悪意あるトランザクションへの署名を求める場合は危険になり得ます。

フロントエンド攻撃では、送付先アドレス、承認先、表示価格、請求ボタン、トランザクションデータが変更される可能性があります。

ユーザーはウェブサイトの表示だけを信頼するのではなく、コントラクトアドレスとウォレットのプロンプトを確認する必要があります。

開発者は、デプロイパイプライン、ドメイン名、コンテンツ配信システム、DNSレコード、ビルドツールを保護する必要があります。

重要なフロントエンドの変更は、コード変更と同様にレビューすべきです。

ウォレットのトランザクションシミュレーションと明確な署名プロンプトは、一部のユーザーリスクを軽減できます。

ただし、インターフェースが誤解を招く場合、ユーザーは有害な操作を承認する可能性があります。

dAppの安全性は、ウェブサイト、ウォレット、スマートコントラクトに至る経路全体の安全性に左右されます。

ユーザーはインターフェースを通じて署名するため、フロントエンドセキュリティはスマートコントラクトセキュリティの一部です。

秘密鍵と管理者のセキュリティ

秘密鍵のセキュリティは、スマートコントラクトをデプロイ、アップグレード、停止、設定、運用するアカウントを保護します。

管理者鍵はコア設定を変更する権限を持つ場合があるため、コードのバグ以上の被害を与えることがあります。

プロトコルは、価値あるコントラクトに対して1つのホットウォレットへ無制限の権限を与えることを避けるべきです。

マルチシグウォレットでは、機密性の高い操作の前に複数の承認を要求できます。

タイムロックは実行を遅らせ、ユーザーと監視者が保留中の変更をレビューする時間を提供できます。

ハードウェアウォレット、安全な署名デバイス、アクセス方針、運用手順書は、鍵の侵害リスク低減に役立ちます。

チームは、1つの鍵がデプロイ、アップグレード、トレジャリー、オラクル設定、緊急機能を同時に管理しないよう、ロールを分離する必要があります。

鍵のローテーションと緊急復旧計画は、インシデント発生前に準備しておく必要があります。

ユーザーは、プロトコルを信頼する前に管理者権限を確認すべきです。

スマートコントラクトセキュリティには、コントラクトを変更できる人と鍵も含まれます。

テスト

テストは、スマートコントラクトのバグに対する最初の重要な技術的防御策です。

ユニットテストでは個々の関数を確認します。

統合テストでは複数のコントラクトが連携してどのように動作するかを確認します。

フォークテストでは、コピーした実ネットワークの状態に対する動作をシミュレーションします。

回帰テストでは、修正済みのバグが後から再発しないことを確認します。

ネガティブテストでは、権限のない操作または無効な操作が想定どおり失敗することを確認します。

優れたテストには、エッジケース、ゼロ値、最大値、通常と異なるトークン小数点桁数、送金手数料付きトークン、古いオラクル、失敗した送金、停止状態が含まれます。

テストにはデプロイスクリプトとアップグレードスクリプトも含めるべきです。

関数テストが強力でも、設定値が誤っていればデプロイ時にコントラクトが失敗する可能性があります。

テストは必要ですが、高価値のコントラクトではテストだけでは十分ではありません。

ファジングと不変条件テスト

ファジングは、多数の入力を生成して予期しない動作を探すテスト手法です。

不変条件テストでは、多数の操作と状態にわたって重要なプロパティが真であり続けるかを確認します。

不変条件として、総資産は常にユーザーの総請求額以上であるべきだと定めることができます。

別の不変条件として、ユーザーは自身の残高を超えて出金できないと定めることができます。

攻撃者は開発者が想定しなかった入力を試すため、ファジングは有用です。

DeFiシステムでは、多数の有効な操作が予期しない順序で組み合わさったときに失敗することがあるため、不変条件テストは有用です。

可能な場合、ファジングには複数ユーザー、複数トークン、繰り返し操作、境界的なタイミング、敵対的なコントラクトを含めるべきです。

開発者は、理解するまで不変条件の失敗をすべて重大なシグナルとして扱う必要があります。

監査人は、経済的なバグやステートマシンのバグを見つけるためにファジングをよく使用します。

複雑なスマートコントラクトでは、ファジングと不変条件テストは単純な例示テストより価値が高い場合があります。

静的解析

静的解析は、コードを実行せずにスキャンし、危険なパターンや起こり得るバグを検出します。

Slitherのドキュメントでは、Slitherは脆弱性検出器を実行し、コントラクト情報を出力し、開発者のコード理解を支援するSolidityおよびVyper向け静的解析フレームワークであると説明されています。

静的解析では、リエントランシーパターン、未使用変数、危険な呼び出し、イベントの欠落、不適切な可視性、疑わしい依存関係などを検出できます。

高速であり、開発パイプラインに統合できます。

静的解析は、誤検知を発生させたりビジネスロジックのバグを見落としたりする可能性があるため、完全ではありません。

開発者は、静的解析レポートに問題がないことを安全性の証明として扱うべきではありません。

また、レビューせずに警告を無視すべきでもありません。

静的解析は、早期かつ頻繁に使用するのが最適です。

監査人がより深い問題に時間を割く前に、多くの単純なミスを検出します。

自動ツールは、人間の判断と組み合わせることでスマートコントラクトセキュリティを向上させます。

形式検証

形式検証は、定義された前提の下で、選択したコントラクトのプロパティが成り立つことを数学的手法で証明します。

Certora Proverのドキュメントでは、形式検証はスマートコントラクトのバイトコードを、期待される動作を記述したルールと比較するものだと説明されています。

形式検証は、高価値プロトコル、コア会計ロジック、トークン不変条件、レンディング市場、ブリッジ、ガバナンスシステムにとって価値がある場合があります。

総供給量の上限、残高保全、アクセス制御の制約、出金の安全性などのプロパティを証明できます。

形式検証の有効性は、指定するプロパティの質に依存します。

仕様が実際のリスクを見落としている場合、プロトコルが安全でなくても証明に合格する可能性があります。

形式検証には専門的なスキルと時間も必要です。

監査、テスト、監視、安全な運用の代替にはなりません。

重要なプロパティが明確で、リスクにさらされる価値が高い場合に最も有用です。

形式検証は特定の主張に対してより強い保証を提供しますが、すべてに対する普遍的な安全性を提供するものではありません。

手動監査

手動のスマートコントラクト監査とは、専門家が行う独立したセキュリティレビューです。

監査では、アーキテクチャ、コード、アクセス制御、テスト、アップグレード性、経済的前提、オラクル設計、デプロイスクリプト、ドキュメントを調査できます。

監査では、脆弱性を特定し、影響を説明し、修正を推奨し、修正が適用されたかを確認すべきです。

監査はスマートコントラクトの安全性を保証するものではありません。

デプロイ前またはデプロイ後に専門家のレビューを加えることで、リスクを軽減します。

監査は特定のコントラクト、ブランチ、コミット、機能だけを対象とする場合があるため、監査範囲が重要です。

ユーザーは、デプロイ済みコードが監査済みコードと一致するかを確認すべきです。

後のアップグレードが別途監査されたかも確認すべきです。

優れた監査はマーケティング用のバッジではなく、セキュリティプロセスの一部です。

真剣なプロトコルは、監査結果をチェックボックスではなくエンジニアリング作業として扱うべきです。

バグバウンティ

バグバウンティは、脆弱性を責任ある形で報告した外部研究者に報酬を提供する仕組みです。

内部チームや監査だけではすべての問題を見つけられないため、バグバウンティは有用です。

公開バウンティでは、異なるスキル、ツール、攻撃者視点を持つ研究者を集められます。

優れたバウンティプログラムでは、範囲、深刻度レベル、報酬範囲、開示ルール、安全なテストルールを定義します。

報酬はリスクにさらされる価値に見合うべきです。

大きな価値を保有するプロトコルに対する小さなバウンティは、責任ある開示の動機付けにならない可能性があります。

バグバウンティのトリアージは迅速かつ専門的に行うべきです。

信頼できる問題を報告した研究者を無視すべきではありません。

バグバウンティは通常、コードが公開またはデプロイされた後に行われるため、監査の代替にはなりません。

時間とともに問題を発見するのに役立つ、継続的なセキュリティ層です。

監視とランタイムセキュリティ

監視では、デプロイ済みコントラクトについて、不審な活動、異常なトランザクション、異常な価格変動、大口出金、ガバナンス操作、失敗した呼び出し、アップグレードイベントを監視します。

スマートコントラクトセキュリティはデプロイで終わりません。

攻撃者は、流動性が高いとき、市場のボラティリティが高いとき、チームが監視していないときにコントラクトを悪用することがあります。

監視は、緊急停止、ユーザーへの警告、パラメーター変更、インシデント対応に間に合うよう、不審な動作を早期検出できる場合があります。

重要なアラートには、TVLの急減、予期しないミント、大規模な管理者操作、異常なオラクル乖離、繰り返される呼び出し失敗、実装のアップグレードなどがあります。

監視対象には、スマートコントラクト、フロントエンド、ガバナンス、オラクル、鍵、インフラを含めるべきです。

チームはローンチ前にアラートシステムをテストする必要があります。

アラートは、誰かが迅速かつ正確に対応できる場合にのみ有用です。

プロトコルが重大なイベント後にインシデントレポートとポストモーテムを公開すると、ユーザーにとって有益です。

ランタイムセキュリティは、スマートコントラクトセキュリティを一度きりのレビューから継続的な運用へと変えます。

インシデント対応

インシデント対応とは、問題が発生した際にプロトコルが何をするかを定める計画です。

対応計画には、コントラクトの停止、入金の無効化、フロントエンド警告の更新、ユーザーへの連絡、セキュリティ研究者との連携、パッチ準備、情報公開が含まれる場合があります。

緊急制御はユーザーを保護できますが、中央集権化リスクも生み出します。

プロトコルは、誰がどの条件で緊急操作を発動できるかを文書化すべきです。

チームは、実際の資金がリスクにさらされる前にインシデントシナリオを練習する必要があります。

情報発信は正確、迅速、誠実であるべきです。

インシデントを隠すと、ユーザー損失が悪化する可能性があります。

インシデント後の分析では、根本原因と長期的な修正を特定する必要があります。

プロトコルは、進行中のエクスプロイト時に即興対応へ依存すべきではありません。

強力なインシデント対応計画は、スマートコントラクトセキュリティの重要な要素です。

安全なデプロイ

安全なデプロイとは、正しいコード、正しい設定、正しい所有権、正しいアドレス、正しい検証によってスマートコントラクトをローンチすることです。

デプロイ時のミスは、コードのバグと同じほど危険になる可能性があります。

コントラクトは監査済みでも、誤った管理者、オラクル、トークンアドレス、手数料設定、アップグレード権限でデプロイされれば安全でなくなる可能性があります。

デプロイスクリプトはレビュー、テスト、バージョン管理を行う必要があります。

チームはメインネットへのデプロイ前にチェックリストを使用すべきです。

コントラクトアドレス、コンストラクタ引数、実装アドレス、管理者アドレス、トランザクションハッシュなど、重要なデプロイ出力を記録する必要があります。

可能な場合、デプロイ後にソースコードを検証すべきです。

公式のEthereumスマートコントラクト検証のドキュメントでは、検証はソースコードとコンパイル済みバイトコードを比較するものだと説明されています。

ユーザーは、操作前にプロジェクトの公式アドレスと検証済みエクスプローラーのデータを比較すべきです。

デプロイセキュリティは、レビュー済みコードが実際のオンチェーンリスクとなる地点です。

安全なアップグレード

安全なアップグレードには、新しい実装をデプロイするだけでは不十分です。

チームはコード差分をレビューし、ストレージレイアウトを検証し、旧状態に対してテストし、ドキュメントを更新し、ソースコードを検証し、アップグレード計画を開示すべきです。

高リスクのアップグレードは、実行前に監査を受けるべきです。

タイムロックとガバナンス提案は、ユーザーに変更をレビューする時間を与えます。

緊急アップグレードでは迅速な実行が必要な場合がありますが、その後も文書化する必要があります。

安全なアップグレードは、出金、手数料、担保、ガバナンス、トークン供給についてのユーザーの前提を密かに変更すべきではありません。

アップグレードによりアドレスを変えずにリスクプロファイルが変化する可能性があるため、ユーザーは依存するプロトコルを監視すべきです。

開発者は、最初のアップグレードが必要になる前にアップグレード用の手順書を作成すべきです。

アップグレード鍵はマルチシグと運用管理で保護する必要があります。

安全なアップグレード性とは、無制限の変更ではなく、制御された変更です。

ユーザーのデューデリジェンス

ユーザーは、操作前に基本的なセキュリティシグナルを確認することで、スマートコントラクトのリスクを軽減できます。

コントラクトのソースコードが検証されているかを確認すべきです。

監査が存在するか、また検出事項が修正されたかを確認すべきです。

コントラクトがアップグレード可能か、誰がアップグレードを管理するかを確認すべきです。

管理者ロール、停止機能、ミント権限、ブラックリスト権限、オラクル設定、出金ルールを確認すべきです。

コントラクトアドレスをプロジェクトの公式情報源と照合すべきです。

新しいプロトコルを使用する際は、少額から始めるべきです。

理解できないトランザクションに署名しないようにすべきです。

トークン承認を確認し、実用的な場合は未使用の権限を取り消すべきです。

ユーザーのデューデリジェンスですべてのリスクを排除することはできませんが、多くの回避可能な損失を防ぐことができます。

開発者のためのスマートコントラクトセキュリティ

開発者は、スマートコントラクトを最初から重大なリスクを伴う金融ソフトウェアとして設計すべきです。

コードはシンプル、モジュール式、かつ十分に文書化された状態に保つべきです。

一般的なパターンについて危険なカスタムコードを書くのではなく、適切な場合は成熟したライブラリを使用すべきです。

複雑な金融ロジックを実装する前に、不変条件を定義すべきです。

監査前にテスト、ファジング、静的解析、手動レビューを使用すべきです。

マーケティング上の期限に合わせるためにデプロイを急ぐべきではありません。

コンパイラバージョン、依存関係のバージョン、デプロイ設定をレビューすべきです。

すべての特権ロールと緊急権限を文書化すべきです。

ローンチ前に監視とインシデント対応を計画すべきです。

安全な開発は、最終的な監査レポートではなくプロセスです。

ユーザーのためのスマートコントラクトセキュリティ

ユーザーは、スマートコントラクトが透明であると同時にリスクを伴う可能性があることを理解すべきです。

ソースコードの検証は、コードが可視であることを意味するだけで、安全であることを意味しません。

監査は専門家が一定範囲をレビューしたことを意味するだけで、バグが存在しないことを意味しません。

高い利回りは、高い技術的または経済的リスクに対する補償である可能性があります。

人気のプロトコルでも脆弱である可能性があります。

長期間運用されているプロトコルでも、新しいアップグレード、新しい統合、新しい市場環境の影響を受ける可能性があります。

可能な場合、大きな残高にはハードウェアウォレットまたはより強力なカストディ設定を使用すべきです。

日常利用ウォレットと長期保管用ウォレットを分けるべきです。

未知のコントラクトに対する無制限の承認を避けるべきです。

ウォレット署名は、取り戻せないスマートコントラクト操作を許可できることを覚えておく必要があります。

よくあるスマートコントラクトセキュリティのミス

よくあるミスの1つは、監査を安全性の保証として扱うことです。

もう1つは、失敗ケースをテストせずにローンチすることです。

3つ目は、1つの管理者鍵に過度に多くの権限を与えることです。

4つ目は、操作可能な価格ソースに依存することです。

5つ目は、アップグレード時にストレージレイアウトを無視することです。

6つ目は、認可にtx.originを使用することです。

7つ目は、すべてのトークンが同じように動作すると信頼することです。

8つ目は、initializer関数を保護しないことです。

9つ目は、ローンチ後にデプロイ済みコントラクトを監視しないことです。

10個目は、明確なインターフェース設計がなくても、ユーザーが危険なウォレットプロンプトを理解すると仮定することです。

スマートコントラクトセキュリティのメリット

スマートコントラクトセキュリティの第1のメリットは、ユーザー資金の保護です。

第2のメリットは、プロトコルの信頼性向上です。

第3のメリットは、透明な制御と検証済みの動作によるユーザー信頼の向上です。

第4のメリットは、緊急停止とエクスプロイトによる損失のリスク低減です。

第5のメリットは、他のプロトコルが十分にレビューされたコントラクトをより安心して信頼できるため、統合が容易になることです。

第6のメリットは、リスクと管理者権限が明確に文書化されることによるガバナンスの改善です。

第7のメリットは、監視と手順書が準備されていることによる迅速なインシデント対応です。

第8のメリットは、安全なアップグレードとデプロイの実践による長期的な保守性の向上です。

問題に責任を持って対応すれば、優れたセキュリティは評判への損害を軽減する場合もあります。

ユーザーは資産保護を真剣に行うプロトコルを好むため、スマートコントラクトセキュリティは競争優位性になります。

スマートコントラクトセキュリティのリスクと限界

どのセキュリティプロセスでも、スマートコントラクトが完全に安全であることを保証することはできません。

監査はバグを見落とす可能性があります。

テストは未知のエッジケースを見落とす可能性があります。

形式検証は誤ったプロパティを証明する可能性があります。

監視は攻撃の検出が遅すぎる可能性があります。

管理者制御は悪用または侵害される可能性があります。

ガバナンスが有害な変更を承認する可能性があります。

オラクルシステムは通常と異なる市場状況で失敗する可能性があります。

ユーザーは安全でないインターフェースを通じて悪意あるトランザクションに署名する可能性があります。

スマートコントラクトセキュリティの目的は、完全なリスク排除ではなくリスク低減です。

スマートコントラクトセキュリティのベストプラクティス

デプロイまで待つのではなく、設計段階からセキュリティ作業を始めましょう。

脅威モデリングを使い、資産、攻撃者、信頼上の前提、障害モードを特定しましょう。

明確な権限と不要な複雑性を最小限に抑えたシンプルなコードを書きましょう。

現行の安定したコンパイラバージョンを使用し、コンパイラ警告をレビューしましょう。

通常ケース、エッジケース、失敗ケース、敵対的なユーザー行動をテストしましょう。

外部監査の前に、ファジング、不変条件テスト、静的解析、手動レビューを実施しましょう。

高価値のコントラクトを監査し、有意義な監査情報を公開しましょう。

特権操作にはマルチシグ制御、タイムロック、透明なガバナンスを使用しましょう。

ローンチ後、ソースコードとデプロイ設定を検証しましょう。

ユーザーが重要な資産を入金する前に、稼働中のコントラクトを監視し、インシデント対応を準備しましょう。

FAQ

スマートコントラクトセキュリティとは何ですか？

スマートコントラクトセキュリティとは、ブロックチェーン上のスマートコントラクトを、バグ、エクスプロイト、安全でない権限、不正なデータ、アップグレードの失敗、危険なユーザー操作から保護することです。

スマートコントラクトセキュリティはなぜ重要ですか？

スマートコントラクトは実際の暗号資産を管理でき、承認済みのブロックチェーントランザクションは通常取り消しが難しいため、スマートコントラクトセキュリティは重要です。

最も一般的なスマートコントラクトの脆弱性は何ですか？

普遍的に最も多い単一の脆弱性はありませんが、アクセス制御の不備、リエントランシー、オラクル操作、ロジックエラー、アップグレード性に関するミスは、重要なカテゴリーに含まれます。

監査はスマートコントラクトの安全性を保証しますか？

いいえ。監査はリスクを軽減しますが、すべての脆弱性、経済的欠陥、将来のアップグレードリスクが見つかったことを保証することはできません。

スマートコントラクトにおけるリエントランシーとは何ですか？

リエントランシーは、外部呼び出しによって、最初のコントラクトが安全に状態を更新する前に別のコントラクトが再度呼び出せるようになる脆弱性です。

オラクル操作とは何ですか？

オラクル操作は、コントラクトが攻撃者によって利益目的で歪められる可能性のある外部価格またはデータ入力に依存する場合に発生します。

アップグレード可能なスマートコントラクトは安全ですか？

アップグレード可能なスマートコントラクトは、慎重に設計・管理されれば安全な場合がありますが、管理者権限、ストレージレイアウト、実装変更、ユーザー信頼に関するリスクが追加されます。

スマートコントラクトセキュリティに役立つツールには何がありますか？

ユニットテスト、ファズテスト、不変条件テスト、静的解析ツール、形式検証システム、監視ツール、ブロックチェーンエクスプローラー、デプロイチェックリストなどが役立ちます。

ユーザーはスマートコントラクトのセキュリティをどのように確認できますか？

ユーザーは、ソースコード検証、監査、管理者権限、アップグレード性、トークン承認、オラクル設計、プロトコルのドキュメント、公式コントラクトアドレスを確認できます。

スマートコントラクトセキュリティですべてのリスクをなくせますか？

いいえ。スマートコントラクトセキュリティはリスクを軽減しますが、技術的、経済的、運用上、ガバナンス上、市場、ユーザー署名に関するすべてのリスクを排除することはできません。

結論

スマートコントラクトセキュリティとは、技術的なバグ、安全でない設計、不正なデータ、脆弱な権限、アップグレードの失敗、現実の攻撃者行動からブロックチェーンコントラクトを保護する包括的な分野です。

スマートコントラクトは、ミスの後に取り消せる余地が非常に限られた状態で、価値ある暗号資産を保有・移動できるため重要です。

強力なセキュリティは脅威モデリングから始まり、安全なコーディング、テスト、ファジング、形式検証、監査、安全なデプロイ、監視、バグバウンティ、インシデント対応を通じて継続します。

主要なリスク領域には、アクセス制御、リエントランシー、オラクル操作、ビジネスロジックのミス、未チェックの外部呼び出し、算術エラー、フラッシュローンに関する前提、安全でない乱数、サービス拒否、プロキシのアップグレード性があります。

開発者は、1つのツールや1回の監査に依存するのではなく、スマートコントラクトを重大なリスクを伴うシステムとして扱い、多層防御を使用すべきです。

ユーザーは、検証済みコード、監査、人気は有用なシグナルですが、安全性の保証ではないことを理解すべきです。

コード、ガバナンス、インフラ、ユーザーインターフェース、ウォレットプロンプト、監視、緊急計画がすべて連携するとき、スマートコントラクトセキュリティは最も強くなります。

初心者にとって、スマートコントラクトセキュリティとは、資産を預ける前にブロックチェーンプログラムをより安全にすることです。

上級者にとっては、プロトコル設計、実装、検証、デプロイ、運用、ガバナンスにまたがる継続的なリスク管理プロセスです。

暗号資産用語集の文脈では、スマートコントラクトセキュリティとは、スマートコントラクトによる資金損失、ルール違反、ユーザーの危険な状態への露出、オンチェーンでの悪用を防ぐための手法と制御を意味します。

重要なポイントは、安全な暗号資産システムには継続的なレビュー、透明な制御、慎重なアップグレード、能動的な監視、慎重なユーザー行動が必要であるため、スマートコントラクトセキュリティは一度きりのチェック項目ではないということです。