DeFi 契約監査の「ルーチン」を振り返ってみると、あなたは罠に陥っていませんか?

DeFi プロジェクトが正式に展開される前に、契約のセキュリティ監査では、プロジェクトのコード仕様、脆弱性、ビジネスロジックのグローバルチェックを実行できるだけではありません。同時に、プロジェクト監査は、投資市場におけるプロジェクト当事者のイメージを形成する上で一定の役割を果たします。

市場投資家がプロジェクトを選択する際、プロジェクト当事者が契約監査の経験を持ち、監査人や監査報告書などの情報を公開していれば、投資の信頼性は間違いなく大幅に向上するでしょう。さらに、プロジェクト関係者の完璧な安全意識も、目に見えない形でプロジェクトに付加価値を与えることになります。

同時に、DeFiプロジェクトの関係者は、運営期間中にセキュリティ監査会社との長期的なビジネス協力を維持する必要があり、これはセキュリティ管理とビジネス拡大の両方に大きな利益をもたらすでしょう。結局のところ、プロジェクトの長期的な発展において、段階的なセキュリティ監査メカニズムは、全体的および局所的なリスク問題をタイムリーに発見し、効果的に解決するのに役立ちます。

では、DeFi 契約監査の主なプロセス、内容、特徴は何でしょうか。また、それらの「ルーチン」とは何でしょうか。

ルーティン1：早期段階の「脈診」

DeFiプロジェクト当事者と契約監査協力関係を締結した後、アーキテクチャ、ビジネス設計などを含むプロジェクトの全体的な状況を理解した上で、関連するプロジェクト監査経験を持つセキュリティテストチームが割り当てられ、特別なサービスを提供します。同時に、プロジェクトテストの範囲とそれに応じた需要の焦点が明確になります。初期段階で「脈を測る」ことをしっかり行いましょう。主な内容は次のとおりです。

1. DeFiプロジェクト当事者は、監査に必要な真正かつ有効な技術、コード、文書およびその他の情報を提供するものとします。

2. 正式にテスト段階に入る前に、セキュリティチームは提供された資料の包括的な評価を実施してサイクルを決定します。

3. 対象モジュール、ローカルコード、包括的なセキュリティ監査などを含むテストサービスの範囲を決定します。

4. ソースコード、アプリケーションプログラム、ファイル情報、テスト環境の最終確認など、関連する要件を完了します。

DeFi プロジェクト契約のコード標準化、セキュリティ、ビジネスロジックについて厳格なセキュリティ監査を実施するために、テストがクリアされた後、契約監査を処理する従来の方法は次のとおりです。

形式検証
静的解析
動的解析
典型的なケース
手動レビュー

ルーチン2: 形式検証

形式手法は、安全で信頼できるソフトウェアを実現するための最も信頼できる手段です。数学記号システムを使用して、ソフトウェアの正確性とセキュリティの厳密な定義と正式な証明を提供します。その中でも厳密な定義は「形式仕様」と呼ばれ、ソフトウェアの機能や特性を明確かつ簡潔に記述した論理的な表現です。

契約監査では、形式手法により定性的な要件属性を使用して、プログラムに特定のセキュリティ脆弱性がないことが証明されます。一方、従来のテスト方法では、選択された入力セットに対してコードが期待どおりに実行されるかどうかをチェックして、プログラムにセキュリティ上の脆弱性があるかどうかを示しますが、同じ種類のセキュリティ上の脆弱性が存在しないことを証明することはできません。

さらに、従来のテスト方法では、まれなシナリオや悪意を持って構築されたシナリオで発生するエラーや、連続して発生する多数の「あり得ないイベント」によって引き起こされるエラーを簡単に見逃してしまう可能性があります。ただし、形式手法では、コードの意図を明確にし、入力空間を完全にカバーすることで、これらの微妙なエラーを発見できるため、プログラムのセキュリティと信頼性が向上します。

成都聯安の創設者であり、長年形式検証研究の専門家である楊霞教授は、次のように述べた。

「従来の検証方法では、考えられるすべての状況を網羅することはできませんが、形式検証ではそれが可能です。この方法は、スマートコントラクトの脆弱性検出に最も信頼性が高く、効果的です。」

成都聯安のBeosin-VaaSワンクリックスマートコントラクト自動形式検証ツールは、イーサリアムスマートコントラクトのセキュリティテスト用に開発されたカスタマイズツールであり、リスクを含むコードの場所を正確に特定し、リスクの原因を指摘することができます。スマートコントラクトの一般的なセキュリティ脆弱性を 97% 以上の精度で効果的に検出し、スマートコントラクトコードに「軍事レベル」のセキュリティ検証を提供します。 ”

ルーチン 3: コード標準監査

コード標準監査の主なテスト項目は次のとおりです。

コンパイラのバージョンの問題により、さまざまな既知のセキュリティ問題が発生する可能性があります。開発者は、契約コードが最新のコンパイラバージョンを使用していることをコード内で指定し、コンパイラの警告を排除する必要があります。

同時に、Solidity スマートコントラクト開発言語は急速に反復されており、throw、years などの一部のキーワードは新しいバージョンのコンパイラによって非推奨になっています。発生する可能性のある隠れた危険性を排除するために、現在のコンパイラバージョンで非推奨になっているキーワードを無効にする必要があります。

