Web3 スマート コントラクト セキュリティのテストと正式な検証

読み取り時間： 9 分

スカイダイビングに行くことを想像してみてください。 飛行機から飛び降りる前に、パラシュートをXNUMX回チェックしますよね？ チェックとテストは、セキュリティの不可欠な部分です。 セキュリティ関連のことを考えてください。 CCTV の設置や、学校での筆記試験の前にペンのインクをチェックするなど、その後に続くテストのメカニズムが存在する可能性があります。私たちは皆、安全対策に従っています。 関連するリスクが高いほど、より多くのことをテストします。 そして、スマート コントラクトについて話すとき、そのリスクは非常に大きくなります。 スマート コントラクトのセキュリティに関しては、油断はできません。

1. セキュリティは常に必要です。

ドアをXNUMX回またはXNUMX回ロックできることは問題ありません。 あなたが留守の間、あなたの家が強盗に遭わないと確信できますか? 強盗が家に侵入するために何をするかわからないため、できません。これは、私たちが講じるすべての安全対策にも当てはまります。 安全性を保証する完全に安全な方法はありません。 それでも、私たちが迅速に行動することで、安全である可能性が高まります。これがゲームです。 さまざまな対策を講じることで、安全である可能性を高めたいと考えています。

Web3 の世界も例外ではありません。 自分自身を救う安全な方法はありませんが、QuillAudits の経験豊富な監査人がいれば、プロトコルが安全に保護される可能性が大幅に高まり、最新のセキュリティが保証されます. web3 には、プロトコルに対していくつかのテストを行うことで、安全性を理解するのに役立つ XNUMX つの重要なメカニズムがあります。

1. スマート コントラクトのテスト
2. スマートコントラクトの正式な検証

それらを詳細に理解し、契約の弱点や脆弱性を知るのにどのように役立つかを学びましょう。

2.スマートコントラクトのテスト

経験豊富な開発者は、コードでマシンに作業を説明できます。 それでも、コードの欠陥や論理エラーのために、マシンが開発者が念頭に置いていた正確なメカニズムを描写していないことがあります。 テストは、コードのどこが失敗しているか、実行する必要があるアクションに対応させるために何ができるかを特定するのに役立つプロセスです。

スマート コントラクトのテスト 契約の詳細な分析を実行し、コードが失敗した場所と理由を見つけようとする開発サイクルのフェーズです。 ほとんどすべてのスマート コントラクトがこのフェーズを経ます。 スマート コントラクトのテストを行う方法は XNUMX つあります。 それらを調べてみましょう。

2.1 自動化

名前が示すように、スマート コントラクトをテストするこの方法は、スクリプト化されたテストを実行するために使用されます。 これには、繰り返しテストを実行してスマート コントラクトの脆弱性や欠陥を見つける自動化されたソフトウェアが含まれます。 これらの自動テスト ツールは、テスト データと期待される結果を使用して構成できます。 次に、実際の結果と期待される結果を比較して、契約が適切に機能しているかどうかを確認します。 自動テストは、さらに XNUMX つのカテゴリに分類できます。

2.1.1. 機能テスト

2 つの数値 a と b を取得し、両方の数値の加算を返すプログラムを作成するとします。 そのプログラムをチェックするには、8 と 10 を指定し、期待される結果が 10 になるようにフィードします。プログラムを実行すると、XNUMX も返されるはずです。そうであれば、問題なく動作し、コードは正しいですが、そうでない場合は、コードに何らかのエラーがあります。 

機能テストでは、特定の条件でコントラクトがどのように動作するかを理解する必要があります。 選択した値で計算を実行し、返された出力を比較することでテストできます。 機能テストには XNUMX つのクラスがあります。

1. 単体テスト:- これは、スマート コントラクトの個々のコンポーネントの正確性をテストすることを扱います。 断定的であるか、変数に関するステートメントが必要です。

2. 統合 テキストNG: – これらは、いくつかの個々のコンポーネントを一緒にテストすることを扱います。 統合テストは、単体テストよりも階層が高いレベルです。 これは、他のスマート コントラクトの一部である可能性のある、さまざまな機能の相互作用から生じるエラーを特定するのに役立ちます。

3. エントルピー テキストNG: – これは、階層の最上位です。 ここでは、契約全体を XNUMX つの完全に統合されたシステムとしてテストし、ニーズどおりに機能するかどうかを確認します。 これはユーザーの観点から行われます。これを行う最善の方法は、テストネットにデプロイすることです。

