イーサリアム開発者が EIP-8141 フレームの新たな用途を解放

イーサリアム開発者のデレク・チャン氏は9月7日、EIP-8141の作者らは複数のトランザクション機能をイーサリアムのトランザクションエンベロープに個別に追加するのではなく、プログラム可能なコントラクトコールとして表現する方法を発見したと述べた。

EIP-8141 の共著者であり Ethlabs の寄稿者でもある Chiang 氏は、この提案の作成者による最近の研究について説明した投稿の中で、この開発を「設計上の画期的な進歩」と説明しました。このアプローチでは、トランザクションの有効期限、集約署名、プライバシープールのマークルルート、およびトランザクション後のアサーションを「フレーム」と呼ばれる呼び出しとして扱います。

公式のドラフト仕様では、フレームトランザクションを一連のコントラクト呼び出しとして定義しています。さまざまなフレームでトランザクションを検証したり、ガスの支払いを承認したり、ユーザー操作を実行したりできます。この提案では現在、DEFAULT、VERIFY、SENDER の 3 つのモードが提供されています。

VERIFY フレームでは、必要な条件が満たされているかどうかを確認できます。 SENDER フレームは、トランザクション送信者として識別されたアカウントから操作を実行します。フレームはアトミックバッチにグループ化することもできます。つまり、バッチ内のすべての操作が同時に成功するか、グループ全体が元に戻されます。

この提案では、チェーン識別子、ノンス、送信者、料金、署名、フレームリストなどのフィールドを含む基本トランザクションエンベロープを定義しています。 Chiang 氏の論点はさらに狭く、開発者は機能ごとに別のエンベロープ形式を作成することなく、新しいフレームターゲットと呼び出しパターンを通じてより多くの機能を導入できる可能性があります。

安定したエンベロープにより調整作業が軽減される可能性がある

Ethereum トランザクションエンベロープを変更すると、実行クライアント以外にも影響します。ウォレット、レイヤー 2 ネットワーク、ブロックエクスプローラー、署名デバイス、ソフトウェアライブラリ、インフラストラクチャプロバイダーはすべて、新しい形式を理解する必要があります。

チェン氏は、イーサリアムのアップグレードはおよそ9カ月ごとに行われるため、エンベロープの変更を繰り返すと時間がかかり、調整が大変になると述べた。十分に一般的なフレーム形式は安定したインターフェイスとして機能し、コントラクトまたは指定されたプロトコルコンポーネントは新しい検証方法を提供します。

これは、将来の機能にネットワークのアップグレードがまったく必要なくなるという意味ではありません。 EIP-8141 自体はイーサリアムのコンセンサスルールを変更し、クライアントの実装を必要とします。新しいオペコード、プリコンパイル、またはガスルールでもハードフォークが必要になる場合があります。提案されている利点は、開発者が必ずしも毎回トランザクションコンテナを再設計する必要がないことです。

EIP-8141 仕様では、主な目標としてネイティブアカウントの抽象化が挙げられています。鍵のローテーション、代替署名システム、スポンサー付きガスの支払い、トランザクションのバッチ処理をサポートする可能性があります。また、従来の外部所有アカウントで使用されていた secp256k1 署名システムへのイーサリアムアカウントの依存性を減らすことも目的としています。

Vitalik Buterin氏が提案したイーサリアムトランザクションの再設計に関する報道の中でcrypto.newsが報じたように、プログラム可能な検証は最終的に、ある固定署名スキームを別の固定署名スキームに置き換えることなく、イーサリアムが新しい認証システムを採用するのに役立つ可能性がある。

EIP-8130 によりフレームの検査が容易になる可能性がある

蒋介石氏もトレードオフを認めた。高度に抽象化されたトランザクションは、ウォレット、シーケンサー、その他のインフラストラクチャが実行前に分析することが困難になる可能性があります。たとえば、レイヤー 2 シーケンサーは、計算コストが予測可能であるため、指定された署名メソッドのみを受け入れたい場合があります。

