スマートコントラクト監査を成功させるための準備方法

ブロックチェーンとDeFiは予測不可能な場合があります。そのため、スマートコントラクト監査 は単なる技術的なマイルストーンではなく、プロジェクトの成否を左右する重要なステップです。

監査により、コードが安全で機能的であり、ユーザーや評判をリスクにさらす可能性のある厄介なバグがないことが保証されます。しかし、ここで重要なのは、監査人にコードを投げつけて魔法が起こることを期待することはできないということです。穏やかでありながら効果的な監査は、あなた側のしっかりとした準備から始まります。

スマートコントラクトを成功させる監査のために準備する方法を正確に説明しましょう。

コードとドキュメントの整理

シンプルに、クリーンに保つ

まず、特に監査人を含むすべての人にとって作業を容易にするようにコードを構造化します。このように考えてください:乱雑で構造化されていないコードは、乱雑なキッチンのようなものです。誰もそこで料理したくありません!

• camelCase、snake_caseなど、チームが好む一貫した命名規則を使用し、全体を通して一貫性を保つ;
• コードをより小さな論理的なモジュールまたはコントラクトに分割する;
• 必要に応じてコードにコメントを付ける;簡潔な説明を提供することは、他の人があなたのロジックを理解するのに大いに役立ちます。

コードを整理することは、監査を容易にするだけでなく プロジェクトを真剣に受け止めていることを示すことになります。

ドキュメントを充実させる

優れたドキュメントは、監査人(そしてあなた)に多くの頭痛の種を省くことができます。含めるべき内容は次のとおりです:

• プロジェクト概要:スマートコントラクトが何をするのか、そしてそれがどのように全体像に適合するのかを説明する;
• アーキテクチャ図:簡単なスケッチまたは図は、監査人がシステムのフローを視覚化するのに役立ちます;
• 機能の説明:各機能は、その入力、出力、目的を概説し、明確に説明する必要があります;
• デプロイ手順:監査人が手間なくデプロイおよびテストできるように、ステップバイステップの詳細を提供します。

明確なドキュメントは時間の節約になり、監査コストを大幅に削減できることを覚えておいてください。

監査前に避けるべき一般的な落とし穴

コードを引き渡す前に、監査中にプロジェクトをつまずかせる最大の警告サインのいくつかを知っておく必要があります。

リエントランシー脆弱性

この古典的な悪用により、攻撃者は状態を更新する前にコントラクトの機能を繰り返し呼び出すことができます。注意しないと、「ラグプル」と言うよりも早くコントラクトの資金を使い果たす可能性があります。そのため、次のことを確認してください:

• 外部呼び出しを行う前に、常にコントラクトの状態を更新する;
• OpenZeppelinのReentrancyGuardのようなリエントランシーガードを使用して、コントラクトを安全に保ちます。

整数オーバーフローとアンダーフロー

スマートコントラクトでは数学エラーが壊滅的である可能性があります;誰かが自分自身に無制限のトークンを送信できると想像してください!これを防ぐには:

• 組み込みのオーバーフローチェックを備えたSolidity 0.8.0以降を使用する;
• または、コントラクトの計算を保護するために安全な数学ライブラリを使用します。

チェックされていない外部呼び出し

外部コントラクトを呼び出すときは、最善を期待するだけでなく、結果を確認してください!

• 外部呼び出し(call、delegatecallなど)の成功または失敗を常に確認する;
• 予期しないエラーを処理するか、脆弱性を回避するために適切にロジックを元に戻します。

不十分なアクセス制御

これは重要です:誰が何をできるのか?コントラクトの機能が適切に制限されていない場合、誰でもトークンを発行したり、所有権を変更したり、さらに悪いことができます。そのため:

• ロールベースのアクセス制御と徹底的な権限チェックを使用する;
• msg.senderのみに依存しないでください。誰がアクセスできるかについて意図的かつ明示的にしてください。

提出前のテストと品質保証

優れたテストはあなたの秘密兵器です。監査人よりもずっと前に隠れたバグを発見できるからです。

単体テスト

小さく始めましょう。単体テストは、コントラクト内のすべての機能をカバーし、通常のケース、エッジケース、エラーケースをチェックする必要があります。

• 徹底的な単体テストにはHardhatやTruffleのようなフレームワークを使用する;
• 「ハッピーパス」で止まらないでください;代わりに、予期しない入力や悪意のある入力もテストしてください。

統合テスト

コントラクトは泡の中に存在しません。スタックの残りの部分とうまく連携することを確認してください。

• 異なるモジュールがどのように相互作用するか、およびコントラクトが実際のシナリオでどのように動作するかをテストする;
• 実世界の状況をシミュレートする必要がある場合は、メインネットフォークを使用します。

自動化ツール

静的および動的分析ツールを活用します:

• Slither:一般的な脆弱性とコード最適化の提案を見つける;
• MythXまたはOyente:監査人の前にセキュリティリスクを検出する自動化ツール。

コードカバレッジ

テストができるだけ多くのコードをカバーすることが望ましいので、高いコードカバレッジを目指してください。90%以上に到達できれば素晴らしいです。これにより、あなたと監査人は、コントラクトが誰も驚かせないという確信を持つことができます。

監査人と効果的に協力する

コードが整理され、テストされたら、監査人を参加させる時です。そのコラボレーションをスムーズかつ効果的にする方法は次のとおりです。

コードを凍結する

監査が始まったら、コントラクトを微調整したいという誘惑に抵抗してください。あなたが行うすべての変更は、監査の一部を無効にし、混乱を引き起こす可能性があります。

• 監査が始まる前に最終リリースバージョンにタグを付ける;
• プロセス中に大幅な変更を避ける;緊急の事態が発生した場合は、最初に監査人と話すのが最善です。

透明性を保ち、オープンにする

監査人は心を読む人ではないので、より多くのコンテキストを提供するほど良いです。

• 完全なドキュメント、デプロイスクリプト、テストケースを提供する;
• 質問に答えたり、明白ではないかもしれないロジックの一部を説明する準備をしてください。

監査報告書をレビューする

最終的な監査報告書を受け取ったとき、年末の成績表のように扱うべきではありません。代わりに、それに取り組んでください!

• 各調査結果の深刻度とプロジェクトへの影響を理解する;
• できるだけ早く脆弱性を修正するためにチームと協力する;
• 調査結果が明確でない、または疑わしいと思われる場合は、監査人に説明を求めてください。

「完璧な」レポートを取得することよりもはるかに重要なのは、優れた監査とは、学習、改善、そして誇りに思えるものを提供することです。

最後に

成功するスマートコントラクト監査はあなたから始まります。コードが整理され、テストされ、十分に文書化されているほど、プロセスはスムーズになります。監査を障害と考えないでください;ユーザーの信頼とプロジェクトの信頼性を構築する上での重要なパートナーと見なしてください。

プロジェクトを公開する準備ができたら、徹底的な監査が安全で成功したローンチのための最善の策です。したがって、時間をかけてコントラクトを準備し、監査人と協力し、永続するものを構築してください!