2.1.2.静的分析

静的解析は、プログラムを実行しなくても実行できます。 これには、実行前のスマート コントラクトのソース コードまたはバイトコードの分析が含まれます。 したがって、その名前が示すように、静的分析により、いくつかの一般的な脆弱性が検出される可能性があります。

2.1.3. 動的解析

静的分析とは異なり、動的分析はスマート コントラクトの実行時に実行され、コードの問題を特定します。 動的コード アナライザーは、コントラクトの実行状態を監視し、脆弱性とプロパティ違反の詳細なレポートを生成します。 ファジングは、動的分析に分類されます。 ファジングは、意図しないコード実行を引き起こすために、正しくない、または悪意のある入力をフィードします。

2.2マニュアル

名前が示すように、このスマート コントラクト テストの方法には、人間の開発者との定期的なやり取りが含まれます。 開発者がコード行を確認するコード監査は、スマート コントラクト テストの手動モードに分類されます。

手動モードは、かなりの時間、スキル、お金、および労力を必要とします。 それでも、自動テストでは見過ごされる可能性のある脆弱性を特定できるため、多くの場合、結果には価値があります。 手動テストには XNUMX つの重要なタイプがあります。

2.2.1 コード監査:- 

安全対策が適切に機能しているかどうかをテストする最善の方法は、それを壊してみるということです。 たとえば、車のロックが正常に機能するかどうかを確認したい場合は、壊してみてください。 熟練した車泥棒なら簡単に私の車に侵入できると思うかもしれません。 私はそうではないかもしれません。解決策は、侵入に長けている人を雇って、あなたを導いてもらうことです!

 はい、QuillAudits について話しています。 私たちはあなたを導くことができる熟練した監査人のチームです。 コード監査には、攻撃者がソース コードの潜在的な脆弱性をすべて見つけるという考え方が必要です。 コード監査は、潜在的な脆弱性と欠陥を発見するためのスマート コントラクトのコードの詳細な評価です。

2.2.2 バグ報奨金:-

ソース コードにセキュリティ上の欠陥がある可能性があり (ほとんどの場合)、それらを見つけることができない場合は、報酬システムを作成して、この作業をフリーランサーにアウトソーシングできます。 これは、スマート コントラクトをハッキングできる人に報酬を発表するようなものです。 これを行うことで、スマート コントラクトに存在する脆弱性について学び、それをより適切に保護し、ユーザーを損失から救うことができます。

3.スマートコントラクトの正式な検証

正式な検証は、正式な仕様に基づいて契約の正確性を評価するプロセスです。 これは、正式な検証が、コードが意図したとおりに動作するかどうかを評価することを意味します。 正式な検証では、プログラムを指定、設計、および検証するための正式な方法を使用します。

3.1 正式仕様とは?

スマート コントラクトのコンテキストでは、正式な仕様とは、考えられるあらゆる状況下で同じままでなければならないプロパティを指します。 これらは、コントラクトの実行に関する論理的なアサーションを変更して表すことができないため、「不変」プロパティです。

形式仕様書は、形式言語で書かれたステートメントの集まりです。 仕様はさまざまなプロパティをカバーし、コントラクトのプロパティが他の状況でどのように動作するかを説明します。 コントラクトが実行中に不変変数またはプロパティの変更に失敗した場合、プロパティの悪用につながる可能性があり、莫大な損失につながる可能性があるため、正式な仕様は重要です。

スマート コントラクトが仕様を満たしているかどうか、または予期しない動作をしているかどうかを判断するのに役立ちます。 フォーマル検証には、仕様、モデル、検証エンジンの XNUMX つのコンポーネントがあります。

3.1.1仕様

仕様は、スマート コントラクトの要件を明確かつ明確に完全に記述したものです。 契約で何をすべきか、何をすべきでないかを説明する必要があります。 以下は、XNUMX つの数値を加算する単純なスマート コントラクトの仕様の例です。

// Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
// Implementation details are not relevant to the specification
// …
}

3.1.2モデル

モデルは、その動作を推論するために使用できるスマート コントラクトを正式に表します。 スマート コントラクトの一般的なモデルの XNUMX つは、Solidity プログラミング言語です。 上記の add 関数のモデル例を次に示します。

// Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
return a + b;
}

3.1.3 検証エンジン

検証エンジンは、モデルを分析し、特定の仕様に関するその正確性を検証できるツールです。 スマート コントラクトで使用できる検証エンジンには、次のようなものがあります。

