EIP-8361とは何ですか？Ethereumのバリディティ・プルーフについて解説

EIP-8361は、EIP-8141フレームトランザクションのための証明持参型受付（proof-carrying admission）に特化しています。Ethereumの実行を置き換えるものではなく、新たなトランザクションタイプの導入やスマートコントラクトのデプロイ、トランザクションのプライバシー提供、バリデーター報酬の変更、18か月の実装期間の定義なども行いません。主な目的は、不正やリソース消費の大きいトランザクションに対する安全性を維持しつつ、検証時の冗長な計算を削減することです。

以下のセクションでは、proof-carryingプロセスの仕組み、ノードの検証内容、EIP-8361がロールアップの有効性証明やトランザクションシミュレーションとどう異なるか、そして未解決の技術的制限について解説します。

主なポイント

• EIP-8361はピアツーピア伝播用のトランザクション有効性証明データを標準化します。 フレームトランザクションは、検証プレフィックスが承認状態に到達したことを示すSTARKを持つことができます。
• ノードはコストの高い認可ロジックを再実行する代わりに証明を検証します。 証明と検証の分離により、Ethereumノード間での重複計算を削減できます。
• 証明はコンセンサス外です。 トランザクションとともに伝送され、メンンプール受付に使われ、不要になれば破棄されます。
• 設計は複雑なスマートアカウント検証をサポートします。 マルチシグルール、代替署名システム、ペイマスター、証明重視の認可などが該当します。
• EIP-8361は草案段階です。 有効化されたアップグレードではなく、EIP-7701、EIP-7702、ロールアップ有効性証明、ステーキング報酬提案とは異なります。

EIP-8361とは

EIP-8361（Transaction Validity Proofs）は、Ethereumトランザクションが検証ロジックによる承認を暗号学的証拠とともに持って到達できるネットワーク機構を提案します。この草案は、フレームトランザクションとプログラム可能な検証段階を定義するEIP-8141のプロトコルレベル変更に対応するネットワーク側の設計です。

Ethereum Improvement Proposal（EIP）は、Ethereumの標準やプロトコル機能、インターフェース、プロセスを記述する技術文書です。EIPとして公開されても、自動的に承認・実装されたことにはなりません。EIP-8361は作業中の草案であり、仕様や依存関係、ステータスは今後変更される可能性があります。

この提案は次の課題に対応します：

高コストな認可を必要とするトランザクションを、すべてのピアがその計算を繰り返さずにノードが安全に受付するにはどうすればよいか？

EIP-8361では、プルーバーが関連するトランザクション検証ロジックをオフチェーンで実行し、STARKを生成します。受信ノードは証明を検証し、宣言された前提条件をEthereumの現在の状態と照合し、トランザクションをパブリックメンンプールに置くか判断します。

トランザクション自体は、最終的にブロックに含まれる際にEthereumの実行ルール下で有効でなければなりません。証明は受付ポリシーの補助であり、プロトコルレベルの実行やコンセンサス検証を置き換えるものではありません。

複雑なEthereumトランザクション検証の難しさ

従来の外部所有アカウント（EOA）は、秘密鍵と公開鍵で管理されます。アカウントはECDSA署名でトランザクションを承認し、送信者ノンス、宛先アドレス、価値、チェーンID、ガスリミット、ガス代やEIP-1559手数料などのフィールドを持ちます。

これらのチェックは予測しやすく、ノードは署名や残高、ノンスを検証し、不正やリプレイのトランザクションを拒否できます。

スマートアカウントは、以下のような多様な検証ロジックを持つ場合があります：

• 複数の公開鍵
• 支出上限
• セッションキー
• 委任コントラクト
• ペイマスターのルール
• ポスト量子署名
• リカバリー条件
• ゼロ知識証明
• アプリ固有の認可コード

こうしたロジックは既存のスマートコントラクトやアカウント展開時の新規コントラクトに存在する場合もあります。コントラクトの作成やデプロイ時にも、ファクトリーや初期化コード、新アドレスの検証が必要な場合があります。

Ethereumノードは、すべての未確認トランザクションに無制限の検証コードを安全に実行できません。攻撃者は高コストなスマートコントラクトやハッシュ関数、ストレージリード、証明システムを呼び出す不正トランザクションを送信し、承認しない場合があります。トランザクションが無効でも、検証にはノードリソースが消費されます。

EIP-8361トランザクション有効性証明 は、負荷の高い作業をプルーバー側に移しつつ、証明検証のコストを制限します。

EIP-8361 Proof-Carryingトランザクションの仕組み

EIP-8361は、EIP-8141フレームトランザクションの受付に2つの方法を提案します：

1. シミュレート受付：ノードが検証プレフィックスを直接実行
2. Proof-Carrying受付：ノードが検証プレフィックスの承認を示すSTARKを検証

