EIP-8141、鍵を替えられない口座から降りる｜決定は9日前

Last Updated on 2026年9月9日 by Co-Founder/ Researcher

ブテリンの週末の投稿を「新しい提案」として報じた記事が並びました。ただ、その9日前に、コア開発者はこの設計をHegotáへ入れる方向をすでに決めています。順序が逆です。決まったあとで本人が語ったのは、鍵を替えられない口座から降りる、という話でした。

イーサリアムの共同創設者ヴィタリック・ブテリンは2026年9月5日、Xでトランザクションの構造に関する整理を示した。トランザクションが起こす効果を「アクション」、その効果が正当であるために満たされるべき条件を「依存関係」と呼び分け、署名やMerkle証明などの依存関係は並列に処理できるとした。状態に触れない「純粋な依存関係」はmempoolで一度だけ検証し、将来はSTARK証明で置き換えうるという。

投稿が指すEIP-8141「Frame Transaction」は、検証・ガス支払い・実行をフレームに分解する新形式で、8月27日のACDE第244回でHegotáアップグレードのScheduled for Inclusionへ移っている。仕様はDraftのままで、起動時期は未定である。

From: Vitalik Buterin reveals Ethereum’s transaction redesign

SFIへ進める方向が示されたのは、投稿の9日前でした

週末の投稿を「新しい提案」として読むと、順序を取り違えます。イーサリアムのコア開発者は2026年8月27日、ACDE（All Core Developers Execution）第244回で、EIP-8141をConsidered for InclusionからScheduled for Inclusionへ進める方向を示しました。Hegotáアップグレードの中身を管理する公式文書EIP-8081の同じ欄には、9月7日時点でFOCIL（EIP-7805）とEIP-8141の2本が記載されています。

つまり、アカウント抽象化をHegotáで出すという方向は、すでに開発者のあいだで共有されています。9月5日の投稿は、その決定が何を意味するのかを本人が言葉にしたものです。海外報道の一部は、この順序を逆に伝えています。

「アクション」と「依存関係」は何を分けているのか

いまのイーサリアムでは、署名の検証、手数料を払えるかの確認、そして実際の処理が、ひとつの流れのなかで扱われます。ブテリンの整理は、この流れを2つに割ります。

ETHを送る、コントラクトを呼ぶといった効果が「アクション」です。その効果が正当であるために真でなければならない条件が「依存関係」です。投稿を報じた複数の媒体によれば、依存関係の例として挙げられたのは、署名、UTXOの存在を示すMerkle証明、そしてSNARKやSTARKといった証明でした。

分けると何が変わるのか。依存関係どうしは、互いを待つ必要がありません。あるトランザクションの署名検証は、別のトランザクションの署名検証の結果を知らなくても進められます。並列に処理できる、というのはこの意味です。

さらに、状態にいっさい触れない依存関係があります。署名が正しいかどうかは、誰の残高がいくらであろうと変わりません。ブテリンはこれを「純粋な依存関係」と呼びます。mempoolの段階で一度だけ検証し、その結果を再帰的なSTARK証明にまとめてしまえば、将来は同じ計算を各バリデーターが繰り返さずに済む可能性がある。報じられている説明は、この筋道です。証明が成立すれば、元のデータそのものを省略できる余地も出てくるといいます。

鍵を替えられない口座から降りる

EIP-8141の共著者の一人であるlightclientは、ブテリンが読者に指し示した9月5日の技術メモで、設計目標を7つ挙げています。そのうち3つが、Crypto Verseの評価軸と正面から重なります。

第一に、鍵のローテーションです。lightclientはこれを「元のプロトコルの最も重大な欠落のひとつ」と表現しています。イーサリアムのEOA（外部所有アカウント）には、EIP-7702が動き出したあとも、アカウントと認証鍵をプロトコル上で切り離して直接ローテーションする仕組みがありません。鍵漏えい時の回復は、プロトコル本体ではなく、委譲コードやウォレット実装に委ねられたままです。

第二に、暗号方式の機動性です。どの署名方式に自分の資産を託すかを、ユーザー自身が選べるようにする。lightclientはこれを「定食メニュー」ではなく「部品」を渡すと書いています。異なるアルゴリズムを混ぜたマルチシグも視野に入っています。

