原文
[Idea/Draft] Protocol-Level Smart Contract Invariant Protection via Pre-Mempool Validation (Security Manifests) — ariutokintumi (2026-07-22)
概要
これは、EVMセキュリティにとって必要な進化であると私が考えるものについて議論を開始するための、概念的なドラフトです。目標は、スマートコントラクト用の標準化された「セキュリティマニフェスト」を導入し、それに特化したメムプールアドミッションポリシーを組み合わせることです。
明確にしておきますが、これは一般的なアイデアです。最終的な仕様を提示するのではなく、議論を開始するために提案するものです。しかし、その前提は直接的です。実行前に意図されたコントラクトの動作を強制することで、ゼロデイエクスプロイトを防ぐインフラストラクチャ層のゲートキーパーが必要になるかもしれません。
動機
現在、スマートコントラクトのセキュリティは、実行時のロジック（ガスとブロックの制限によって制約される）またはオフチェーン監視（手遅れになることが多い）に完全に依存しています。EIP-7906 (トランザクションアサーション)のような最近の提案は素晴らしいですが、それらはユーザー側の保護（例：スリッページ/ステート差分制限）です。これらは攻撃者からスマートコントラクト自体を保護するものではありません。
まず、明白な障害について触れておきましょう。L1ノードが非決定的なAIや重いヒューリスティックをネイティブに実行すると、コンセンサスを破壊してしまうことは承知しています。したがって、この提案はGeth/Reth内にAIを組み込むことを示唆するものではありません。代わりに、オフチェーンの脅威分析とオンチェーンのメムプールアドミッションを橋渡しするための、ネットワークレベルの標準を提案します。
提案アーキテクチャ（ハイレベル）
-
マニフェスト標準: コントラクトは、通常のパラメータ、状態境界、および制限された変更を詳述する標準化されたURIを公開します。
-
プレメムプールルーティング: 保護されたコントラクトをターゲットとするトランザクションは、特殊なビルダーネットワークまたはプレメムプールにゴシップされます。
-
ヒューリスティック / AI検証: この特殊なネットワーク内のノードは、コントラクトのマニフェストを使用して、トランザクションペイロードに対して高度な非決定論的チェック（AI/ML脅威モデリング）を実行します。
-
標準メムプールアドミッション: 安全と判断された場合、トランザクションは暗号学的証明（例：zkML）または委員会署名でラップされます。L1ノードは、これを受け入れる前に、この軽量な証明/署名を単純に検証します。検証のためのガス費用は送信者が支払います。
マニフェストの構成（ドラフトコンセプト）
マニフェストは、securityManifestURI()のような標準化された関数を介してオンチェーンで参照またはアクセス可能な、不変のドキュメント（オンチェーンまたはIPFS/Arweaveでホストされ、通知なしのコンテンツ変更を避ける）であるべきです。
-
フォーマット: 標準化されたJSONまたはYAMLスキーマ。
-
内容: ABIの拡張として機能し、厳密な事前条件と事後条件を定義する必要があります。以下を概説します。
-
許容される入力範囲（例：「関数XはYより大きい
uint256を受け取ってはならない」）。 -
状態不変条件（例：「すべての残高の合計は
totalSupplyと厳密に等しくなければならない」）。 -
行動異常（例：「単一のトランザクションでTVLの10%以上を枯渇させてはならない」）。
-
-
言語: 理想的には、既存の不変条件テスト構文（HalmosやFoundryの
forge test不変条件構造など）に密接にマッピングされるべきです。これにより、開発者はローカルテストの制約をライブネットワークファイアウォールに簡単に変換できます。
明白な問題への対処（トレードオフと攻撃ベクトル）
セキュリティ層を追加することは、本質的に新しい攻撃ベクトルを追加することになるため、トレードオフについて事前に言及しておきたいと思います。
-
非遡及的: この仕様は遡及的であってはならず、あるべきではありません。既存のアップグレード不可能なコントラクトに任意にマニフェストをアタッチしてその動作を変更することはできません。これは、新規デプロイまたは特定のアップグレードパスに対するオプトイン標準でなければなりません。
-
「悪意のある管理者」ベクトル: 典型的な質問は、「管理者が悪意を持ってマニフェストを更新し、ユーザーを検閲したり、コントラクトを破壊したりした場合はどうなるのか？」です。答えは、管理者が悪意を持ってERC-ERC-1967プロキシの実装を更新した場合とまったく同じことが起こります。 はい、アップグレードキーへの信頼が必要です。これは、プロキシですでに受け入れているまったく同じトレードオフの新しい形にすぎません。
-
監査可能性: 悪意のあるマニフェストは誤検知（または意図的なサービス拒否）を引き起こす可能性があるため、マニフェストはコードです。保護するSolidityスマートコントラクトとまったく同じように監査されなければなりません。
悪意を持って使用されれば、検閲ツールになります。正しく使用されれば、その恩恵は計り知れません。開発者は、完璧な形式検証に純粋に依存したり、予測不能なエッジケース攻撃を恐れたりする必要がなくなります。なぜなら、インフラストラクチャ自体がコントラクトの基本的な物理学に違反するトランザクションのルーティングを拒否するからです。
コミュニティへの公開質問
-
メムプールゴシップルール: これは、汎用的な「有効性証明」フィールドを必要とする新しいEIP-EIP-2718トランザクションタイプで処理されるべきでしょうか、それともMEV-Boost ビルダーによってプロトコル外で完全に処理されるべきでしょうか？
-
まずL2で？ 最終目標はEVM全体のインフラストラクチャですが、まずL2 シーケンサーの実装に特化してこれを標準化する方が理にかなっているでしょうか（Zircuitがシーケンサーレベルの隔離にアプローチする方法と同様に）？
この概念化を洗練するための、コミュニティからの率直な意見と建設的なアイデアを楽しみにしています。
1投稿 - 1参加者