2番目の方法は、通常の検証コード呼び出しがノードの検証予算を超える場合を想定しています。

1. トランザクションが検証ロジックを定義

EIP-8141フレームトランザクションは、認可や支払者特定、実行準備など目的ごとにフレームを分割できます。検証プレフィックスは通常の実行フレームの前に実行されます。

検証プレフィックスは、送信者や委任先のスマートコントラクトを呼び出し、署名や権限、残高、有効期限などをチェックし、APPROVE操作を実行します。

EIP-8141は、従来のECDSA署名による送信者決定型トランザクションと異なり、プログラム可能な検証モデルでアカウント抽象化を推進します。また、EIP-7702のECDSA認可リストに依存せず、より柔軟な暗号技術を目指しています。

2. プルーバーが検証プレフィックスを実行

プルーバーは、宣言された入力と状態前提条件に基づき検証プレフィックスを実行します。以下の検証が含まれる場合があります：

• 署名と公開鍵の一致
• 送信者残高の十分性
• ペイマスター残高の基準超過
• コントラクトストレージの権限
• チェーンIDの一致
• ノンスによるリプレイ防止
• 検証コードが承認で終了

プルーバーは、関連トランザクションや依存関係、前提条件、支払者、有効性条件をコミットするSTARKを作成します。

3. 証明が状態前提条件を宣言

暗号学的証明は、状態が変化した場合に黙って依存していると無効化されます。EIP-8361は、証明時に利用した状態事実を記述する前提条件ベクターを提案します。

等価条件はコントラクトのコードハッシュやノンス、ストレージ値が宣言値と一致することを示し、以上条件はアカウント残高が最低値を上回る必要があることを示します。

これにより、証明はEthereumの全状態を埋め込まずとも過去の有効状態に結びつきます。新しいブロックでデータが変化した場合、ノードは前提条件ベクターを再確認できます。

この仕組みは EIP-8361メンンプール検証 の中核です：ノードは暗号的に有効な古い証明を盲信しません。

4. ノードがSTARKを検証

受信ノードは、証明検証前に低コストの構造チェックを行い、その後指定の検証鍵でSTARKを検証し、依存関係や前提条件をEthereum状態と照合します。

最新の証明システムは、元の計算再実行より速く検証できる証明を生成します。単一の証明が多くのピアによる繰り返しシミュレーションを置き換え、ネットワーク全体で冗長計算を削減します。

ただし、証明生成自体は高コストです。STARK生成には多大な処理やメモリ、専用ソフトウェアが必要です。この提案は計算の移動であり、排除ではありません。

5. トランザクションがメンンプールに入る

証明と状態チェックが成功すれば、ノードは高コストな検証プレフィックスを再実行せずにトランザクションを受付・伝播できます。

証明はピアツーピアのメタデータであり、トランザクションのコールデータやスマートコントラクト、アカウント状態、ブロックのMerkle rootには保存されません。

トランザクションが含まれると、Ethereumはプロトコルルール下で実行します。証明が古くなったりトランザクションが削除されれば、ネットワークメタデータは破棄されます。

EIP-8361有効性証明の証明内容

EIP-8361有効性証明は、特定の検証計算が宣言された前提条件下で正しく実行され、承認状態に到達したことを示す暗号学的証拠です。

これは、検証ロジックが有効な署名や十分な残高、正しいノンス、許可された支払者、コントラクト認可をチェックしたことを示します。ただし、トランザクションによる後続のEVM状態遷移の正しさすべてを証明するものではありません。

この区別は重要です：

• EIP-8361は受付関連の検証を証明します。
• ロールアップ有効性証明はオフチェーン状態遷移を証明します。
• Merkle証明は認証済みデータ構造への包含を証明します。
• ゼロ知識証明は情報を秘匿する場合がありますが、有効性のみではプライバシーは保証されません。

Merkle証明は、リーフからMerkle rootへの接続で、トランザクションが特定バッチ・ブロック・状態ツリーに属することを示します。ZKロールアップでは、Merkle証明が送信者・受信者アカウントの存在や残高更新による新状態root生成を立証します。

EIP-8361は効率的な正当性証明としてSTARKを用いますが、目的は機密実行ではありません。トランザクションや依存関係は参加ノードに可視のままです。

EIP-8361とZKロールアップ有効性証明の比較

Layer 2スケーリングソリューションは有効性証明を広範に利用します。ZKロールアップは複数トランザクションをオフチェーンで実行し、簡潔な証明をEthereumのバリファイアコントラクトに提出します。その証明は、バッチが前の有効状態をルール通り新状態に変換したことを示します。

Ethereum上で全トランザクションを再実行する代わりに、バリファイアコントラクトが証明と公開入力を検証します。これによりオンチェーンリソース消費が削減され、多数トランザクションにガス代を分散できます。再帰的証明システムは、複数証明の集約も可能です。