第三に、リレーヤー不要であることです。ここが、この設計のいちばん奥にある思想だと考えます。

特定の中継主体に依存せずに済ませる

アカウント抽象化そのものは新しい考えではありません。2023年から動いているERC-4337は、ハードフォークなしに同じ体験を実現しました。その構造では、UserOperationが通常とは別の公開mempoolで扱われ、Bundlerがそれを束ねて通常のトランザクションへ変換します。Paymasterを使えば、利用者に代わってガス代を払うこともできます。いずれも誰でも運営できる役割ですが、取引が届くかどうかは、その役割を担う主体がいることを前提とします。

EIP-8141は、特定の第三者リレーヤーに依存せず、通常のパブリックmempoolで一般的なユースケースを扱うことを、プロトコル側の設計目標に据えています。仕様のmempool規則は、ERC-7562に着想を得ながらも、ステーキングと評判システムを完全に取り除きました。lightclientは「一般的なユースケースはすべて、デフォルトでパブリックmempoolがサポートしなければならない」と書き、その理由として、パブリックmempoolこそがイーサリアムの検閲耐性を担保する鍵だからだと述べています。プライバシープールの利用も、リレーヤーなしで成り立たせる対象に含まれています。

自分の鍵を自分で持てるかどうかは、ウォレットの話です。しかし自分の取引を、特定の中継主体に頼らずネットワークへ流せるかどうかは、プロトコルとmempool設計の両方にまたがる話です。8141が触っているのは後者のほうです。

日本の読者にとって、どこが効いてくるか

短期的には何も変わりません。EIP-8141はメインネットで動いておらず、現在のロードマップでは、HegotáはGlamsterdamに続くアップグレードとして位置づけられています。

効いてくるのは、その先の3つだと見ています。

ひとつは、ウォレットと決済基盤の作り替えです。フレームトランザクションでは、ガスの見積もりが「実行ガス」と「状態ガス」の二次元になり、しかもフレームごとに別々の枠として宣言します。片方の枠から他方へ融通することはできません。国内でウォレットやオンチェーン決済を手がける事業者にとっては、見積もりロジックそのものの設計変更にあたります。

ふたつめは、耐量子への移行経路です。EIP-8141は動機の冒頭で、今日の楕円曲線ベースの認証から耐量子方式へ移行できる道を挙げています。lightclientの説明では、耐量子署名は2キロバイトから10キロバイトに達しうるため、そのままでは手数料が現実的な水準に収まりません。だから署名の集約が要る、という順序で設計されています。この媒体が3月に扱った量子耐性ロードマップは、いま実装側の器を得ようとしている段階です。

みっつめは、ORIGINの挙動です。フレームトランザクションではORIGINがフレームの呼び出し元を返すため、tx.originとmsg.senderの一致を安全確認に使っているコントラクトは、挙動が変わりえます。仕様はこれを推奨されないパターンと位置づけていますが、該当するコードを抱えるプロジェクトは、いま棚卸ししておく価値があります。

封筒は解けた。次は標準形

Scheduled for Inclusionは、仕様が確定したという意味ではありません。採用手続きを定めるEIP-7723は、この段階を、コア開発者が次のアップグレードへ入れる強い意思で一致し、かつ仕様と実装が一定の成熟度に達したと合意した状態、と定義しています。示しているのは不測の事態がなければ入る見込みであって、EIP-7723自身が、SFIからConsidered for Inclusionへ、あるいはDeclined for Inclusionへ戻す道も用意しています。

ACDE第244回でも、仕様や実装、場合によってはEIP番号まで変わりうるとの留保が付きました。共著者の一人であるデレク・チャン氏は、この時点でSFIの判断を下すことに反対していました。並行して検討されているEIP-8130（Keystore Accounts）との相互運用性も、論点として残ったままです。

ブテリンが挙げた「取引量ベースで90%超は完全な動的性を必要としない」という数字も、ネットワーク全体の測定値ではなく、本人の見積もりです。手数料についても、静的に解析できる取引ほど安くすべきだという設計方針が語られているだけで、どの取引がいくら安くなるという約束はまだありません。Hegotáの起動時期も、EIP-8081の起動テーブルはSepolia、Hoodi、メインネットのいずれも空欄のままです。

