認証方法の柔軟性と検証コストの予測可能性を両立
イーサリアム（Ethereum）のアカウント抽象化（Account Abstraction：AA）に関する新たな改善提案「EIP-8397：フレーム・オーセンティケーター・シグネチャーズ（Frame Authenticator Signatures）」が8月26日に提出された。
EIP-8397は、AAの実現に向けた「EIP-8141：フレーム・トランザクション（Frame Transaction）」に、新たな署名方式「オーセンティケーター（AUTHENTICATOR）」を追加する提案だ。スマートコントラクトを使ってさまざまな認証方式を利用できるようにしながら、その認証に必要な計算量には一定の上限を設ける。つまり、同提案は認証方法の自由度を維持しながら、ノードが認証処理に必要な負荷をあらかじめ見積もれるようにする狙いがある。
EIP-8397の前提となるAAとは、秘密鍵による署名を前提とする従来のアカウントを、より柔軟な認証や操作ができるようにする考え方だ。AAを導入することで、スマートフォンの生体認証を利用するパスキーでのトランザクション承認や、秘密鍵紛失時の別方法でのアカウント復旧、サービス側がユーザーに代わってガス代を支払うなど、一般的なウェブサービスに近い使い勝手をウォレットに持たせられる。
こうしたAAをイーサリアムのプロトコルレベルで実現する方法として提案されているのがEIP-8141だ。同提案では、トランザクションを「フレーム」と呼ばれる複数の処理単位で構成する。それぞれのフレームでトランザクションの検証やガス支払いの承認、ユーザー操作の実行などを行えるようにする仕組みだ。
EIP-8141では、イーサリアム上でスマートコントラクトを実行する「EVM」を使って、アカウントごとに検証方法を定義できる。一方、独自の署名方式を利用する場合は、その暗号学的な検証もアカウント側のプログラムで行うため、検証コストをあらかじめ予測しにくくなる場合がある。特に大量のトランザクションを扱うL2では、検証コストをあらかじめ予測できることが重要となる。
そこでEIP-8397ではスマートコントラクトを利用する「オーセンティケーター」署名方式を導入する。オーセンティケーターは、署名などの暗号学的な証明を検証する役割を担う。プロトコルにあらかじめ組み込まれた署名方式に限定せず、用途に応じた認証方式を実装できるようにする。
ただし、オーセンティケーターは通常のスマートコントラクトのように自由に動作できるわけではない。認証処理はブロックチェーンの状態を読み書きできない制限された環境で実行され、使用できるガスにも上限が設けられる。
これにより、認証方法を柔軟に設計できる余地を残しながら、オーセンティケーター署名の検証に必要な計算量を一定の範囲に収める。ノードやL2のシーケンサーなどは、認証処理に必要な最大コストを事前に把握しやすくなるとのこと。
EIP-8397ではさらに、「提示された署名などが正しいか」という認証と、「その認証方法をアカウントが受け入れるか」という認可を分離する仕組みが提案されている。プロトコル側ではオーセンティケーターが暗号学的な証明を検証し、その認証を自身のアカウントで認めるかどうかはEIP-8141の「VERIFY」フレームを使ってアカウント側が判断する。この仕組みにより、計算負荷の大きい暗号学的な認証は一定の条件下で処理しつつ、どの認証方法を受け入れるかといったアカウントごとのルールは柔軟に設計できるとのことだ。
L1とL2で利用できるAAを巡り議論
EIP-8397が提案された背景では、イーサリアムのL1とL2の双方で利用できるAAをどのように実現するかについて議論が進んでいる。
現在はEIP-8141のほか、米コインベース（Coinbase）のクリス・ハンター（Chris Hunter）氏が提案した「EIP-8130：アカウント・アブストラクション・バイ・アカウント・コンフィギュレーション（Account Abstraction by Account Configuration）」もAAの実装方式として議論されている。
EIP-8141がEVMを使って検証方法を柔軟に定義できる設計を採用する一方、EIP-8130ではトランザクションの認証に使用するオーセンティケーターを識別できる仕組みを採用している。EIP-8130ではL1とL2で異なる要件に対応する仕組みも設けられており、L2向けのトランザクションでは利用できるオーセンティケーターを限定することで、検証コストの予測可能性を高められる。
両提案を巡る議論では、L1で求められる認証方法の拡張性と、大量のトランザクションを扱うL2で求められる検証処理の予測可能性をどう両立するかが論点となっている。EIP-8141側でもL2からの意見を受け、状態に依存せず一定のコストで認証できる仕組みの検討が進められてきた。EIP-8397は、こうした方向性に沿った提案となっている。
またイーサリアムのコア開発者らは8月27日に開催された会議で、EIP-8141を次期大型アップグレード「ヘゴタ（Hegotá）」の「Scheduled for Inclusion（SFI）」に移すことで合意した。これにより、ヘゴタでAAを導入する方針が示された一方、現在のEIP-8141の仕様がそのまま採用されると決まったわけではない。AAの具体的な仕様を巡る議論は続いており、採用されるEIPやトランザクション形式などが今後変更される可能性もある。
New EIP!
— ethresearchbot (@ethresearchbot) August 26, 2026
Frame Authenticator Signatures
🔗 https://t.co/4EaIdG1Aef
Highlights:
– Introduces a new EIP-8141 signature scheme (0x03) called AUTHENTICATOR: the signature’s “signer” is an authenticator contract address, and the signature bytes are `key_id (32 bytes) || proof`.
-…
AA update: The Frame Transactions EIP was moved today to Scheduled status for the Hegotá upgrade. It was proposed as a headliner and moved in March of this year to Considered status. There was strong consensus that it was important to ship Account Abstraction in Hegotá even if…
— nixo.eth (@nixorokish) August 27, 2026
TLDR: Frames (8141) was just SFI-ed, but it was only meant to signal that Ethereum WILL ship AA in Hegota. It does NOT mean that Frames as written, or even the final EIP number, are set in stone.
— Derek Chiang | Ethlabs (@decentrek) August 27, 2026
In the ACDE I was pushing against making the SFI decision now, given that the… https://t.co/WvRzQtYJ2I
参考：EIP
画像：PIXTA