有効性証明は、ロールアップが無効な状態遷移を確定させるのを防ぎます（証明システム等が安全な場合）。また、紛争ウィンドウ不要でL2→L1ファイナリティを高速化します。

EIP-8361は異なるアプローチです。全計算バッチの証明やL2のMerkle root更新、出金トリガーは行いません。ノード受付要件を満たす1つのフレームトランザクションを証明します。

EIP-8361有効性証明とFraud Proofの比較

オプティミスティック・ロールアップは、提出状態更新がチャレンジされない限り有効と見なします。Fraud Proofは監視者が異議ある遷移を検出し、チャレンジ期間内に証拠を提出する必要があります。無効な主張は、チャレンジ解決まで暫定的に受け入れられることがあります。

有効性証明システムは逆で、バリファイアが正しい実行の暗号証拠を確認して初めて新状態コミットメントが受理されます。これによりFraud Proofチャレンジ期間を待たず高速出金が可能です。

ただし、有効性証明が常にFraud Proofより「安全」とは限りません。主な違いはプルーバー複雑性、バリファイア安全性、データ可用性、信頼セットアップ、チャレンジ前提、実装成熟度などです。

EIP-8361自体はロールアップのセキュリティモデルではありません。証明はメンンプール受付前に検証され、ロールアップのFraud Proofや有効性証明はオフチェーンスケーリングを保護します。

EIP-8361とEIP-7702アカウント委任の比較

EIP-7702は既存EOAがコードフィールドに委任インジケーターを設定し、アカウントへの呼び出しが指定スマートコントラクトのコードを実行できるようにします。authorization_listを含むタイプ4トランザクションを導入しました。

各認可タプルは以下を含みます：

• chain_id
• 委任コントラクトアドレス
• アカウントノンス
• 署名フィールド

認可はEOA秘密鍵で署名されます。署名者はtx.originと異なる場合があり、1つのトランザクションで複数EOAの認可も可能です。各認可は通常の実行前に対応アカウントの委任インジケーターを更新できます。

これにより、ユーザーはアカウントを従来のスマートコントラクトに恒久的に変換せず、署名認可でスマートコントラクトへの実行権限を委任できます。委任コードはバッチ処理、ガススポンサー、権限管理などをサポートします。

EIP-7702はセキュリティ上の考慮も生みます。chain IDが0の場合、認可がチェーン間で有効となり、ノンスや署名フィールドはリプレイ攻撃を抑止します。委任コードはtx.originや未決トランザクション、ストレージ、残高にも影響します。

EIP-8361はauthorization_listを置き換えたり拡張しません。複雑な検証ロジックを含むトランザクション受付に関するものです。EIP-8361有効性証明とトランザクションシミュレーションの主な違いは、EOAコード委任ではなくメンンプール計算に関するものです。

EIP-8361とEIP-7701ネイティブアカウント抽象化の比較

EIP-7701は2024年5月1日にネイティブアカウント抽象化提案として作成されました。検証・実行・ポストオペレーション段階に分割し、新EIP-2718トランザクションタイプを提案しました。

設計はエントリポイントアドレス0x7701、ロールベースオペコード、送信者・ペイマスター分離検証、コントラクト制御ガス支払いを用いました。ERC-4337バンドラーフローは不要でした。

EIP-7701はEIP-8141により撤回されました。公開仕様に撤回理由が明記され、EOF形式コントラクト必須という主張も最終仕様には含まれません。

EIP-8361はEIP-8141の新しいフレームトランザクションモデルを中心に構築され、高コストなプログラム可能検証を安全に伝播しやすくすることでアカウント抽象化をサポートします。

EIP-2718はEIP-7701、EIP-7702、EIP-8141などで使われる型付きトランザクションエンベロープを提供します。署名データにタイプを含めることで、型をまたぐ署名リプレイリスクも低減します。

ウォレット、ノード、デベロッパーへの実務的影響

ウォレット開発者は、スマートアカウント認可が通常のメンンプールシミュレーションには高コストな場合、proof-carrying admissionを利用可能です。ウォレットはローカルプルーバーやサービス、分散型証明ネットワークから証明を取得し、トランザクション送信前に利用できます。

ノード開発者は以下を実装する必要があります：

• ピアツーピア証明伝送
• バージョン管理された検証鍵
• 証明サイズ制限
• 前提・依存関係のチェック
• ピアごとのレート制限
• 古い証明の排除
• フォールバックシミュレーション

スマートコントラクト開発者は、全ノードに全コストを実行させずアプリ固有検証を維持できます。ポスト量子署名や複数鍵ポリシー、複雑なペイマスター、証明ベース権限もサポートできます。

EIP-8361のウォレット・ノード・デベロッパーへの影響 は、証明生成遅延やクライアント採用、相互運用性、EIP-8141最終仕様に依存します。