スマートコントラクトでは、冗長なコードによってコードの可読性が低下し、コントラクトを展開するためにより多くのガスが必要になる場合があります。したがって、冗長なコードを識別して削除する必要があります。さらに、SafeMath ライブラリの関数がコントラクト内の数学演算に正しく使用されているかどうかを厳密にチェックする必要があります。

Solidity は状態回復例外を使用してエラーを処理します。状態回復例外は、現在の呼び出しとそのすべての子で状態に加えられたすべての変更を元に戻し、呼び出し元にエラーのフラグを立てます。

assert 関数と require 関数を使用すると、条件をチェックし、条件が満たされない場合は例外をスローすることができます。 assert 関数は、内部エラーをテストし、変数以外のものをチェックする場合にのみ使用してください。 require 関数は、入力変数またはコントラクト状態変数が条件を満たしているかどうかなどの条件の有効性を確認したり、外部コントラクト呼び出しの戻り値を検証したりするために使用されます。

Ethereum 仮想マシンは、コントラクトコードを実行するためにガスを消費します。ガスが不足すると、コード実行によってガス不足例外がスローされ、すべての状態変更がキャンセルされます。契約開発者は、ガス不足による関数実行の失敗を回避するために、コードのガス消費を制御する必要があります。

さらに、コントラクト機能の可視性が設計要件を満たしているかどうか、現在のコントラクトでフォールバック機能が正しく使用されているかどうかを厳密にチェックする必要があります。

秘訣4: DeFiセキュリティ脆弱性監査

現在、ビジネスロジックの脆弱性は DeFi プロジェクトで最も一般的です。プロジェクトのビジネスロジックの設計が不正確なため、特定の状況下ではプロジェクトの内部に不均衡が生じる可能性が非常に高くなります。

DeFi プロジェクトはブロックチェーンのスマートコントラクトに基づいて開発されており、従来の金融システムを超えた多くの機能を備えていることに留意する必要があります。

単一のトランザクションで複数の内部トランザクションを開始でき、失敗した場合はロールバックできます。
デフレトークン
契約コードは変更できません

同時に、契約権限エラー、つまり契約内の機能の可視性変更におけるエラーも監査でよく見られます。通常、これは呼び出し元とパラメータが効果的に検証されていないために発生し、その結果、悪意のあるユーザーによって関数が呼び出され、大きな損失が発生します。

従来のセキュリティ問題と同様に、不適切な権限設定や無効なセキュリティチェックは、システムに多大なリスクをもたらします。しかし、違いは、スマートコントラクトの不変性により、そのような問題が発見されたとしても、効果的に修正できない可能性があるということです。

さらに、再入脆弱性も監査の焦点となります。具体的には、コントラクトが呼び出しを開始すると、攻撃者はコントラクト呼び出しの特性を利用して関数を繰り返し呼び出し、コントラクトの予想される実行順序にエラーを引き起こし、ターゲットアカウントの資産を盗むことができます。

監査中にコーディングエラーも頻繁に発生します。これは主に、開発者のミスによって発生したコーディングエラーが原因です。よくある例としては、単位の誤り、精度による乗算の忘れ、& の誤った使用などがあります。 YAM 脆弱性インシデントでは、図に示すように、コードが弾性調整リベースを実行するときに精度を乗算し忘れていました。

プロジェクト事業では、コードと脆弱性の徹底的な検出を確保するとともに、DeFiプロジェクトに関与するトークンの基本情報の検査、トークン標準に関連する機能の確認、特にトークンの鋳造、破棄、所有者の変更、その他の特別な権限のレビューとリスク分析など、ビジネスロジックと実装に関する関連監査も実施しています。

多くのプロジェクトにはプロキシ転送のロジックがあります。このロジックを扱う場合、多くのプロジェクト関係者は、次の図に示すように、プロジェクト関係者の契約にトークンの最大値を承認するようにユーザーに直接求めます。

このようにして、契約にはすべてのユーザー資金を譲渡する権利があります。さらに、二重承認の問題もあります。プロジェクト Web サイトが認証を実行する場合、契約アドレスへの認証と外部アドレスへの認証の 2 つの認証が開始されます。ユーザーがこれに注意しないと、大きな経済的リスクに直面することになります。

ルーチン 5: 監査レポート

契約監査は、最終的には DeFi プロジェクトにおける資金のセキュリティに役立ちますが、この点に関する多くの問題は不適切な機能とアルゴリズムに関連しています。そのため、契約監査とは、財務リスクを引き起こす可能性のある内容、つまり、早急に修正する必要があるコード、抜け穴、ロジックなどの潜在的なリスクや問題点を指摘することです。

監査時間、期間、監査人などの基本情報に加えて、監査レポートには、プロジェクトに対する投資警告リマインダーも含まれます。監査レポートの中心的な内容は、検査されたスマートコントラクトの監査結果を、設計やコード実装などの複数の側面と次元で反映することです。同時に、レポートでは発見されたさまざまなリスク問題を指摘し、プロジェクト関係者に修復を通知します。

監査レポートを通じて、さまざまなレベルとレイヤーでの潜在的な攻撃や脆弱性など、契約のリスク要素が明確に示されます。しかし、安全性監査報告書の目を引く「合格」という言葉が、投資家が投資判断を下す唯一の根拠となるべきではない。