スマートコントラクトを保護するにはどうすればよいですか? (セキュリティチェックリスト)

コードの監査と正式な検証

1. 複数の独立したセキュリティ会社と協力して、展開前に手動でコード レビューを実施します。

2. Certora や MythX などの正式な検証ツールを適用して、重要な不変条件の正しさを数学的に証明します。

3. すべての外部呼び出しが、チェック効果相互作用パターンを使用して再入ベクトルに対して検証されていることを確認します。

4. OpenZeppelin コントラクトを含むすべてのインポートされたライブラリを監査して、バージョン固有の脆弱性がないか確認します。

5. 各コミットを対応する検証レポートおよびタイムスタンプにリンクする不変の監査証跡を維持します。

アクセス制御と権限管理

1. 監査済みの標準からの Ownable パターンまたは AccessControl パターンを使用して、ロールベースのアクセス制御を実装します。

2. 管理機能とユーザー向けロジックを厳密に分離し、パブリック エントリ ポイントでの特権操作を禁止します。

3. 資金の一時停止、アップグレード、引き出しなどの機密性の高い操作には複数署名の承認を必要とします。

4. 管理キーを定期的にローテーションし、GitHub リポジトリやプレーンテキスト ファイルではなく、ハードウェア セキュリティ モジュールを使用してオフラインで保存します。

5. 呼び出し元、タイムスタンプ、ターゲットの役割、前の所有者などの完全なコンテキストを含めて、オンチェーン上のすべての権限変更をログに記録します。

ガスの最適化と実行時の安全対策

1. 実行中にガス切れエラーを引き起こす可能性のある無制限のループを回避します。ページネーションまたは上限付き反復を使用します。

2. 外部呼び出しに明示的なガス制限を挿入して、無限フォールバック ループによる DoS を防止します。

3. スタック オーバーフローやサイレント トランケーションを回避するために、配列または文字列を処理する前に入力の長さと範囲を検証します。

4. ユーザーが指定した値を含むすべての算術演算に対して、SafeMath または Solidity 0.8+ の組み込みオーバーフロー チェックを使用します。

5. 本番エラー メッセージで機密ロジックを公開せずにデバッグを支援するために、元に戻す文字列を有効にしてデプロイします。

アップグレード可能性とプロキシ パターン

1. アップグレード ロジックをビジネス ロジックから完全に切り離す必要がある場合にのみ、透過的プロキシを優先します。

2. 不正なアップグレードを防ぐために、プロキシ管理者アドレスをプロキシ自体ではなく、別の強化された契約に保存します。

3. クォーラム強制投票期間を持つタイムロック DAO によって管理されない限り、メインネットの起動後にアップグレード機能を凍結します。

4. 新しいロジックを展開する前に、slither または cretic-tools を使用して実装間のストレージ レイアウトの互換性を確認します。

5. 明示的にホワイトリストに登録され、ログに記録されていない限り、たとえアップグレード機能内であっても、任意のアドレスへの自己破壊またはデリゲートコールを決して許可しないでください。

監視、アラート、インシデント対応

1. Tenderly または BlockSec を介してリアルタイム トランザクション トレースを統合し、異常な状態遷移を検出します。

2. 突然の残高の低下、予期しない所有権の移転、または繰り返しの取り消しなどの重大な状況に備えて、オンチェーン イベント ウォッチャーを設定します。

3. 公開 Slack や Discord グループではなく、暗号化されたチャネルを通じて指定された応答者にアラートをルーティングします。

4. 侵害が確認されてから数秒以内にブロードキャストできるように、事前に署名された緊急一時停止トランザクションを維持します。

5. ガバナンスマルチシグによって署名された IPFS バックアップのマークルルートを使用して、すべての履歴状態スナップショットを毎週アーカイブします。

よくある質問

Q: Slither や Mythril などの自動スキャナーだけに頼ることはできますか?自動ツールは既知のパターンを捕捉しますが、トークンノミクスまたはインタラクション モデルに固有のロジック上の欠陥を見逃します。人間によるレビューは引き続き不可欠です。

Q: GitHub の ERC-20 テンプレートを変更せずに使用しても安全ですか?いいえ。一般的なテンプレートの多くには、コンパイラのバージョン、修飾子の欠落、または安全でない転送セマンティクスに関する古い前提条件が含まれています。各行にはコンテキストの検証が必要です。

Q: 自己破壊機能を備えた契約を展開する必要がありますか?自己破壊は取り返しのつかないリスクをもたらします。テストに必要な場合は、コンパイル時フラグまたは条件付きコンパイルを使用して、メインネットの起動前に永続的に無効にします。

Q: ライブ契約の管理キーはどれくらいの頻度でローテーションする必要がありますか?秘密キーはスマート コントラクトを直接管理しないため、管理キーのローテーションは展開後に適用できません。代わりに、ガバナンス署名者をローテーションし、タイムロックされた提案を通じてマルチシグしきい値を更新します。