それでも、8月末からの10日あまりで、位置づけは確実に変わりました。lightclientはメモをこう締めています。フレームはEVMへの最後の変更ではないが、アカウントに関して必要な最後のトランザクション型であるべきだ、と。有効期限の指定、プライバシープールからの引き出し、取引内容の事前検証、口座の全額送金、署名の集約。彼が例として並べた拡張は、いずれも新しいトランザクション型を必要としません。封筒はもう設計されており、これから作られるのは、その中に入る標準形のほうです。

2015年のイーサリアムは、鍵ひとつと直列実行で足りる世界を前提に組まれました。11年をかけて、その前提そのものを組み直す作業が、ようやく実装の段階に入ったことになります。

アカウント抽象化（Account Abstraction）
口座の認証方法、手数料の支払い方、処理の実行を、固定のルールではなく利用者側で定義できるようにする考え方。イーサリアムでは長らくアプリ層のERC-4337が担ってきた。EIP-8141はこれをプロトコル本体へ持ち込む提案である。lightclientは「バリデーション抽象化」という呼び方のほうが実態に近いとしている。

フレームトランザクション（Frame Transaction）
EIP-8141が定義する新しいトランザクション形式。トランザクションを「フレーム」と呼ぶ複数のコントラクト呼び出しへ分解し、それぞれが検証・ガス支払いの承認・利用者操作の実行を担う。トランザクション型は0x06。フレームは1件のトランザクションにつき最大64件まで。

Scheduled for Inclusion（SFI）
EIPがネットワークアップグレードへ採用される過程の一段階。EIP-7723は、コア開発者が次のアップグレードへ入れる強い意思で一致し、かつ仕様と実装が一定の成熟度に達したと合意した状態と定義する。仕様の確定を意味しない。前段階のConsidered for Inclusionや、除外を意味するDeclined for Inclusionへ戻ることもある。

ACDE（All Core Developers Execution）
イーサリアムの実行層を担当する開発者が集まる定例会議。EIPの採用段階の変更は、この場か、合意層のACDCで確認される。

Hegotá
Glamsterdamに続くとされるネットワークアップグレードの呼称。採用状況はメタEIPであるEIP-8081が管理する。2026年9月7日時点で、起動時期を記す欄は空欄のままである。

mempool（メモリプール）
ブロックへ取り込まれる前のトランザクションを、各ノードが一時的に保持する領域。誰でも接続できるパブリックmempoolは、特定の中継業者を経由せずに取引をネットワークへ届ける経路にあたる。

EOA（Externally Owned Account／外部所有アカウント）
秘密鍵ひとつで制御される従来型のイーサリアムアカウント。コントラクトアカウントと異なり、独自の検証ロジックを持たない。

Bundler / Paymaster
ERC-4337の構造に登場する役割。BundlerはUserOperationを束ねて通常のトランザクションへ変換し、Paymasterは利用者に代わって手数料を負担する。いずれも誰でも運営できるが、取引が届くにはその役割を担う主体が必要になる。

ERC-7562
ERC-4337のmempoolにおいて、無効な送信の負荷を抑えるための検証規則を定めた文書。ステーキングと評判システムを用いる。EIP-8141はこの規則に着想を得つつ、両者を採用していない。

STARK
ある計算が正しく行われたことを、計算をやり直さずに確かめられる暗号学的証明。証明どうしを再帰的に検証できるため、多数の検証を小さな1件へまとめる用途に用いられる。

UTXO（Unspent Transaction Output）
ビットコインが採用する残高管理の方式。使い残しの出力を指定して使う。口座残高を持つイーサリアムのアカウントモデルとは前提が異なる。

Merkle証明
ハッシュを階層状に集約した木構造を用い、あるデータが集合に含まれることを、集合全体を渡さずに示す方法。

検閲耐性
特定の主体の判断によって、取引がブロックへ取り込まれない事態を防ぐ性質。パブリックmempoolと、Hegotáで同時にSFIとなったFOCIL（EIP-7805）は、いずれもこの性質を支える仕組みである。