ミスリル: Solidity スマート コントラクトの幅広いセキュリティ脆弱性を検出できるオープンソースのシンボリック実行ツール。

リミックス IDE: スマート コントラクトの正当性を検証できる正式な検証ツールを含む統合開発環境。

チェルトラ証明者: 自動化された数学的推論を使用してスマート コントラクトの正確性を検証できる商用ツール。 以下は、正式な検証を使用して、Certora Prover を使用してスマート コントラクトの正確性を検証する方法の例です。

pragma solidity 0.7.6; // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint)
function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function test_add(uint a, uint b) public pure returns (bool) {
uint expected = a + b;
uint actual = add(a, b);
return expected == actual;
} // Verification: Verify the correctness of the add function contract TestAdd {
function test_add(uint a, uint b) public view returns (bool) {
return CertoraProver.verify(test_add, a, b);
}
}

上記の例では、add 関数のモデル、関数の仕様、および関数の正確性を検証できる検証エンジン (Certora Prover) を含む Solidity スマート コントラクトを定義します。 関数の正確性を検証するために使用できるテスト関数 (test_add) も定義します。

3.2 テストと正式な検証

説明したように、テストされていないデータについては言うことができないため、テストは不足している入力データ ボットに対して期待される結果を返します。 考えられるすべての入力でそれをチェックすることは事実上不可能です。 したがって、その「機能の正しさ」については確信が持てません。 そこで正式な検証の出番です。正式な検証方法では、厳密な数学的手法を使用して、ソフトウェアまたはスマート コントラクトを指定および検証します。

3.3 フォーマル検証のテクニック

フォーマル検証には、強化するための幅広い技術があります スマートコントラクトセキュリティ. ブログのこの部分では、いくつかを個別に説明します。

3.3.1 モデルチェック

正式な仕様とは何かについて説明したので、この正式な検証手法でスマート コントラクトをその仕様に照らしてチェックします。 これらのスマート コントラクトは状態遷移システムとして表され、プロパティは時相論理を使用して定義されます。 

この手法は主に、時間の経過に伴うスマート コントラクトの動作を表す一時的なプロパティを評価するために使用されます。 アクセス制御プロパティ (管理呼び出し 自己破壊) は形式論理として書き下すことができます。 次に、モデル検査アルゴリズムは、コントラクトがこの正式な検証を満たしているかどうかを検証できます。

モデル チェックでは、状態空間探索と呼ばれる手法を使用します。これは基本的に、スマート コントラクトが取り得るすべての状態を試してから、そのいずれかがプロパティ違反につながるかどうかを確認することです。 ただし、これは無限に多くの状態につながる可能性があります。 したがって、モデル チェッカーは抽象化手法に依存して、スマート コントラクトの効率的な分析を可能にします。

3.3.2 定理の証明

定理の証明は、プログラムの正しさに関する数学的推論に関するものです。 契約のシステムと仕様の論理的な印象を作成し、ステートメント間の「論理的な同等性」を検証します。 論理的等価性は、ステートメント B が真である場合に限り、ステートメント A が真であるという数学的関係です。

モデル チェック手法で学んだように、契約を有限状態の遷移システムとしてモデル化します。 定理証明は、無限状態システムの解析を処理できます。 ただし、自動化された定理証明者は、論理的な問題が決定可能かどうかを常に知ることはできません。 したがって、正しさの証明を導き出す際に定理証明者を導くために、人間の支援が必要になることがよくあります。

4. まとめ

テストと正式な検証は、どちらもスマート コントラクト開発の不可欠な部分です。 これらは、スマート コントラクトを安全にするために使用される方法であり、コントラクトをデプロイできるようにするのに役立ちます。 しかし、ご存知のように、セキュリティだけでは決して十分ではありません。 適切なテストが行​​われていないという理由だけで、多くのスマート コントラクトがハッキングされていました。 今まで以上に web3 コミュニティはより安全なプロトコルを必要としています。 

QuillAudits の使命は、プロトコルの保護を支援することです。 熟練した経験豊富なチームにより、脆弱性が 3 つでも見過ごされることはありません。 私たちの Web サイトにアクセスして、WebXNUMX プロジェクトを保護してください!

28 ビュー

• SEO を活用したコンテンツと PR 配信。 今日増幅されます。
• Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 こちらからアクセスしてください。
• 情報源： https://blog.quillhash.com/2023/02/16/testing-and-formal-verification/