イーサリアムの開発者は最近、EIP-8141の設計に新たな進展があったことを明らかにしました。この提案は、新しい機能を追加するたびにイーサリアムのトランザクションフォーマットを変更するのではなく、一部のトランザクション機能を「フレーム」と呼ばれるプログラマブルなコントラクト呼び出しとして実装しようとするものです。
取引機能をプログラマブルに呼び出せるように変更
このアイデアは、取引の満期、集約署名、プライバシーポールに関連するMerkleルート、および取引実行後のアサーションチェックをカバーしています。開発者によると、このインターフェースが十分に汎用的であれば、イーサリアムが今後新しい検証方式を導入した際に、ウォレット、ブラウザ、署名デバイス、Layer 2は毎回新しいトランザクションラッパーに適応する必要がなくなります。
EIP-8141草案では、1つのFrame Transactionを、一連のコントラクト呼び出しの集合として定義しています。異なるフレームは、トランザクション条件の検証、ガス支払いの承認、またはユーザー操作の実行を担当できます。
現在の草案では、DEFAULT、VERIFY、SENDERの3つのモードが列挙されています。VERIFYフレームは、特定の条件が満たされているかを検証するために使用され、SENDERフレームは、トランザクションの送信者として操作を実行することを意味します。複数のフレームは原子的なバッチとして構成され、すべてが成功するか、または全体がロールバックされます。
ウォレットとインフラの調整コストを削減
開発者Derek Chiangの核心的な見解は、今後の新機能追加に必ずしも新しい取引ラッパーを設計する必要はないということである。新しいframeターゲットと呼び出しパターンを用いることで、基本構造を安定させたまま機能を拡張できる可能性がある。
イーサリアムがトランザクションのラッピングを変更するたびに、影響は実行クライアントにとどまらず、ウォレット、Layer 2、ブロックエクスプローラー、署名ハードウェア、ソフトウェアライブラリ、およびさまざまなインフラストラクチャプロバイダーも新しいフォーマットを理解し、サポートする必要があります。
チアンは、イーサリアムのアップグレードは約9か月ごとに実施され、トランザクションパッケージングを頻繁に変更すると調整コストが高くなると述べた。一方、frame形式が比較的安定したインターフェースとなる場合、新しい検証方法はスマートコントラクトや指定されたプロトコルコンポーネントに任せられるようになる。
ただし、これは今後のすべての機能がネットワークアップグレードを回避できることを意味するわけではありません。EIP-8141自体はイーサリアムのコンセンサスルールを変更し、クライアントの実装を必要とします。新しいオペコード、プリコンパイルされたコントラクト、またはガスルールが関与する場合、ハードフォークが必要となる可能性があります。
EIP-8130と並列検証の方向性
開発者も、取引の抽象化が進むと、ウォレットとソーターが取引を実行前に分析するのがより難しくなることを認めています。これに対応するため、チームはEIP-8141と別のアカウント抽象化ドラフトであるEIP-8130の連携方法を検討しています。
EIP-8130は、チェーン上にkeystore構造を提出し、アカウントが事前に参加者と認証契約を登録し、トランザクションで認証方法を明確に標識します。これにより、ノードは任意のウォレットコードを実行する前に、トランザクションに必要な検証プロセスを判断できます。Layer 2にとって、これは認証方法の範囲をより予測可能なコストのセットに制限するのに役立ちます。
ヴィタリク・ブテリンは別の投稿で、関連する方向性を説明しました。彼は取引を「アクション」と「依存条件」の2つの部分に分割しました。前者はイーサリアムの状態を変更し、後者は署名、メルクル証明、ゼロ知識証明などの前提条件を含みます。これらの依存関係が互いに独立している場合、将来的には並列でチェック可能になり、一部の取引の処理コストを削減できる可能性があります。
Hegotáに上場済みですが、有効化時期は未定です
公式のHegotá Meta EIPは、Frame Transactionsを計画されたアップグレードの一つとしてリストアップしており、これはその状態が以前より進展したことを意味します。ただし、EIP-8141は現在もコアドラフト段階にあり、技術的詳細はまだ確定していません。
今後推進すべき作業には、仕様の更新、実行クライアントの実装完了、開発ネットワークの構築、およびウォレットとLayer 2システムとの相互運用テストが含まれます。開発者は、プログラマブルな検証が無効なトランザクションのフィルタリングにかかる計算コストを高める可能性があるため、メモリープールのサービス拒否リスクを評価する必要があります。
現在、Hegotá の Sepolia、Hoodi およびメインネットの有効化時間は未設定です。EIP-8141 はアップグレード計画に含まれていますが、最終的な実装にはまだ実装とテストのプロセスが必要です。