Cabinet
テクノロジーインサイト一覧へ戻る
2026.08.27

EIP-8141 が Hegotá の Scheduled for Inclusion へ ― ただし提案者自身が「仕様も EIP 番号も確定ではない」と述べている

EIP-8141 が Hegotá の Scheduled for Inclusion へ ― ただし提案者自身が「仕様も EIP 番号も確定ではない」と述べている

何が起きたか

Hegotá は Glamsterdam に続く Ethereum のネットワークアップグレードで、Glamsterdam が2026年第4四半期へ後ろ倒しされたことに伴い、ethereum.org の公式ロードマップ上は2027年に置かれている。

スコープ策定は二段階で進んでいる。第一段階でコンセンサス層のヘッドライナーとして EIP-7805（FOCIL、Fork-choice enforced Inclusion Lists）が選定された。8月6日が非ヘッドライナー EIP の提案締切で、そこから ACD プロセスが全体像の評価へ移った。研究者 Toni Wahrstätter は8月16日、66件の提案が議論の俎上にあると述べている。これは66件が承認済みという意味ではない。大半は PFI（Proposed for Inclusion）段階で、提案自体はパーミッションレスに行える。

8月13日の ACDE 議題は、この66件を絞り込むためにおよそ2週間を割り当てた。PFI リストは8月27日ごろに確定し、明確な推進者がいない提案は自動的に見送りとなる。クライアントチームは9月10日までにランク付けした優先度を提出することになっている。

そのうえで、8月25日にアカウント抽象化の技術ブレイクアウトが開かれ、EIP-8141 と EIP-8130 が比較された。8月27日の ACDE で EIP-8141 は CFI から SFI へ移った。開発者 nixo.eth は、この提案が今年3月に Considered へ移っていたこと、そして Hegotá でアカウント抽象化を出すことが重要だという強い合意があったことを述べている。

EIP-8141 は Frame Transactions と題された提案で、新しいトランザクション型を導入し、一つのトランザクションを VERIFY フレームと一つ以上の EXECUTE フレームに分割する。ノードはメンプールへの受け入れ前に実行のシミュレーションを行う必要がある。既存の EOA との後方互換は維持され、アドレスを変える必要はなく、既存の EIP-1559 トランザクションも有効なままである。

何を解こうとしているのか

アカウント抽象化そのものは新しくない。ERC-4337 は2023年3月に Final となり、EntryPoint コントラクトとバンドラを使ってコンセンサス層に触れずに実現した。2025年の Pectra で入った EIP-7702 は、既存の EOA が一時的にコントラクトコードへ委任できるようにした。2026年半ば時点で、スマートアカウントの展開数は Ethereum とロールアップ全体で3,000万を超えるとされる。

にもかかわらず L1 への組み込みが議論されるのは、アプリケーション層に留めておくと断片化と合成可能性の制約が残るからである。ERC-4337 の UserOperation は通常のトランザクションと別のメンプールを流れ、EntryPoint を経由するぶんガスが上乗せされる。同等の EOA トランザクションに対して30〜50%程度高くつくという見積もりがある。プロトコルに組み込めば、この上乗せと別メンプールの運用が不要になる。

Frame Transactions の設計上の焦点は、検証と実行を明示的に分けた点である。任意の検証ロジックを許すと、メンプールに入れる時点で「このトランザクションは手数料を払えるか」が判定できなくなり、DoS の口になる。VERIFY フレームを分離し、受け入れ前にシミュレーションを義務づけるのは、この判定可能性を回復するための設計である。裏返せば、ノードの負担はメンプール受け入れ段階で増える。バリデータ側はクライアント、メンプールポリシー、ブロック選択ロジックの更新が必要になる。

代替案とのトレードオフ、そして実装までの距離

同じ ACDE で異論も記録されている。Ethlabs の研究者 Derek Chiang は、8141 の SFI 化は「Ethereum が Hegotá でアカウント抽象化を出す」という意思表示にすぎず、Frames が書かれたとおりの仕様で確定したわけでも、最終的な EIP 番号が決まったわけでもないと述べ、この時点で SFI 判断を下すことに会議中は反対していたと明言している。競合案 EIP-8130 への支持と、Frame Transactions に対する未解消の異論が残っているという趣旨である。

EIP-8130 は Coinbase / Base 側が推す案で、9月に Base で稼働する予定とされる。つまり、L2 が L1 より先にアカウント抽象化方式を実装する。Hegotá が2027年である以上、同じアドレスが L1 と L2 で異なる振る舞いをしうる期間が1年以上続く可能性がある。この断片化を避けるため、二案の統合、あるいは Frame Transactions の上に 8130 形式のアカウントを構築して L1 と L2 で同一の振る舞いにする、という二つの道筋が検討されている。進捗は毎週火曜 14:00 UTC のアカウント抽象化ブレイクアウトと Forkcast のダッシュボードで追える。

