スマートコントラクトの形式検証
スマート契約分散化され、信頼性があり、堅牢なアプリケーションを作成し、新しいユースケースを導入し、ユーザーに価値を提供することが可能になっています。スマートコントラクトは大量の価値を取り扱うため、セキュリティは開発者にとって重要な考慮事項です。
フォーマル検証は、改善のために推奨される技術の1つですスマートコントラクトセキュリティ.形式的検証は、形式手法
プログラムの指定、設計、および検証に使用され、長年にわたって重要なハードウェアおよびソフトウェアシステムの正確性を確保するために使用されています。
スマートコントラクトに実装された場合、形式的検証は契約のビジネスロジックが事前に定義された仕様を満たすことを証明できます。テストなどの契約コードの正確性を評価する他の方法と比較して、形式的検証はスマートコントラクトが機能的に正しいことを強く保証します。
フォーマル検証とは何ですか？
形式検証とは、形式仕様に関連するシステムの正確さを評価するプロセスを指します。より簡単に言えば、形式検証によってシステムの振る舞いが特定の要件を満たしているかどうかを確認することができます（つまり、私たちの望む動作をしているかどうかをチェックできます）。
システム（この場合はスマートコントラクト）の期待される動作は形式モデリングを使用して記述され、仕様言語により形式的なプロパティの作成が可能になります。形式検証技術は、契約の実装がその仕様に準拠していることを検証し、前者の正確性の数学的証明を導出できます。契約がその仕様を満たす場合、「機能的に正しい」、「設計により正しい」、または「構築により正しい」と記述されます。
形式モデルとは何ですか？
コンピューターサイエンスでは、形式モデル
は、計算プロセスの数学的記述です。プログラムは数学関数 (方程式) に抽象化され、関数への出力が入力に対してどのように計算されるかをモデルで記述します。
形式モデルは、プログラムの動作の解析が評価される抽象化レベルを提供します。形式モデルの存在により、対象モデルの望ましい特性を記述する形式仕様の作成が可能となります。
形式的検証のためにスマートコントラクトのモデリングにはさまざまな技術が使用されています。例えば、一部のモデルはスマートコントラクトの高レベルな動作について推論するために使用されます。これらのモデリング技術は、スマートコントラクトをブラックボックスの観点で適用し、入力を受け入れ、その入力に基づいて計算を実行するシステムとして見ています。
ハイレベルモデルは、スマートコントラクトと外部エージェント（外部所有アカウント（EOA）、契約アカウント、およびブロックチェーン環境など）の関係に焦点を当てています。このようなモデルは、特定のユーザーの相互作用に応じて契約がどのように振る舞うかを指定するプロパティを定義するために有用です。
逆に、他の形式モデルはスマートコントラクトの低レベルの動作に焦点を当てています。高レベルのモデルは契約の機能について推論するのに役立つかもしれませんが、実装の内部動作の詳細を捉え損ねる可能性があります。低レベルのモデルはプログラムの分析に白箱の視点を適用し、プログラムトレースなどのスマートコントラクトアプリケーションの低レベル表現に依存しています。制御フローグラフ
契約の実行に関連するプロパティについて推論する。
低レベルモデルは、イーサリアムの実行環境（つまり、EVM低レベルのモデリング技術は、特にスマートコントラクトの重要な安全性を確立し、潜在的な脆弱性を検出する際に特に役立ちます。
形式仕様とは何ですか？
仕様は単に特定のシステムが満たす必要がある技術要件です。プログラミングでは、仕様はプログラムの実行に関する一般的な考えを表します（つまり、プログラムが行うべきこと）
スマートコントラクトのコンテキストにおいて、形式仕様はプロパティーを指し、それは契約が満たす必要がある要件の形式的な記述です。そのようなプロパティは「不変式」として記述され、契約の実行に関する論理的な主張を表し、どんな例外もなく、あらゆる可能な状況の下で真でなければなりません。
したがって、形式仕様は、スマートコントラクトの意図された実行を記述する形式言語で書かれた一連の文であると考えることができます。 仕様は契約の特性をカバーし、契約が異なる状況でどのように振る舞うかを定義します。 形式検証の目的は、スマートコントラクトがこれらの特性（不変条件）を持っているかどうか、およびこれらの特性が実行中に違反されていないかを判断することです。
スマートコントラクトの安全な実装を開発する際には、形式仕様が重要です。不変条件を実装しない契約や、実行中にそのプロパティが違反される契約は、機能性を損なう可能性があり、悪意のある攻撃を引き起こす恐れがあります。
スマートコントラクトの形式仕様の種類
形式仕様は、プログラム実行の正確性に関する数学的推論を可能にします。形式モデルと同様に、形式仕様は、契約の実装の高レベルの特性または低レベルの動作を捉えることができます。
形式仕様は、要素を使用して導出されますプログラムロジック
, プログラムの特性について形式的な推論を可能にするもの。プログラム論理には、プログラムの期待される動作を（数学の言語で）表現する形式的な規則があります。さまざまなプログラム論理が形式仕様の作成に使用されています。到達可能性論理
そしてホーア論理
スマートコントラクトの形式仕様は、一般的に高レベルまたは低レベルの仕様として広く分類されます。 仕様がどのカテゴリに属しているかに関係なく、分析対象システムの特性を適切かつ曖昧さなく記述する必要があります。
高水準仕様
その名前が示すように、高レベル仕様（または「モデル指向仕様」とも呼ばれる）はプログラムの高レベルな動作を記述します。高レベル仕様はスマートコントラクトをモデル化します。有限状態機械
(FSM)は、操作を実行して状態を遷移できる、FSMモデルの形式的な特性を定義するために時間論理が使用されています。
は「時間的に限定された命題について推論するための規則(例えば、「私はいつも空腹である」または「私は最終的に空腹になる」)です。形式検証に適用する場合、時間論理は、ステートマシンとしてモデル化されたシステムの正しい動作に関するアサーションを述べるために使用されます。具体的には、時間論理は、スマートコントラクトが置かれる可能性のある将来の状態と、それが状態間でどのように遷移するかを記述します。
スマートコントラクトの高レベル仕様は、通常、安全性と生存性の2つの重要な時間的特性を捉えています。安全性特性は、“何も悪いことが起こらない”という考えを表し、通常は不変性を表します。安全性特性は一般的なソフトウェア要件を定義する場合があります。デッドロック
、または契約に固有の特性を表す（たとえば、関数のアクセス制御に対する不変条件、状態変数の許容値、トークンの転送条件など）。
たとえば、ERC-20トークン契約のtransfer（）またはtransferFrom（）を使用する条件をカバーするこの安全要件を取るとします。「送信者の残高が送信されるトークンの要求額よりも低くない」。この契約不変条件の自然言語の説明は、厳密に検証されるための形式（数学的）の仕様に翻訳することができます。
ライブネス特性は、「最終的に何か良いことが起こる」と主張し、契約が異なる状態を通過する能力に関係しています。ライブネス特性の例としては、「流動性」があり、これは契約が要求に応じて残高をユーザーに移転する能力を指します。この特性が違反されると、ユーザーは契約に格納されている資産を引き出すことができなくなります。これは、Parityウォレット事件
.
低レベル仕様
ハイレベル仕様は、契約の有限状態モデルを出発点とし、このモデルの所望の特性を定義します。一方、ローレベル仕様（特性指向仕様とも呼ばれる）はしばしばプログラム（スマートコントラクト）を数学的関数の集合としてモデル化し、そのようなシステムの正しい動作を記述します。
簡単に言うと、低レベルの仕様はプログラムのトレースを分析し、これらのトレースに対してスマートコントラクトのプロパティを定義しようとします。トレースとは、スマートコントラクトの状態を変更する関数実行のシーケンスを指します。したがって、低レベルの仕様は、契約の内部実行の要件を指定するのに役立ちます。
低レベルの形式仕様は、ホーアスタイルのプロパティまたは実行パス上の不変条件として与えることができます。
ホーア様式の特性
プログラムの正確性について推論するための形式的なルールセットを提供し、スマートコントラクトを含みます。ホーア様式の特性は、Hoare トリプル {P}c{Q} によって表され、ここで、c はプログラムであり、P と Q は c の状態に関する述語（つまり、事前条件と事後条件として形式的に記述されます）。
事前条件は、関数の正しい実行に必要な条件を記述する述語です。契約に呼び出すユーザーは、この条件を満たさなければなりません。事後条件は、関数が正しく実行された場合に確立される条件を記述する述語です。ユーザーは、この条件が関数に呼び出した後に真であることを期待することができます。ホーア論理の不変条件は、関数の実行によって維持される述語です（つまり、変更されない）。
ホーア様式の仕様は、部分的な正しさまたは完全な正しさを保証できます。契約関数の実装が「部分的に正しい」場合、事前条件が関数が実行される前に真である場合、および実行が終了すると、事後条件も真である。事後条件が真であることが保証されると、事前条件が関数が実行される前に真である場合、実行が終了することが保証され、それが行われると、事後条件が真であることが保証されます。
全体の正しさの証明を得ることは難しいです。というのも、いくつかの実行は終了する前に遅れるか、まったく終了しないかもしれません。 とはいえ、実行が終了するかどうかという問題は、おそらく議論の余地があると言えます。なぜなら、イーサリアムのガスメカニズムが無限プログラムループを防ぐからです（実行は成功するか、 'ガス切れ'エラーによって終了します）。
ホーア論理を使用して作成されたスマートコントラクト仕様には、契約内の関数やループの実行のために定義された事前条件、事後条件、不変式があります。事前条件には、関数への誤った入力の可能性が含まれており、事後条件には、そのような入力に対する期待される応答が記述されています（例：特定の例外をスローする）。このように、ホーアスタイルの特性は、契約実装の正確性を保証するために効果的です。
多くの形式的検証フレームワークは、関数の意味論的正確性を証明するためにホーア様式の仕様を使用しています。また、Solidityのrequireおよびassert文を使用して、契約コードに直接ホーア様式のプロパティ（アサーションとして）を追加することも可能です。
requireステートメントは前提条件または不変条件を表し、通常はユーザー入力を検証するために使用されますが、assertは安全性に必要な事後条件を捕捉します。例えば、関数の適切なアクセス制御（安全性プロパティの一例）は、呼び出し元アカウントの識別に関する前提条件チェックとしてrequireを使用することで達成できます。同様に、契約の状態変数の許容値に関する不変条件（例：流通中のトークンの総数）は、assertを使用して、関数の実行後の契約の状態を確認することで侵害から保護することができます。
トレースレベルのプロパティ
トレースベースの仕様は、契約を異なる状態に移行させる操作と、これらの操作間の関係を記述します。前述のように、トレースは、契約の状態を特定の方法で変更する操作のシーケンスです。
このアプローチは、一部の事前定義された状態（状態変数によって記述される）と事前定義された遷移のセット（契約関数によって記述される）を持つスマートコントラクトのモデルに依存しています。さらに、制御フローグラフ
（CFG）は、プログラムの実行フローのグラフィカル表現であり、契約の操作的意味論を記述するためによく使用されます。ここでは、各トレースが制御フローグラフ上のパスとして表されます。
主に、トレースレベルの仕様はスマートコントラクト内部実行パターンについて推論するために使用されます。トレースレベルの仕様を作成することで、スマートコントラクトの許容される実行パス（つまり、状態遷移）を主張します。シンボリック実行などの技術を使用して、形式的に実行が形式モデルで定義されていないパスに従わないことを形式的に検証できます。
Let’s use an example of a DAOトレースレベルのプロパティを記述するための一部の公開関数を持つ契約。ここでは、DAO契約がユーザーが次の操作を行うことを許可していると仮定します。
- 入金する
- 資金を預けた後に提案に投票する
- 提案に投票しない場合は払い戻しを請求します
例として、トレースレベルのプロパティには、「資金を預けていないユーザーは提案に投票できない」といったものや、「提案に投票していないユーザーは常に払い戻しを請求できる」といったものがあります。両方のプロパティは、実行の好ましいシーケンスを主張します（投票は資金を預ける前に行われるべきであり、提案に投票した後に払い戻しを請求することはできない）。
スマート契約の形式検証技術
モデルチェック
モデルチェックは、アルゴリズムがスマートコントラクトの形式モデルをその仕様に対してチェックする形式検証技術です。モデルチェックでは、スマートコントラクトはしばしば状態遷移システムとして表現され、許容される契約状態に関する属性は時間論理を使用して定義されます。
モデルチェックには、システム（すなわち契約）の抽象的な数学的表現を作成し、このシステムの特性を表現するための式を使用する必要があります命題論理
. これにより、モデル検査アルゴリズムのタスクが単純化され、つまり数学モデルが与えられた論理式を満たすことを証明することができます。
形式検証におけるモデルチェックは、契約の振る舞いを時間の経過に沿って記述する時間的特性を評価するために主に使用されます。スマートコントラクトの時間的特性には、安全性と生存性が含まれます。これは以前に説明しました。
例えば、アクセス制御に関連するセキュリティプロパティ（例：契約の所有者だけがselfdestructを呼び出すことができる）は、形式論理で記述することができます。その後、モデル検査アルゴリズムによって、契約がこの形式仕様を満たしているかどうかが検証されることがあります。
モデルチェックは、スマートコントラクトのすべての可能な状態を構築し、プロパティ違反を引き起こす到達可能な状態を見つけようとする状態空間探索を使用します。しかし、これは無限の状態（「状態爆発問題」として知られる）につながる可能性があり、そのためモデルチェッカーは抽象化技術に頼って、スマートコントラクトの効率的な分析を可能にしています。
定理証明
定理証明は、スマートコントラクトを含むプログラムの正しさについて数学的に推論する方法です。これは、契約のシステムとその仕様のモデルを数式(論理ステートメント)に変換することを含みます。
定理証明の目的は、これらの文の間の論理的同値を検証することです。“論理的同値”（または“論理的双条件”) とは、2つの文の間の関係の一種であり、最初の文が真である場合に限り、2番目の文も真である。
契約モデルに関する記述とその特性の間の必要な関係（論理的同値性）は、証明可能な文（定理と呼ばれる）として定式化されます。 形式推論システムを使用して、自動定理証明器は定理の妥当性を検証できます。 言い換えれば、定理証明器はスマートコントラクトのモデルが仕様と完全に一致していることを確実に証明できます。
モデル検査が有限状態を持つ遷移システムとして契約モデルをモデル化する一方、定理証明は無限状態システムの分析を扱うことができます。ただし、これにより自動定理証明器は常に論理問題が「決定可能」かどうかを知ることができないことを意味します。
その結果、定理証明器を導出の正当性の証明に導くために人間の支援がしばしば必要とされます。定理証明において人間の努力を使用することは、完全に自動化されたモデルチェックよりも使用コストが高くなります。
シンボリック実行
シンボリック実行は、具体的な値（例：x == 5）の代わりにシンボリックな値（例：x > 5）を使用して関数を実行することによってスマート契約を分析する方法です。形式的検証手法として、シンボリック実行は、契約のコード内のトレースレベルのプロパティについて形式的に推論するために使用されます。
シンボリック実行は、シンボリックな入力値に対する数学的な式として実行トレースを表し、それはパス述語とも呼ばれます。SMTソルバー
「satisfiable（つまり、式を満たす値が存在する）」かどうかをチェックするために使用されます。脆弱なパスが満たされる場合、SMTソルバはそのパスに向かう実行を誘発する具体的な値を生成します。
スマートコントラクトの関数がuint値（x）を入力として取り、xが5より大きい場合はリバートし、10よりも小さい場合もリバートしますと仮定します。通常のテスト手順を使用してエラーをトリガーするxの値を見つけるには、実際にエラーをトリガーする入力を見つける保証なしに、何十ものテストケース（またはそれ以上）を実行する必要があります。
逆に、シンボリック実行ツールは、シンボル値を使用して関数を実行します：X > 5 ∧ X < 10（つまり、xは5より大きく、かつ10より小さい）。関連するパス述語 x = X > 5 ∧ X < 10 は、その後、SMTソルバーに与えられて解決されます。特定の値が式 x = X > 5 ∧ X < 10 を満たす場合、SMTソルバーはそれを計算します。たとえば、ソルバーはxの値として7を出力する可能性があります。
シンボリック実行はプログラムへの入力に依存しており、到達可能なすべての状態を探索する入力のセットが潜在的に無限であるため、それはまだテストの形態です。ただし、例で示されているように、シンボリック実行は、プロパティ違反を引き起こす入力を見つけるために通常のテストよりも効率的です。
また、シンボリック実行は、関数にランダムに入力を生成するなど、他のプロパティベースの手法（例：fuzzing）よりも、偽の陽性が少なくなります。シンボリック実行中にエラーステートがトリガーされた場合、エラーをトリガーする具体的な値を生成して問題を再現することが可能です。
シンボリック実行は、正しさの数学的証明の一定程度を提供することもできます。オーバーフロー保護付きの契約関数の次の例を考えてみてください。
整数オーバーフローを引き起こす実行トレースは、次の式を満たす必要があります: z = x + y AND (z >= x) AND (z=>y) AND (z < x OR z < y) このような式は解決されない可能性が高いため、safe_add関数がオーバーフローしない数学的証明として機能します。
スマートコントラクトに形式検証を使用する理由は何ですか？
信頼性の必要性
フォーマル検証は、死亡、負傷、または財政的破滅など、壊滅的な結果をもたらす可能性のある安全に関わるシステムの正しさを評価するために使用されます。スマートコントラクトは莫大な価値を管理する高価なアプリケーションであり、設計上の単純なエラーが...ユーザーにとって回復不可能な損失
ただし、ブロックチェーン上で実行される際に期待どおりに機能することを保証する可能性を高めるために、デプロイ前に契約を正式に検証することが重要です。
信頼性は、特にEthereum Virtual Machine（EVM）に展開されたコードは通常不変であるため、任意のスマートコントラクトで非常に望ましい品質です。ローンチ後のアップグレードが簡単にアクセスできないため、契約の信頼性を保証する必要があり、形式的検証が必要です。形式的検証は、整数のアンダーフローおよびオーバーフロー、再入可能性、および不適切なガス最適化などの難しい問題を検出することができます。これらの問題は、監査人やテスターの目をすり抜ける可能性があります。
機能的な正しさを証明する
プログラムのテストは、スマートコントラクトが要件を満たしていることを証明する最も一般的な方法です。これには、契約を実行し、それが処理するはずのデータのサンプルを使用してその動作を分析することが含まれます。契約がサンプルデータに対して期待される結果を返した場合、開発者はその正確さの客観的な証拠を持っています。
ただし、このアプローチでは、サンプルの一部ではない入力値の正しい実行を証明することはできません。したがって、契約のテストはバグを検出するのに役立つかもしれません（つまり、実行中に希望する結果を返さないコードパスがある場合）、しかし、バグの欠如を決定的に証明することはできません。
逆に、形式的検証は、契約を実行せずに無限の範囲の実行に要求を満たすことを形式的に証明できます。これには、正確に正しい契約の振る舞いを記述する形式仕様を作成し、契約システムの形式（数学的）モデルを開発する必要があります。その後、契約のモデルとその仕様との整合性を確認するための形式的証明手順に従うことができます。
形式検証では、契約のビジネス ロジックが要件を満たしているかどうかを検証するという問題は、証明または反証できる数学的命題です。命題を形式的に証明することで、有限のステップ数で無限の数のテストケースを検証できます。このようにして、形式検証は、契約が仕様に関して機能的に正しいことを証明する可能性が高くなります。
理想的な検証ターゲット
検証ターゲットは、形式的に検証されるシステムを記述します。形式的検証は、「組み込みシステム」（より大きなシステムの一部を形成する小さな単純なソフトウェア）に最適です。また、ルールが少ない特殊なドメインにも適しており、これにより、ドメイン固有のプロパティを検証するためのツールを変更することが容易になります。
スマートコントラクトは、少なくともある程度は、両方の要件を満たしています。例えば、イーサリアムのコントラクトはサイズが小さいため、正式な検証に適しています。同様に、この評価基板 (EVM) はシンプルなルールに従っているため、評価基板 (EVM) で実行されるプログラムのセマンティック・プロパティの指定と検証が容易になります。
より速い開発サイクル
形式的検証手法（モデルチェックやシンボリック実行など）は、通常、スマートコントラクトコードの通常の解析（テストや監査中に実行される）よりも効率的です。これは、形式的検証が象徴的な値を使用して主張をテストするためです（「ユーザーがnイーサを引き出そうとしたらどうなるか？」）テストは具体的な値を使用するためです（「ユーザーが5イーサを引き出そうとしたらどうなるか？」）。
シンボリック入力変数は具体的な値の複数のクラスをカバーできるため、形式的検証アプローチはより短い時間枠でより多くのコードカバレッジを約束します。効果的に使用すると、形式的検証は開発者の開発サイクルを加速することができます。
フォーマル検証は、高価な設計エラーを減らすことにより、分散型アプリケーション（dapps）の構築プロセスも改善します。脆弱性を修正するために契約をアップグレードする場合、コードベースを広範囲に書き直す必要があり、開発にさらに多くの労力が費やされます。フォーマル検証は、テスターや監査人を通り抜ける可能性のある契約実装の多くのエラーを検出し、契約を展開する前にこれらの問題を修正するための十分な機会を提供できます。
形式検証の欠点
人手のコスト
形式的検証、特に人間が証明者を導いて正当性の証明を導出する半自動検証は、かなりの手作業を必要とします。さらに、形式仕様の作成は高度なスキルを要求する複雑な活動です。
これらの要因（努力と技能）により、契約の正確性を評価する通常の方法（テストや監査など）に比べて、形式的検証がより厳格で高コストであることが要求されます。それでも、完全な検証監査の費用を支払うことは実用的であり、スマートコントラクトの実装におけるエラーのコストを考えれば妥当です。
偽陰性
フォーマル検証は、スマートコントラクトの実行がフォーマル仕様と一致するかどうかをチェックできるだけです。そのため、仕様がスマートコントラクトの期待される動作を適切に記述していることを確認することが重要です。
仕様が不適切に書かれていると、脆弱な実行を指す特性の違反は形式的検証監査で検出されない可能性があります。この場合、開発者は誤って契約がバグフリーであると仮定する可能性があります。
パフォーマンスの問題
形式検証には、モデルチェック中に遭遇する状態および経路爆発問題、およびシンボリックチェック中に遭遇する問題など、さまざまなパフォーマンスの問題があります。また、形式検証ツールは、しばしばSMTソルバーやその他の制約ソルバーを基礎として使用しており、これらのソルバーは計算集中型の手順に依存しています。
また、プログラム検証ツールが常に特性（論理式として記述される）が満足されるかどうかを判断することができるとは限りません（"判定可能性問題
「）プログラムが決して終了しない可能性があるためです。そのため、契約のいくつかの性質を証明することが不可能であるかもしれません。たとえそれがよく指定されていても。
イーサリアムスマートコントラクトのための形式検証ツール
形式仕様を作成するための仕様言語
Act：Actによって、ストレージの更新、事前/事後の条件、および契約不変式の指定が可能になります。そのツールスイートにはCoq、SMTソルバー、またはhevmを使用して多くのプロパティを証明することができる証明バックエンドも含まれています。
Scribble - Scribbleは、Scribble仕様言語のコード注釈を具体的なアサーションに変換して仕様をチェックします。
Dafny - Dafnyは、コードの正確性を推論し証明するために高レベルの注釈に依存する検証対応のプログラミング言語です。
正確性を確認するためのプログラム検証ツール
Certora Prover - Certora Proverは、スマートコントラクトのコードの正確性をチェックするための自動形式検証ツールです。仕様はCVL（Certora Verification Language）で書かれ、プロパティ違反は静的解析と制約解決の組み合わせによって検出されます。
Solidity SMTChecker - SolidityのSMTCheckerは、SMT（Satisfiability Modulo Theories）とHorn solvingに基づいた組み込みモデルチェッカーです。コンパイル中に契約のソースコードが仕様に一致しているかどうかを確認し、安全性のプロパティの違反を静的にチェックします。
solc-verify - solc-verifyは、Solidityコンパイラの拡張バージョンであり、注釈とモジュラープログラム検証を使用して、Solidityコードに対して自動形式検証を実行できます。
KEVM - KEVMは、Kフレームワークで記述されたEthereum仮想マシン（EVM）の形式的意味論です。KEVMは実行可能であり、到達可能性論理を使用して特定のプロパティ関連の主張を証明することができます。
証明のための論理フレームワーク
Isabelle - Isabelle/HOLは、数学的な式を形式言語で表現し、それらの式を証明するためのツールを提供する証明支援システムです。主な用途は数学的証明の形式化であり、特にコンピュータハードウェアやソフトウェアの正当性の証明、コンピュータ言語やプロトコルの性質の証明が含まれます。
Coqは、定理証明器であり、定理を使用してプログラムを定義し、機械が検証した正当性の証明を対話形式で生成することができます。
スマートコントラクト内の脆弱なパターンを検出するためのシンボリック実行ベースのツール
Manticore - シンボリック実行に基づくEVMバイトコード解析ツール解析ツール。
hevm - hevmは、EVMバイトコードのための象徴的実行エンジンおよび等価性チェッカーです。
Mythril - Ethereumスマートコントラクトの脆弱性を検出するためのシンボリック実行ツール
免責事項：
- この記事は[から転載されました]. すべての著作権は元の著者に帰属します[**]. If there are objections to this reprint, please contact the Gate Learnチームが promptly に対処します。
- 責任の免責事項：この記事で表現されている意見や考えは、著者個人のものであり、投資アドバイスを構成するものではありません。
- 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及がない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。
Artigos relacionados
Polygon 2.0 (POL)とは? MATICからPOLへ
ガスレス取引とは?
ラップイーサリアム(WETH)とは何ですか?
スマートコントラクトの形式検証
スマート契約分散化され、信頼性があり、堅牢なアプリケーションを作成し、新しいユースケースを導入し、ユーザーに価値を提供することが可能になっています。スマートコントラクトは大量の価値を取り扱うため、セキュリティは開発者にとって重要な考慮事項です。
フォーマル検証は、改善のために推奨される技術の1つですスマートコントラクトセキュリティ.形式的検証は、形式手法
プログラムの指定、設計、および検証に使用され、長年にわたって重要なハードウェアおよびソフトウェアシステムの正確性を確保するために使用されています。
スマートコントラクトに実装された場合、形式的検証は契約のビジネスロジックが事前に定義された仕様を満たすことを証明できます。テストなどの契約コードの正確性を評価する他の方法と比較して、形式的検証はスマートコントラクトが機能的に正しいことを強く保証します。
フォーマル検証とは何ですか？
形式検証とは、形式仕様に関連するシステムの正確さを評価するプロセスを指します。より簡単に言えば、形式検証によってシステムの振る舞いが特定の要件を満たしているかどうかを確認することができます（つまり、私たちの望む動作をしているかどうかをチェックできます）。
システム（この場合はスマートコントラクト）の期待される動作は形式モデリングを使用して記述され、仕様言語により形式的なプロパティの作成が可能になります。形式検証技術は、契約の実装がその仕様に準拠していることを検証し、前者の正確性の数学的証明を導出できます。契約がその仕様を満たす場合、「機能的に正しい」、「設計により正しい」、または「構築により正しい」と記述されます。
形式モデルとは何ですか？
コンピューターサイエンスでは、形式モデル
は、計算プロセスの数学的記述です。プログラムは数学関数 (方程式) に抽象化され、関数への出力が入力に対してどのように計算されるかをモデルで記述します。
形式モデルは、プログラムの動作の解析が評価される抽象化レベルを提供します。形式モデルの存在により、対象モデルの望ましい特性を記述する形式仕様の作成が可能となります。
形式的検証のためにスマートコントラクトのモデリングにはさまざまな技術が使用されています。例えば、一部のモデルはスマートコントラクトの高レベルな動作について推論するために使用されます。これらのモデリング技術は、スマートコントラクトをブラックボックスの観点で適用し、入力を受け入れ、その入力に基づいて計算を実行するシステムとして見ています。
ハイレベルモデルは、スマートコントラクトと外部エージェント（外部所有アカウント（EOA）、契約アカウント、およびブロックチェーン環境など）の関係に焦点を当てています。このようなモデルは、特定のユーザーの相互作用に応じて契約がどのように振る舞うかを指定するプロパティを定義するために有用です。
逆に、他の形式モデルはスマートコントラクトの低レベルの動作に焦点を当てています。高レベルのモデルは契約の機能について推論するのに役立つかもしれませんが、実装の内部動作の詳細を捉え損ねる可能性があります。低レベルのモデルはプログラムの分析に白箱の視点を適用し、プログラムトレースなどのスマートコントラクトアプリケーションの低レベル表現に依存しています。制御フローグラフ
契約の実行に関連するプロパティについて推論する。
低レベルモデルは、イーサリアムの実行環境（つまり、EVM低レベルのモデリング技術は、特にスマートコントラクトの重要な安全性を確立し、潜在的な脆弱性を検出する際に特に役立ちます。
形式仕様とは何ですか？
仕様は単に特定のシステムが満たす必要がある技術要件です。プログラミングでは、仕様はプログラムの実行に関する一般的な考えを表します（つまり、プログラムが行うべきこと）
スマートコントラクトのコンテキストにおいて、形式仕様はプロパティーを指し、それは契約が満たす必要がある要件の形式的な記述です。そのようなプロパティは「不変式」として記述され、契約の実行に関する論理的な主張を表し、どんな例外もなく、あらゆる可能な状況の下で真でなければなりません。
したがって、形式仕様は、スマートコントラクトの意図された実行を記述する形式言語で書かれた一連の文であると考えることができます。 仕様は契約の特性をカバーし、契約が異なる状況でどのように振る舞うかを定義します。 形式検証の目的は、スマートコントラクトがこれらの特性（不変条件）を持っているかどうか、およびこれらの特性が実行中に違反されていないかを判断することです。
スマートコントラクトの安全な実装を開発する際には、形式仕様が重要です。不変条件を実装しない契約や、実行中にそのプロパティが違反される契約は、機能性を損なう可能性があり、悪意のある攻撃を引き起こす恐れがあります。
スマートコントラクトの形式仕様の種類
形式仕様は、プログラム実行の正確性に関する数学的推論を可能にします。形式モデルと同様に、形式仕様は、契約の実装の高レベルの特性または低レベルの動作を捉えることができます。
形式仕様は、要素を使用して導出されますプログラムロジック
, プログラムの特性について形式的な推論を可能にするもの。プログラム論理には、プログラムの期待される動作を（数学の言語で）表現する形式的な規則があります。さまざまなプログラム論理が形式仕様の作成に使用されています。到達可能性論理
そしてホーア論理
スマートコントラクトの形式仕様は、一般的に高レベルまたは低レベルの仕様として広く分類されます。 仕様がどのカテゴリに属しているかに関係なく、分析対象システムの特性を適切かつ曖昧さなく記述する必要があります。
高水準仕様
その名前が示すように、高レベル仕様（または「モデル指向仕様」とも呼ばれる）はプログラムの高レベルな動作を記述します。高レベル仕様はスマートコントラクトをモデル化します。有限状態機械
(FSM)は、操作を実行して状態を遷移できる、FSMモデルの形式的な特性を定義するために時間論理が使用されています。
は「時間的に限定された命題について推論するための規則(例えば、「私はいつも空腹である」または「私は最終的に空腹になる」)です。形式検証に適用する場合、時間論理は、ステートマシンとしてモデル化されたシステムの正しい動作に関するアサーションを述べるために使用されます。具体的には、時間論理は、スマートコントラクトが置かれる可能性のある将来の状態と、それが状態間でどのように遷移するかを記述します。
スマートコントラクトの高レベル仕様は、通常、安全性と生存性の2つの重要な時間的特性を捉えています。安全性特性は、“何も悪いことが起こらない”という考えを表し、通常は不変性を表します。安全性特性は一般的なソフトウェア要件を定義する場合があります。デッドロック
、または契約に固有の特性を表す（たとえば、関数のアクセス制御に対する不変条件、状態変数の許容値、トークンの転送条件など）。
たとえば、ERC-20トークン契約のtransfer（）またはtransferFrom（）を使用する条件をカバーするこの安全要件を取るとします。「送信者の残高が送信されるトークンの要求額よりも低くない」。この契約不変条件の自然言語の説明は、厳密に検証されるための形式（数学的）の仕様に翻訳することができます。
ライブネス特性は、「最終的に何か良いことが起こる」と主張し、契約が異なる状態を通過する能力に関係しています。ライブネス特性の例としては、「流動性」があり、これは契約が要求に応じて残高をユーザーに移転する能力を指します。この特性が違反されると、ユーザーは契約に格納されている資産を引き出すことができなくなります。これは、Parityウォレット事件
.
低レベル仕様
ハイレベル仕様は、契約の有限状態モデルを出発点とし、このモデルの所望の特性を定義します。一方、ローレベル仕様（特性指向仕様とも呼ばれる）はしばしばプログラム（スマートコントラクト）を数学的関数の集合としてモデル化し、そのようなシステムの正しい動作を記述します。
簡単に言うと、低レベルの仕様はプログラムのトレースを分析し、これらのトレースに対してスマートコントラクトのプロパティを定義しようとします。トレースとは、スマートコントラクトの状態を変更する関数実行のシーケンスを指します。したがって、低レベルの仕様は、契約の内部実行の要件を指定するのに役立ちます。
低レベルの形式仕様は、ホーアスタイルのプロパティまたは実行パス上の不変条件として与えることができます。
ホーア様式の特性
プログラムの正確性について推論するための形式的なルールセットを提供し、スマートコントラクトを含みます。ホーア様式の特性は、Hoare トリプル {P}c{Q} によって表され、ここで、c はプログラムであり、P と Q は c の状態に関する述語（つまり、事前条件と事後条件として形式的に記述されます）。
事前条件は、関数の正しい実行に必要な条件を記述する述語です。契約に呼び出すユーザーは、この条件を満たさなければなりません。事後条件は、関数が正しく実行された場合に確立される条件を記述する述語です。ユーザーは、この条件が関数に呼び出した後に真であることを期待することができます。ホーア論理の不変条件は、関数の実行によって維持される述語です（つまり、変更されない）。
ホーア様式の仕様は、部分的な正しさまたは完全な正しさを保証できます。契約関数の実装が「部分的に正しい」場合、事前条件が関数が実行される前に真である場合、および実行が終了すると、事後条件も真である。事後条件が真であることが保証されると、事前条件が関数が実行される前に真である場合、実行が終了することが保証され、それが行われると、事後条件が真であることが保証されます。
全体の正しさの証明を得ることは難しいです。というのも、いくつかの実行は終了する前に遅れるか、まったく終了しないかもしれません。 とはいえ、実行が終了するかどうかという問題は、おそらく議論の余地があると言えます。なぜなら、イーサリアムのガスメカニズムが無限プログラムループを防ぐからです（実行は成功するか、 'ガス切れ'エラーによって終了します）。
ホーア論理を使用して作成されたスマートコントラクト仕様には、契約内の関数やループの実行のために定義された事前条件、事後条件、不変式があります。事前条件には、関数への誤った入力の可能性が含まれており、事後条件には、そのような入力に対する期待される応答が記述されています（例：特定の例外をスローする）。このように、ホーアスタイルの特性は、契約実装の正確性を保証するために効果的です。
多くの形式的検証フレームワークは、関数の意味論的正確性を証明するためにホーア様式の仕様を使用しています。また、Solidityのrequireおよびassert文を使用して、契約コードに直接ホーア様式のプロパティ（アサーションとして）を追加することも可能です。
requireステートメントは前提条件または不変条件を表し、通常はユーザー入力を検証するために使用されますが、assertは安全性に必要な事後条件を捕捉します。例えば、関数の適切なアクセス制御（安全性プロパティの一例）は、呼び出し元アカウントの識別に関する前提条件チェックとしてrequireを使用することで達成できます。同様に、契約の状態変数の許容値に関する不変条件（例：流通中のトークンの総数）は、assertを使用して、関数の実行後の契約の状態を確認することで侵害から保護することができます。
トレースレベルのプロパティ
トレースベースの仕様は、契約を異なる状態に移行させる操作と、これらの操作間の関係を記述します。前述のように、トレースは、契約の状態を特定の方法で変更する操作のシーケンスです。
このアプローチは、一部の事前定義された状態（状態変数によって記述される）と事前定義された遷移のセット（契約関数によって記述される）を持つスマートコントラクトのモデルに依存しています。さらに、制御フローグラフ
（CFG）は、プログラムの実行フローのグラフィカル表現であり、契約の操作的意味論を記述するためによく使用されます。ここでは、各トレースが制御フローグラフ上のパスとして表されます。
主に、トレースレベルの仕様はスマートコントラクト内部実行パターンについて推論するために使用されます。トレースレベルの仕様を作成することで、スマートコントラクトの許容される実行パス（つまり、状態遷移）を主張します。シンボリック実行などの技術を使用して、形式的に実行が形式モデルで定義されていないパスに従わないことを形式的に検証できます。
Let’s use an example of a DAOトレースレベルのプロパティを記述するための一部の公開関数を持つ契約。ここでは、DAO契約がユーザーが次の操作を行うことを許可していると仮定します。
- 入金する
- 資金を預けた後に提案に投票する
- 提案に投票しない場合は払い戻しを請求します
例として、トレースレベルのプロパティには、「資金を預けていないユーザーは提案に投票できない」といったものや、「提案に投票していないユーザーは常に払い戻しを請求できる」といったものがあります。両方のプロパティは、実行の好ましいシーケンスを主張します（投票は資金を預ける前に行われるべきであり、提案に投票した後に払い戻しを請求することはできない）。
スマート契約の形式検証技術
モデルチェック
モデルチェックは、アルゴリズムがスマートコントラクトの形式モデルをその仕様に対してチェックする形式検証技術です。モデルチェックでは、スマートコントラクトはしばしば状態遷移システムとして表現され、許容される契約状態に関する属性は時間論理を使用して定義されます。
モデルチェックには、システム（すなわち契約）の抽象的な数学的表現を作成し、このシステムの特性を表現するための式を使用する必要があります命題論理
. これにより、モデル検査アルゴリズムのタスクが単純化され、つまり数学モデルが与えられた論理式を満たすことを証明することができます。
形式検証におけるモデルチェックは、契約の振る舞いを時間の経過に沿って記述する時間的特性を評価するために主に使用されます。スマートコントラクトの時間的特性には、安全性と生存性が含まれます。これは以前に説明しました。
例えば、アクセス制御に関連するセキュリティプロパティ（例：契約の所有者だけがselfdestructを呼び出すことができる）は、形式論理で記述することができます。その後、モデル検査アルゴリズムによって、契約がこの形式仕様を満たしているかどうかが検証されることがあります。
モデルチェックは、スマートコントラクトのすべての可能な状態を構築し、プロパティ違反を引き起こす到達可能な状態を見つけようとする状態空間探索を使用します。しかし、これは無限の状態（「状態爆発問題」として知られる）につながる可能性があり、そのためモデルチェッカーは抽象化技術に頼って、スマートコントラクトの効率的な分析を可能にしています。
定理証明
定理証明は、スマートコントラクトを含むプログラムの正しさについて数学的に推論する方法です。これは、契約のシステムとその仕様のモデルを数式(論理ステートメント)に変換することを含みます。
定理証明の目的は、これらの文の間の論理的同値を検証することです。“論理的同値”（または“論理的双条件”) とは、2つの文の間の関係の一種であり、最初の文が真である場合に限り、2番目の文も真である。
契約モデルに関する記述とその特性の間の必要な関係（論理的同値性）は、証明可能な文（定理と呼ばれる）として定式化されます。 形式推論システムを使用して、自動定理証明器は定理の妥当性を検証できます。 言い換えれば、定理証明器はスマートコントラクトのモデルが仕様と完全に一致していることを確実に証明できます。
モデル検査が有限状態を持つ遷移システムとして契約モデルをモデル化する一方、定理証明は無限状態システムの分析を扱うことができます。ただし、これにより自動定理証明器は常に論理問題が「決定可能」かどうかを知ることができないことを意味します。
その結果、定理証明器を導出の正当性の証明に導くために人間の支援がしばしば必要とされます。定理証明において人間の努力を使用することは、完全に自動化されたモデルチェックよりも使用コストが高くなります。
シンボリック実行
シンボリック実行は、具体的な値（例：x == 5）の代わりにシンボリックな値（例：x > 5）を使用して関数を実行することによってスマート契約を分析する方法です。形式的検証手法として、シンボリック実行は、契約のコード内のトレースレベルのプロパティについて形式的に推論するために使用されます。
シンボリック実行は、シンボリックな入力値に対する数学的な式として実行トレースを表し、それはパス述語とも呼ばれます。SMTソルバー
「satisfiable（つまり、式を満たす値が存在する）」かどうかをチェックするために使用されます。脆弱なパスが満たされる場合、SMTソルバはそのパスに向かう実行を誘発する具体的な値を生成します。
スマートコントラクトの関数がuint値（x）を入力として取り、xが5より大きい場合はリバートし、10よりも小さい場合もリバートしますと仮定します。通常のテスト手順を使用してエラーをトリガーするxの値を見つけるには、実際にエラーをトリガーする入力を見つける保証なしに、何十ものテストケース（またはそれ以上）を実行する必要があります。
逆に、シンボリック実行ツールは、シンボル値を使用して関数を実行します：X > 5 ∧ X < 10（つまり、xは5より大きく、かつ10より小さい）。関連するパス述語 x = X > 5 ∧ X < 10 は、その後、SMTソルバーに与えられて解決されます。特定の値が式 x = X > 5 ∧ X < 10 を満たす場合、SMTソルバーはそれを計算します。たとえば、ソルバーはxの値として7を出力する可能性があります。
シンボリック実行はプログラムへの入力に依存しており、到達可能なすべての状態を探索する入力のセットが潜在的に無限であるため、それはまだテストの形態です。ただし、例で示されているように、シンボリック実行は、プロパティ違反を引き起こす入力を見つけるために通常のテストよりも効率的です。
また、シンボリック実行は、関数にランダムに入力を生成するなど、他のプロパティベースの手法（例：fuzzing）よりも、偽の陽性が少なくなります。シンボリック実行中にエラーステートがトリガーされた場合、エラーをトリガーする具体的な値を生成して問題を再現することが可能です。
シンボリック実行は、正しさの数学的証明の一定程度を提供することもできます。オーバーフロー保護付きの契約関数の次の例を考えてみてください。
整数オーバーフローを引き起こす実行トレースは、次の式を満たす必要があります: z = x + y AND (z >= x) AND (z=>y) AND (z < x OR z < y) このような式は解決されない可能性が高いため、safe_add関数がオーバーフローしない数学的証明として機能します。
スマートコントラクトに形式検証を使用する理由は何ですか？
信頼性の必要性
フォーマル検証は、死亡、負傷、または財政的破滅など、壊滅的な結果をもたらす可能性のある安全に関わるシステムの正しさを評価するために使用されます。スマートコントラクトは莫大な価値を管理する高価なアプリケーションであり、設計上の単純なエラーが...ユーザーにとって回復不可能な損失
ただし、ブロックチェーン上で実行される際に期待どおりに機能することを保証する可能性を高めるために、デプロイ前に契約を正式に検証することが重要です。
信頼性は、特にEthereum Virtual Machine（EVM）に展開されたコードは通常不変であるため、任意のスマートコントラクトで非常に望ましい品質です。ローンチ後のアップグレードが簡単にアクセスできないため、契約の信頼性を保証する必要があり、形式的検証が必要です。形式的検証は、整数のアンダーフローおよびオーバーフロー、再入可能性、および不適切なガス最適化などの難しい問題を検出することができます。これらの問題は、監査人やテスターの目をすり抜ける可能性があります。
機能的な正しさを証明する
プログラムのテストは、スマートコントラクトが要件を満たしていることを証明する最も一般的な方法です。これには、契約を実行し、それが処理するはずのデータのサンプルを使用してその動作を分析することが含まれます。契約がサンプルデータに対して期待される結果を返した場合、開発者はその正確さの客観的な証拠を持っています。
ただし、このアプローチでは、サンプルの一部ではない入力値の正しい実行を証明することはできません。したがって、契約のテストはバグを検出するのに役立つかもしれません（つまり、実行中に希望する結果を返さないコードパスがある場合）、しかし、バグの欠如を決定的に証明することはできません。
逆に、形式的検証は、契約を実行せずに無限の範囲の実行に要求を満たすことを形式的に証明できます。これには、正確に正しい契約の振る舞いを記述する形式仕様を作成し、契約システムの形式（数学的）モデルを開発する必要があります。その後、契約のモデルとその仕様との整合性を確認するための形式的証明手順に従うことができます。
形式検証では、契約のビジネス ロジックが要件を満たしているかどうかを検証するという問題は、証明または反証できる数学的命題です。命題を形式的に証明することで、有限のステップ数で無限の数のテストケースを検証できます。このようにして、形式検証は、契約が仕様に関して機能的に正しいことを証明する可能性が高くなります。
理想的な検証ターゲット
検証ターゲットは、形式的に検証されるシステムを記述します。形式的検証は、「組み込みシステム」（より大きなシステムの一部を形成する小さな単純なソフトウェア）に最適です。また、ルールが少ない特殊なドメインにも適しており、これにより、ドメイン固有のプロパティを検証するためのツールを変更することが容易になります。
スマートコントラクトは、少なくともある程度は、両方の要件を満たしています。例えば、イーサリアムのコントラクトはサイズが小さいため、正式な検証に適しています。同様に、この評価基板 (EVM) はシンプルなルールに従っているため、評価基板 (EVM) で実行されるプログラムのセマンティック・プロパティの指定と検証が容易になります。
より速い開発サイクル
形式的検証手法（モデルチェックやシンボリック実行など）は、通常、スマートコントラクトコードの通常の解析（テストや監査中に実行される）よりも効率的です。これは、形式的検証が象徴的な値を使用して主張をテストするためです（「ユーザーがnイーサを引き出そうとしたらどうなるか？」）テストは具体的な値を使用するためです（「ユーザーが5イーサを引き出そうとしたらどうなるか？」）。
シンボリック入力変数は具体的な値の複数のクラスをカバーできるため、形式的検証アプローチはより短い時間枠でより多くのコードカバレッジを約束します。効果的に使用すると、形式的検証は開発者の開発サイクルを加速することができます。
フォーマル検証は、高価な設計エラーを減らすことにより、分散型アプリケーション（dapps）の構築プロセスも改善します。脆弱性を修正するために契約をアップグレードする場合、コードベースを広範囲に書き直す必要があり、開発にさらに多くの労力が費やされます。フォーマル検証は、テスターや監査人を通り抜ける可能性のある契約実装の多くのエラーを検出し、契約を展開する前にこれらの問題を修正するための十分な機会を提供できます。
形式検証の欠点
人手のコスト
形式的検証、特に人間が証明者を導いて正当性の証明を導出する半自動検証は、かなりの手作業を必要とします。さらに、形式仕様の作成は高度なスキルを要求する複雑な活動です。
これらの要因（努力と技能）により、契約の正確性を評価する通常の方法（テストや監査など）に比べて、形式的検証がより厳格で高コストであることが要求されます。それでも、完全な検証監査の費用を支払うことは実用的であり、スマートコントラクトの実装におけるエラーのコストを考えれば妥当です。
偽陰性
フォーマル検証は、スマートコントラクトの実行がフォーマル仕様と一致するかどうかをチェックできるだけです。そのため、仕様がスマートコントラクトの期待される動作を適切に記述していることを確認することが重要です。
仕様が不適切に書かれていると、脆弱な実行を指す特性の違反は形式的検証監査で検出されない可能性があります。この場合、開発者は誤って契約がバグフリーであると仮定する可能性があります。
パフォーマンスの問題
形式検証には、モデルチェック中に遭遇する状態および経路爆発問題、およびシンボリックチェック中に遭遇する問題など、さまざまなパフォーマンスの問題があります。また、形式検証ツールは、しばしばSMTソルバーやその他の制約ソルバーを基礎として使用しており、これらのソルバーは計算集中型の手順に依存しています。
また、プログラム検証ツールが常に特性（論理式として記述される）が満足されるかどうかを判断することができるとは限りません（"判定可能性問題
「）プログラムが決して終了しない可能性があるためです。そのため、契約のいくつかの性質を証明することが不可能であるかもしれません。たとえそれがよく指定されていても。
イーサリアムスマートコントラクトのための形式検証ツール
形式仕様を作成するための仕様言語
Act：Actによって、ストレージの更新、事前/事後の条件、および契約不変式の指定が可能になります。そのツールスイートにはCoq、SMTソルバー、またはhevmを使用して多くのプロパティを証明することができる証明バックエンドも含まれています。
Scribble - Scribbleは、Scribble仕様言語のコード注釈を具体的なアサーションに変換して仕様をチェックします。
Dafny - Dafnyは、コードの正確性を推論し証明するために高レベルの注釈に依存する検証対応のプログラミング言語です。
正確性を確認するためのプログラム検証ツール
Certora Prover - Certora Proverは、スマートコントラクトのコードの正確性をチェックするための自動形式検証ツールです。仕様はCVL（Certora Verification Language）で書かれ、プロパティ違反は静的解析と制約解決の組み合わせによって検出されます。
Solidity SMTChecker - SolidityのSMTCheckerは、SMT（Satisfiability Modulo Theories）とHorn solvingに基づいた組み込みモデルチェッカーです。コンパイル中に契約のソースコードが仕様に一致しているかどうかを確認し、安全性のプロパティの違反を静的にチェックします。
solc-verify - solc-verifyは、Solidityコンパイラの拡張バージョンであり、注釈とモジュラープログラム検証を使用して、Solidityコードに対して自動形式検証を実行できます。
KEVM - KEVMは、Kフレームワークで記述されたEthereum仮想マシン（EVM）の形式的意味論です。KEVMは実行可能であり、到達可能性論理を使用して特定のプロパティ関連の主張を証明することができます。
証明のための論理フレームワーク
Isabelle - Isabelle/HOLは、数学的な式を形式言語で表現し、それらの式を証明するためのツールを提供する証明支援システムです。主な用途は数学的証明の形式化であり、特にコンピュータハードウェアやソフトウェアの正当性の証明、コンピュータ言語やプロトコルの性質の証明が含まれます。
Coqは、定理証明器であり、定理を使用してプログラムを定義し、機械が検証した正当性の証明を対話形式で生成することができます。
スマートコントラクト内の脆弱なパターンを検出するためのシンボリック実行ベースのツール
Manticore - シンボリック実行に基づくEVMバイトコード解析ツール解析ツール。
hevm - hevmは、EVMバイトコードのための象徴的実行エンジンおよび等価性チェッカーです。
Mythril - Ethereumスマートコントラクトの脆弱性を検出するためのシンボリック実行ツール
免責事項：
- この記事は[から転載されました]. すべての著作権は元の著者に帰属します[**]. If there are objections to this reprint, please contact the Gate Learnチームが promptly に対処します。
- 責任の免責事項：この記事で表現されている意見や考えは、著者個人のものであり、投資アドバイスを構成するものではありません。
- 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及がない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。
Artigos relacionados
Polygon 2.0 (POL)とは? MATICからPOLへ
ガスレス取引とは?