したがって、開発者は、別のアカウント抽象化案の草案である EIP-8130 でフレームがどのように機能するかを検討しています。 EIP-8130 は、アカウントがアクターと認証コントラクトを登録するオンチェーンキーストアを作成します。トランザクションは認証方法を明示的に識別します。

この構造により、ノードは任意のウォレットコードを実行する前に、トランザクションに必要な検証プロセスを決定できます。 EIP-8130 で提案されているレイヤー 2 プロファイルでは、チェーンはトランザクションパスを固定コストの認証子の正規セットに制限し、通常の EVM 実行を通じて他の認証方法を利用できるようにすることができます。

Chiang氏は、EIP-8130はEIP-8141フレーム上に定義された構造を課す可能性があると述べた。この連携により、フレームの柔軟性を維持しながら、ウォレットや高スループットのチェーンにより読みやすいトランザクション形式を提供できる可能性があります。組み合わせた設計はまだ最終決定されておらず、両方の仕様はまだ改訂される可能性があります。

以前の crypto.news の報道では、Hegotá の初期スコーピングプロセスにおける EIP-8141 と EIP-8130 間の競合を調査しました。最新のコメントは、開発者が提案を相互に排他的な代替案としてのみ扱うのではなく、互換性のある要素を探していることを示唆しています。

Buterin は並列検証でフレームを接続します

Vitalik Buterin は別の投稿で技術的な方向性を詳しく説明し、トランザクションの「アクション」と「依存関係」を区別しました。 ETHの転送など、アクションによってイーサリアムの状態が変化します。依存関係とは、署名、マークル証明、ゼロ知識証明など、満たさなければならない条件です。

ブテリン氏は、独立した依存関係を並行してチェックできると主張しました。 Ethereum 状態にアクセスしない条件は、実行中に繰り返されるのではなく、mempool によって 1 回処理される可能性があります。複数のチェックは最終的には再帰的な STARK 証明によって表現される可能性がありますが、それは承認された機能ではなく研究の方向性のままです。

この区別は、クライアントが予測可能なトランザクションとイーサリアムの完全な動的実行環境を必要とする操作を区別するのにも役立ちます。ブテリン氏は、より静的に分析可能な活動により、ガスコストが削減され、さらに規模が拡大する可能性があると述べた。そのような料金体系は承認されていません。

フレームモデルは、検証と実行が識別可能な呼び出しとして現れるため、そのアプローチに潜在的なインターフェイスを提供します。イーサリアムは、より単純なトランザクションが要件に関するより多くの情報を宣言できるようにしながら、柔軟な契約の実行を維持します。

EIP-8141 は予定されていますが、日付は未定です

公式の Hegotá Meta EIP には、イーサリアムの Hegotá アップグレードに含まれる予定のフレームトランザクションと FOCIL がリストされています。これは以前の検討よりも強力なステータスを示していますが、EIP-8141 の現在の技術設計が凍結されるわけではありません。

EIP-8141 は、ドラフトコア提案としてマークされたままです。その作成者は、実装作業が進むにつれて、フレームモード、署名処理、ガスアカウンティング、および EIP-8130 との関係を改訂できます。 Hegotá 文書では、Sepolia、Hoodi、およびメインネットのアクティベーションフィールドも空白のままになっています。

次の測定可能なステップには、仕様の更新、実行クライアントの実装、開発ネットワーク、ウォレットおよびレイヤー 2 システムとの相互運用性テストが含まれます。開発者は、プログラム可能な検証によって無効なトランザクションの拒否の計算コストが高くなる可能性があるため、mempool のサービス拒否リスクも調査する必要があります。

テストでは、提案されている柔軟なフレームと構造化された認証子の組み合わせが、イーサリアムのベース層とより高速な EVM チェーンのニーズを満たすことができるかどうかが判断されます。アクティベーションパラメータが公開されるまで、EIP-8141 は予定されているもののヘゴタの未完成の部分のままです。