Hegotá 全体の絞り込みでは、Ethlabs が四つの優先順位を提示している。FOCIL、より短いスロット時間、ネイティブアカウント抽象化、L1 スケーリングである。過積載のハードフォークを繰り返さない、という趣旨だ。同グループは EIP-8182（ETH と ERC-20 の秘匿送金）を最下位に置き、Hegotá からの除外を推奨した。ゼロ知識への依存を持ち込む大きな変更であり、進めるならヘッドライナーとして扱うべきだという理由である。EIP-8375（ePBS 下で外部ビルダー入札の総額の一部を焼却する提案）については、サイドチャネル決済を促しうると警告し、MEV バーン設計は長年の研究にもかかわらず広い合意を得た案が出ていないと述べている。EIP-8363（ステーキング比率の上昇に応じてバリデータ報酬の焼却割合を増やす提案）については、ランク付け自体を辞退した。金融政策は通常の技術的スコープ判断ではなく、より広い議論に委ねるべきだという立場である。

このほか、ガスリミット引き上げに備えてブロックの肥大を抑える提案群がある。EIP-8131 はユーザーが制御するバイトごとに最低64ガスを課し、EIP-8279 は同様の会計をブロックアクセスリストのデータへ広げる。EIP-8368 は、ガスリミットが既存の参照水準を超えて引き上げられた場合に、状態成長の価格設定を再較正する。

想定される落とし穴

第一に、SFI は「この仕様で出す」ではなく「この機能を出す」という宣言である。今回はその区別を提案側自身が明言している。EIP-8141 の現行テキストに対して実装を始めると、番号ごと差し替わる可能性がある。ステータス表記を追うだけでは、この不確実性は見えない。

第二に、L2 が先行する。Base で9月に 8130 が動き始めるということは、L1 が2027年に何を採用するかにかかわらず、スマートアカウントの実装者はまず 8130 に対応する経済的動機を持つということである。仮に統合が実現しなければ、既存の資産が先行実装の側に積み上がった状態で L1 の仕様が決まることになる。

第三に、9月10日の提出物は「決定」ではなく「クライアントチームの優先度」である。ここに載ったことをもって採用と読むと、実際の絞り込み結果と食い違う。同様に、明確な推進者がいない提案は自動的に見送られるため、8月27日時点の PFI リストから消えた提案は「否決された」のではなく「推進者がいなかった」場合がある。

第四に、Hegotá のスコープは Glamsterdam の進捗に従属している。Glamsterdam は当初の2026年上期から二度後ろ倒しされ、第4四半期になった。同じスコープ管理の失敗が繰り返されれば、Hegotá の2027年も動く。社内のロードマップに2027年を固定値として置くのは早い。

【技術インサイトとアクション】

  1. ステータス表記（PFI / CFI / SFI）は「合意の強さ」を表すが、「仕様の確定度」とは独立している。今回の SFI は機能を出す意思の表明であって、仕様のフリーズではない。この二軸を混同すると、まだ動く仕様に対して実装工数を先に投じることになる。ステータスだけを追う社内トラッキングは、この区別を落とす。 ［テックリード・アーキテクト］ 社内のプロトコル動向トラッキングに「ステータス」と「仕様の安定度」の2列を分けて持ち、EIP-8141 については9月10日のクライアント優先度提出結果を確認するまで、実装着手ではなく設計レビューに留める。
  2. L2 が L1 より先に同種の機能を実装する構図では、同じアドレスがレイヤーによって異なる振る舞いをする期間が生じる。スマートアカウントの前提でアドレスの挙動を扱っているアプリケーションは、L1 と L2 で同一の署名・検証ロジックが通ることを暗黙に仮定していると、この期間に壊れる。 ［ウォレット・アプリケーション開発者］ EIP-8130 が Base で稼働する9月中に、自社のアカウント抽象化まわりの実装がレイヤーごとに異なる方式へ分岐できる構造になっているかを確認し、単一方式を前提にした抽象化を持っている場合は分岐点を設ける。
  3. Frame Transactions はメンプール受け入れ前のシミュレーションを必須とするため、ノードの負担が受け入れ段階へ前倒しされる。任意の検証ロジックを許すことと、メンプールの DoS 耐性を保つことの折り合いが、この設計の本体である。RPC プロバイダやメンプール監視を運用している側にとっては、Hegotá の実質的な影響はここに出る。 ［ノード運用者・RPC 事業者］ 2026年内に、メンプール受け入れ時のシミュレーション負荷を見積もるための計測項目（受け入れ判定のレイテンシ、拒否率、シミュレーション実行時間）を現行環境で先に取得し、比較基準を作っておく。

【引用：出典】

本記事は公開情報に基づく技術解説であり、投資助言を目的としたものではありません。