例えば、トレーダーが Gate でEthereumアップグレードの市場反応を評価する場合、ネットワーク発表と ETH/USDTマーケットチャート を比較できますが、市場価格や取引高、ガス代だけでは草案EIPの技術的承認や有効化は判断できません。

セキュリティ上の考慮と制限

EIP-8361には複数のセキュリティ上の考慮点があります。

1. 証明の健全性はSTARK回路と検証鍵の正確さに依存します。回路バグが意図と異なる証明を生成する可能性があります。
2. 証明検証にも計算・帯域幅が必要です。攻撃者が不正または過大な証明を送信する場合、低コスト事前チェックやサイズ制限、ピア属性付与が必要です。
3. 前提条件が古くなることがあります。証明が有効でも、ブロックで状態が変化すれば適用できなくなります。
4. ノードポリシーの不一致でトランザクション伝播が分断される可能性があります。クライアントごとに証明サイズ上限や受付基準が異なる場合があります。
5. 証明生成は、十分なハードウェアや最適化ソフトウェアを持つサービスが少数の場合、中央集権圧力を生みます。

EIP-8361は通常のトランザクションコストを排除しません。トランザクションがブロック実行に到達すれば、送信者や支払者がガス代を負担します。証明はノードのオフチェーン計算冗長性を削減しますが、Ethereumのガス代を排除しません。

EIP-8361が提案しないこと

いくつかの主張は他提案に基づくものであり、EIP-8361には当てはまりません。

EIP-8361は以下を行いません：

• 18か月の移行期間の規定
• ステーキング利回り下限の撤廃
• バリデーター報酬の上限設定
• ステーキング50％接近時の報酬差し引き
• 市場駆動のステーキング均衡の創出
• EIP-7702の認可リスト導入
• EIP-7701のネイティブエントリポイント導入
• 新EIP-2718トランザクションタイプの作成
• プライバシー保証
• ZKロールアップバッチの決済
• Fraud Proofの置換
• ユーザーの契約上または関連権利の免除

草案の著作権セクションは、著作権や関連権利がCC0で放棄される場合があり、これはEIP文書自体に関する法的通知であり、ユーザー資金やトランザクション権利、スマートコントラクト権限には関係しません。

結論

EIP-8361はEthereumパブリックメンンプール向けに証明持参型トランザクション受付を提案します。プルーバーが複雑なEIP-8141検証プレフィックスを一度実行し、STARKを生成することで、複数ノードが同じ高コスト計算を再現せずに検証できます。

主な用途は、通常のメンンプール検証制限を超えるプログラム可能な認可（高度なスマートアカウント、代替署名、ペイマスター、証明重視コントラクトなど）です。設計はノード計算の冗長性を削減しつつ、現状態の前提条件を可視・再確認可能に保ちます。

EIP-8361はZKロールアップ決済、Fraud Proofチャレンジ、EIP-7702アカウント委任、撤回済みEIP-7701設計とは異なります。あくまで草案段階のネットワーク提案であり、セキュリティや証明経済性、相互運用性、依存関係は今後のEthereum展開前にさらなる開発が必要です。

よくある質問

EIP-8361は新しいトランザクションタイプを作成しますか？

いいえ。EIP-8141フレームトランザクションに証明持参型受付を適用します。EIP-2718が汎用型トランザクションフレームワークを提供しますが、EIP-8361は新たなトランザクションエンベロープを導入しません。

EIP-8361の証明はゼロ知識証明ですか？

草案はSTARKベースの有効性証明を提案していますが、有効性は必ずしもプライバシーを意味しません。証明は宣言された前提条件下での正しい検証を示すもので、すべてのトランザクションデータの秘匿を目的としません。

単一証明で複数トランザクションをカバーできますか？

証明システムは計算の集約や再帰的証明が可能で、ロールアップは複数トランザクション証明を1つに圧縮可能です。EIP-8361現行設計は任意バッチ集約の標準化ではなく、特定フレームトランザクションの受付に焦点を当てています。

EIP-8361はガス代を削減しますか？

直接的には削減しません。ノードのオフチェーン計算の繰り返しを減らす可能性はありますが、ブロックに含まれるトランザクションはEthereum実行分のガスを引き続き支払います。

EIP-8361はEIP-7702とどう異なりますか？

EIP-7702はEOAが署名認可タプルでコード実行を委任できます。EIP-8361は高コストなプログラム可能検証を持つトランザクションを証明ベースでノードが受付する方法を提案します。

免責事項

本コンテンツは教育目的であり、Ethereumの確定的なアップグレードを保証するものではありません。仕様、実装計画、セキュリティ前提、ネットワークサポートは変更される場合があります。プロトコル開発や過去の市場データは将来のETHパフォーマンスを保証しません。