実行ガスと状態ガス
EIP-8037が導入した二次元のガス計測。実行ガスは計算やデータの処理量を、状態ガスはチェーン上に永続的に残る状態の増加量を測る。フレームトランザクションでは、この2つをフレームごとに別々の枠として宣言し、枠のあいだで融通することはできない。

ORIGIN
トランザクションの発信元を返すEVMの命令。フレームトランザクションでは、フレームの呼び出し元を返す挙動へ変わる。

耐量子（Post-Quantum）暗号
量子コンピューターによる攻撃にも耐えうるとされる暗号方式の総称。現行のECDSA署名より署名が大きくなる傾向があり、lightclientの説明では2キロバイトから10キロバイトに達しうる。

プライバシープール
入金と出金の結びつきを隠しつつ、資金の由来について一定の証明を可能にする仕組み。EIP-8141は、これを中継者なしでパブリックmempoolから使えるようにすることを設計目標に含めている。

EIP-8141: Frame Transaction（外部）
フレームトランザクションの公式仕様。トランザクション型0x06、フレームの3モード、mempool規則までを定める。Draft段階。

EIP-8081: Hardfork Meta – Hegotá（外部）
Hegotáアップグレードの採用状況を管理する公式文書。SFI欄にFOCILとEIP-8141が並ぶ。起動時期の欄は空欄のまま。

EIP-7723: Network Upgrade Inclusion Stages（外部）
EIPが採用されるまでの段階を定義した文書。SFIの2条件と、SFIから前段階へ戻す手順もここにある。

EIP-8130: Keystore Accounts（外部）
EIP-8141と並行して検討されているアカウント抽象化案。認証子コントラクトを鍵管理契約に登録する設計を採る。

Frames are all you need（lightclient）（外部）
EIP-8141共著者による設計解説。鍵のローテーション、暗号方式の機動性、リレーヤー不要など7つの目標を示す。

Vitalik Buterin（X／2026年9月5日）（外部）
ブテリンが9月5日に投稿した本文。アクションと依存関係の定義、純粋な依存関係のSTARK置き換えを述べている。

Frame Transaction（Ethereum Magicians）（外部）
EIP-8141の議論スレッド。仕様への異論、mempool規則の詰め、他案との比較が継続して投稿されている。

ERC-4337: Account Abstraction Using Alt Mempool（外部）
Bundlerとpaymasterを用いるアプリ層のアカウント抽象化規格。EIP-8141が置き換えを目指す前提となる。

Vitalik Buterin Says 90% of Ethereum Activity Doesn’t Need Full Dynamism（外部）
投稿のタイムスタンプ、前後の投稿、参照先の技術メモまで特定した記事。仕様定数の変遷にも触れている。

ACDE 244（外部）
ACDE第244回の会議ノート。SFIが仕様を凍結しない点と、L2側の断片化懸念が記録されている。

Ethereum core developers schedule EIP-8141 for Hegotá upgrade（外部）
EIP-8141のSFI移行を報じた記事。Hegotáの提案数と、クライアントチームの提出期限を数値で示している。

イーサリアム「EIP-8397」提案、AA実現に向け認証方式を拡張（外部）
EIP-8397の提出を報じた日本語記事。EIP-8141へ新しい署名方式を追加する提案の位置づけがわかる。

Ethereum (ETH) Core Developers Lock Account Abstraction EIP-8141 Into Hegotá Upgrade（外部）
SFI決定の場でのやりとりを整理した記事。共著者からの異論と、司会側の説明が並べて記録されている。

EIP-8141「Frame Transaction」のHegotá SFI移行と鍵のローテーション設計を、より広い文脈で理解するための関連記事をご案内します。Ethereumプロトコル改革・他基盤の改革対比・セルフカストディの鍵管理・AI時代の決済インフラを横断的に読むことで、「アカウント抽象化がプロトコル本体に降りてくる」意味が立体的に見えてきます。

Ethereumプロトコル改革

• Ethereum「Lean Ethereum」始動—ブテリンが量子耐性・プライバシー・拡張性を最優先に → 本記事のEIP-8141動向と直接連動する、Ethereum本体側のプロトコル改革全体像。「Lean Ethereumの量子耐性ロードマップ」と「EIP-8141の暗号方式機動性」の関係を両記事併読で立体的に理解できます。
• Robinhood Chainがメインネット始動｜Chainlinkが支える新金融 → 本記事の基盤動向と並ぶ、Ethereum L2上での金融プラットフォーム動向。「L1本体改革」「L2実装」両軸を理解できます。
• Polygonが直してから話した理由—非公開で先に配る手順が残した記録 → 本記事のHegotáアップグレード動向と並ぶ、Polygon L2側のプロトコル改革運用事例。

他基盤プロトコル改革の対比軸

• BlackRock・Strategy・Coinbaseら9社が Bitcoin Security Consortium 設立、量子対策を含むセキュリティ開発へ3年1500万ドル → 本記事の耐量子移行経路動向と対比される、BTC 9社連合による長期セキュリティ動向。「Ethereum改革」「BTC 9社連合」の対比を理解できます。
• XRPL機密送金、5億ドル市場と対象規格にずれ → 本記事のプロトコル改革動向と並ぶ、XRPL本体側の直近改革動向。「アカウント抽象化（Ethereum）」「機密送金（XRPL）」の対比を理解できます。
• Solanaが400ミリ秒の壁を破った日―メインネットで350ミリ秒への切替が完了 → 本記事のプロトコル改革動向と並ぶ、Solana本体側の改革動向。
• ECX、ビットコインフォーク3段階のリプレイ・報酬設計を読む → 本記事のプロトコル改革動向と並ぶ、BTCフォーク設計動向。「本体改革」「派生フォーク」のガバナンス手法の対比を理解できます。

セルフカストディ・鍵管理

• MetaMask Agent Wallet の「セルフカストディ」を検算する—鍵の置き場所とガードレールの射程 → 本記事のEIP-7702（委譲コード）動向と直接連動する、AIエージェント×セルフカストディの実装事例。「プロトコル本体で鍵管理」「ウォレット実装で鍵管理」の対比を理解できます。
• Coldcardのシード生成に欠陥、第4波疑いを含め約1,816 BTC流出の暫定推計—競合取引は被害者と攻撃者の双方の手段に → 本記事の「鍵漏えい時の回復」議論と対をなす、鍵生成の脆弱性事案。「鍵をローテーションできない」現実の重さを理解できます。
• SecondFi始動｜「鍵は自分のまま」EMURGOが挑む、暗号資産で使う・貯める・稼ぐ時代 → 本記事の設計目標「鍵のローテーション」と並ぶ、セルフカストディ型サービスの実装事例。

AI×Web3・自律エージェント決済・ガス支払い

• Cloudflare「Monetization Gateway」―x402・ステーブルコインでリクエストを取引に → 本記事の「リレーヤー不要」設計目標と関連する、AIエージェント決済インフラ動向。「ペイマスタ不要でパブリックmempool」の意味を実装事例から理解できます。

セキュリティ・スマートコントラクト検証

• アライドアーキテクツ × Nyx Foundation、AIがDeFiの安全を”検算”する時代へ → 本記事のmempool検証規則動向と並ぶ、AI×形式検証によるオンチェーン安全性検証動向。

トークン設計・OFT・Base関連

• $LAPTOP、CLARITY法の名を供給条件に掲げる─細則が判定するのは市場構造法一般 → 本記事の直近姉妹記事。「Base×OFT（LayerZero）」「Ethereum本体×Frame Transaction」の設計対比を理解できます。

EIP-8081の提案一覧を眺めていて、目が留まった行があります。「EIP-8250 Keyed Nonces for Frame Transactions」と「EIP-8272 Recent Roots for Frame Transactions」。どちらも名前にFrame Transactionsを抱えています。

本体がまだ草案の段階で、それを前提にした提案が2本、すでに順番待ちの列に並んでいます。仕様が固まる前から、その上に建てるつもりでいる人たちがいるということです。

——————–
※本記事は情報提供を目的としており、投資助言ではありません。
　詳細は当サイトの免責事項をご確認ください。
——————–