Ethereumの次期大型更新「Hegotá（ヘゴタ）」で採用予定の中心機能は、FOCIL（EIP-7805）とFrame Transaction（EIP-8141）の2つです。今は一つのブロック作成者に取引を外され続ける余地があり、秘密鍵とガス代支払いの形も固定的です。更新後は複数バリデータの包含要求が働き、認証方法と支払者をアカウント側のコードで設計できる方向へ進みます。
実施は2027年第2四半期の見込みですが、メインネットの起動日時は未定です。まず利用者に関係する変化をつかみ、その後に開発・運用上の条件を確認していきましょう。
この記事を読むと、FOCILとFrame Transactionの仕組み、一般利用者・ウォレット開発者・バリデータへの影響、公式情報を追うときの確認点が分かります。価格予測ではなく、プロトコル更新の内容を判断するための技術的な地図として活用してください。
Ethereumの次期大型更新Hegotáで何が決まっているのか
Hegotáは、Glamsterdamに続くEthereumのプロトコル更新です。名称は実行層側の更新名とコンセンサス層側の更新名を組み合わせた呼び方で、複数のEIP（Ethereum Improvement Proposal）を一つのハードフォークとして導入する枠組みを指します。アプリや通貨が新しく発行されるという意味ではありません。
Q2 2027は見込みであり起動日時は未定
ethereum.orgのロードマップはHegotáを2027年第2四半期の見込みとして案内しています。一方、Hegotáの構成を管理するメタEIPであるEIP-8081では、Sepolia、Hoodi、メインネットの起動epochや時刻が未記入です。したがって「2027年第2四半期に必ず実施される」「特定の日に切り替わる」とは言えません。
ハードフォークの日程は、仕様の成熟、複数クライアントの実装、テスト、開発者会議での合意などを経て具体化します。検索結果やSNSに予定月が表示されても、起動時刻が公式仕様へ入ったか、テストネットで問題なく動いたかを別途確認する必要があります。予定は理解の目安であって、送金や資産移動を急がせる締め切りではありません。
採用予定はEIP-7805とEIP-8141の2件
2026年9月25日時点のEIP-8081では、採用予定の区分にFOCIL（EIP-7805）とFrame Transaction（EIP-8141）が置かれています。FOCILはコンセンサス側から取引の包含を後押しし、Frame Transactionは実行側で取引とアカウントの能力を広げます。別々の課題を扱う一方、将来の取引形式を検閲されにくい形でネットワークへ届けるという点で関係します。
「採用予定」は、記事執筆時点の公式な構成上の位置づけです。仕様や実装が一切変わらないという保証ではありません。また、候補一覧に載ることと採用予定になることも同じではありません。ニュースを読む際は、EIP番号だけでなく、そのEIPがどの区分にあるかを見ると誤解を減らせます。
EFの優先度評価と正式な採用決定は異なる
Ethereum Foundation（EF）のProtocolチームは、候補EIPの優先度や組み合わせについて見解を公開しています。これは技術的な論点を理解する重要資料ですが、EFの評価だけでハードフォークの採用が決まるわけではありません。AllCoreDevsでの議論、仕様の状態、クライアント実装、テスト結果などが積み重なって構成が固まります。
EIP-8081で使われる区分も確認しましょう。SFIは採用予定、CFIは採用を検討する段階、PFIは提案された段階、DFIは当該フォークへの採用を見送る区分です。名称が有望に見えることや、EFの評価が高いことを、SFIと読み替えてはいけません。
FOCILは取引の検閲耐性をどう高めるのか
まなぶ「クリプ先生、検閲耐性って、どんな取引でも必ず通すという意味なんですか？」
クリプ「そうではないよ。無効な取引まで通すのではなく、有効な取引を特定の作成者が外し続ける力を弱める考え方なんだ。」
FOCILは「Fork-choice enforced Inclusion Lists」の略です。直訳すると、フォーク選択規則によって強制される包含リストとなります。ここでいう包含とは、有効な取引をブロックへ収録することです。ネットワークへ送った取引が正当でも、ブロック作成を担う主体が意図的に選ばなければ、処理が遅れたり排除されたりする余地があります。
複数バリデータが作る包含リスト
現在のブロック作成では、提案者と外部ビルダーなどの役割分担により効率化が進む一方、取引選択の影響力が限られた主体へ集まり得ます。FOCILでは、複数のバリデータが「次のブロックに含めるべき取引」のリストを作ります。一人の判断だけでなく、委員会の複数参加者から候補を集める点が重要です。
リストに載れば無条件で実行されるわけではありません。残高不足、nonceの不整合、ガス条件など、取引としての有効性は必要です。また、ブロックの容量や仕様上の条件もあります。FOCILが狙うのは、有効で収録可能な取引が恣意的に無視される状況を減らすことであり、プロトコルの検証規則を迂回する仕組みではありません。
要件を満たさないブロックには投票しない
包含リストに強制力を持たせるのがfork choiceです。fork choiceは、同時に候補となるチェーンが見えたとき、どれを正当な先頭として選ぶかを定める規則です。EIP-7805の設計では、アテスターは有効な包含リストの要件を満たさないブロックに投票しません。ブロック提案者やビルダーにとっては、対象取引を理由なく外すと支持を得にくくなる構造です。
罰金のように後から処分するだけではなく、ブロックを選ぶプロセスに包含条件を組み込むため、「enforced」と呼ばれます。ただし、ネットワーク遅延などでリストが届かなかった場合まで単純に不正扱いすると、正常なブロック生成を損ねます。そのため、伝播時間、有効性判定、容量の扱いは実装上の要点になります。
単独ビルダーに集中する検閲力を弱める狙い
FOCILの価値は、ある一人のビルダーが取引選択を支配する状態から、複数のバリデータが包含へ関与する状態へ寄せることです。特定アドレスとの取引、特定アプリの呼び出し、ある地域から発信された取引などを単独主体が外し続ける能力を弱める狙いがあります。
一方で、検閲の可能性がゼロになるわけではありません。多数の参加者が同じ取引を避ける場合、取引自体が無効な場合、ネットワークへ十分に伝わっていない場合などは別問題です。FOCILは検閲耐性を高める一層の仕組みであり、通信、参加者分散、クライアント実装を含む全体の健全性が引き続き必要です。
FOCILの実装課題：運用者が確認する3点
ここからはバリデータ・ノード運営者向けの補足です。一般利用者は「通信遅延」「矛盾するリスト」「検証負荷」の3点がテスト対象だと押さえれば十分です。
通信遅延とビルダー接続性
複数バリデータの包含リストは限られたスロット時間内に伝わる必要があります。到着が遅れると、同じブロックを見ても要件を満たすかの判断が参加者間で割れかねません。ビルダー側にも、対象取引を受信し、検証してペイロードへ組み込む接続性が必要です。地理、帯域、クライアント性能の異なる環境で、遅延や欠落を測ることが重要になります。
矛盾するリストと検証負荷
同じ作成者が相手ごとに異なるリストを送るequivocation（矛盾した複数メッセージの送信）が起きれば、適合性判断が混乱します。重複・矛盾を検出する規則と、通信障害を悪意と取り違えない設計が必要です。またビルダーは複数リストを照合し、nonceの競合や実行可能性を確認するため、計算と通信の負担が増えます。
開発者向け：新しい取引型の検証範囲
Frame Transactionのようにアカウント側コードで検証する取引を包含対象にするには、短時間で安全に判定できる処理範囲が必要です。関連案EIP-8369のVOPS Profilesは、検証時に許す操作を制限して適格性を判定します。これは開発者向けの依存論点であり、FOCILやFrame Transactionと同じ採用予定ではありません。
Frame Transactionが変える認証・実行・ガス支払い
まなぶ「クリプ先生、アカウント抽象化って、口座を分かりにくくする技術なんですか？」
クリプ「ここでの『抽象化』は、認証や支払いの固定ルールをコードで選べるようにすることだよ。使う人には、回復や代理支払いとして見えてくるんだ。」
Frame Transactionは、新しい取引形式を通じてネイティブなアカウント抽象化（AA）を実現しようとするEIP-8141の提案です。Ethereumの通常口座では、特定の楕円曲線署名と秘密鍵が認証の中心にあります。Frame Transactionでは、取引をいくつかの処理枠として扱い、アカウントのコードが検証、実行、ガス支払いに関与できるようにします。
アカウント側コードで検証する新しい取引形式
従来の取引では、誰が送信者かを確認する方法がプロトコル側で強く固定されています。Frame Transactionでは、アカウントが持つコードで認証条件を表現できます。たとえば一つの秘密鍵だけでなく、複数鍵の組み合わせ、別方式の署名、一定条件を満たした回復手続きなどを設計できる余地が生まれます。
重要なのは、ウォレット画面の便利機能だけを追加する話ではなく、Ethereumが取引として認識する基盤を変える点です。現在もスマートコントラクトウォレットやERC-4337によるAAは利用できますが、bundlerなどプロトコル外の役割に依存します。ネイティブ化は基盤との統合を深められる反面、クライアントや周辺インフラへ広い対応を求めます。
署名方式とガス代の支払者をプログラム可能にする
認証をコードで扱えれば、署名方式を用途や時代に合わせて選べます。また、取引を実行する人とガス代を払う人を分ける設計も可能になります。アプリ運営者が初回利用分を負担する、利用者が保有する別トークンを入口にして支払いを処理する、といった体験の基盤になり得ます。
ただし「ガス代がなくなる」という意味ではありません。ネットワークの計算資源には費用が必要で、誰かがETH建てのガスを負担します。利用者に見えなくする、別の支払いと組み合わせる、スポンサーが負担するという違いです。無料をうたうサービスでも、負担者、上限、失敗時の扱いを確認する必要があります。
既存AA・bundler・paymasterとの移行に残る不確実性
現在のAAエコシステムには、UserOperationをまとめるbundler、ガス代を代理するpaymaster、ウォレット実装、監視やシミュレーションの仕組みがあります。Frame Transactionが導入されても、これらが即座に不要になると決まったわけではありません。既存口座をどう移すか、アプリが従来取引と新取引をどう併用するか、失敗理由をどう表示するかなどが残ります。
EIP-8141は変更範囲が大きく、仕様が採用予定であることと、すべてのウォレットが同日に対応することは別です。利用者体験は、各ウォレットとアプリの実装、監査、サポート方針によって段階的に変わる可能性があります。開発者はプロトコル仕様だけでなく、RPC、署名ライブラリ、シミュレーター、インデクサーの対応も追う必要があります。
ウォレットは回復・複数承認・耐量子移行へ進めるか
回復機能・複数承認・ガス代肩代わりの基盤
秘密鍵を一つ失うと操作できなくなる問題に対し、アカウントコードで回復条件を設定できれば、指定した複数の保護者による承認、時間を置いた鍵変更、端末と別要素の組み合わせなどを実装しやすくなります。高額操作だけ複数承認にする、日常利用には上限を設けるといったポリシーも考えられます。
もっとも、柔軟性は自動的な安全性を意味しません。回復者の結託、実装バグ、複雑な条件によるロックアウト、スポンサー機能の悪用など、新しい攻撃面も生まれます。ウォレットごとの設計と監査、緊急時の手順、権限表示が重要です。プロトコルが可能性を提供し、製品が安全な形へ落とし込むという二段階で考えましょう。
署名方式を口座側で切り替えられる意味
現在広く使われる署名方式に将来の弱点が見つかった場合、認証方式が固定された口座は移行が難しくなります。口座側のコードで署名検証を選べれば、残高やアドレス上の状態を維持しながら、別方式へ切り替える経路を作りやすくなります。これがFrame Transactionを耐量子移行の「起点」と表現する理由です。
切り替えには、新しい署名方式の標準化、効率的な検証、ウォレット対応、利用者への安全な案内が必要です。署名データが大きくなれば、ガスや帯域への影響も評価しなければなりません。選択可能になることと、実用的な耐量子方式が全利用者へ配備されることの間には、多くの工程があります。
Hegotáは耐量子化の完了ではなく移行の起点
ethereum.orgのセキュリティロードマップは、現在の量子計算機がEthereumの暗号を破れる状態ではないと説明しつつ、将来に備えた研究と移行を扱っています。Hegotá単体でEthereum全体が耐量子化されるわけではありません。Frame Transactionはアカウントの認証方式を移行しやすくする部品の一つです。
コンセンサスに使う署名、過去に公開された公開鍵、スマートコントラクト内の暗号、ブリッジやL2など、耐量子対応の対象は口座取引だけではありません。「耐量子対応」という見出しを見たら、どの層のどの鍵を対象にし、何が実装済みで何が研究中かを確認してください。危機をあおって送金や購入を促す情報には慎重さが必要です。
プライバシー対応は関連候補との組み合わせ（未確定）
FOCILとFrame Transaction自体が取引内容を秘匿するわけではありません。プライバシー技術では、複数利用者が共有する送信元や、ゼロ知識証明で状態を示す構成が使われる場合があります。柔軟な取引形式だけでは、順番待ちや包含の問題が残ります。FOCILとFrame Transaction、その関連候補を組み合わせ、プライバシー取引も通常取引と同様に扱いやすくする構想があります。
Keyed Noncesで共有送信元の順番待ちを減らす
nonceは、同じ送信元から出る取引の順番を管理し、再送攻撃を防ぐ番号です。一系列しかない場合、先の取引が止まると後の取引も処理できないことがあります。複数利用者が共有送信元を使うプライバシープールでは、一人の処理がほかの利用者の待ち時間へ波及しかねません。
EIP-8250のKeyed Noncesは、nonceに複数の系列を持たせ、独立した処理を並行させやすくする案です。鍵付きの棚を複数用意し、それぞれで順番を管理するイメージです。ただし、これはHegotáで採用予定のEIP-8141そのものではなく、Frame Transactionを補う検討中の提案です。
Recent Rootsで最近の状態を証明に使う
プライバシー取引の証明は、ある時点の状態を基準に「必要な条件を満たしている」と示すことがあります。しかし、参照できる状態が狭いと、証明を作ってからネットワークへ届く間に状態が進み、利用しにくくなる可能性があります。
EIP-8272は、Frame Transactionの検証から最近の状態ルートを参照できるようにする案です。ある一瞬だけでなく、許容される最近の状態を基準に証明できれば、生成と包含の時間差へ対応しやすくなります。どの範囲を安全に認めるか、古い状態の悪用をどう防ぐかといった設計が必要です。
プライバシー関連案はまだ検討中
Keyed NoncesとRecent Rootsは、共有送信元、証明生成、FOCILによる包含保証の接続を理解するうえで重要です。しかし、2026年9月25日時点で「Hegotáに必ず入る機能」とは書けません。メタEIPの区分が変わる可能性もあります。
プライバシーという目的が支持されていても、具体的なEIPの採用は、安全性、実装負荷、テスト可能性、ほかの機能との依存関係で判断されます。目的への賛同、技術案への評価、特定フォークへの採用決定を三つに分けて読むことが大切です。
周辺EIPの採用状況一覧
EIP-8081では、SFI（採用予定）、CFI（検討中）、PFI（提案中）、DFI（当該フォークでは見送り）という管理ラベルを使います。略号を覚えるより、個別EIPの技術評価とHegotáへの採用状況を分け、メタEIPの更新日と一緒に確認することが大切です。
| 位置づけ | 主なEIP | この記事での読み方 |
|---|---|---|
| 採用予定 | EIP-7805、EIP-8141 | FOCILとFrame Transactionが主軸。仕様・日程の更新は引き続き確認する |
| 主要2機能との関連候補 | EIP-8369、EIP-8250、EIP-8272 | 取引検証、並行nonce、最近の状態参照を補うが、採用予定と同一視しない |
| その他の候補 | EIP-7906、EIP-8298、EIP-8151、EIP-8279、EIP-8131、EIP-8368、EIP-8025 | 安全性、口座移行、データ・状態肥大化、実行証明を扱う。詳細は個別EIPと最新区分を参照する |
| 見送り | EIP-8146 | 技術的な有用性と、このフォークへの採用は別の判断 |
この一覧は候補の重要度を横並びに示すものではありません。本記事の検索意図に直結するのは採用予定の2件と、その接続に必要な3件です。その他はHegotá全体を追う開発者向けの索引としてまとめています。
利用者・開発者・ノード運営者が今確認すべきこと
一般利用者向け：原則として事前操作不要
通常のETH保有者やアプリ利用者は、Hegotáという名称だけを理由に、資産を移動したり、新しいトークンへ交換したりする必要は原則ありません。正規のネットワーク更新は、ウォレットに秘密鍵やシードフレーズの入力を求めるイベントでもありません。「アップグレード対応のため送金が必要」といった案内には注意してください。
利用中のウォレットや取引所が出す正式なサポート情報を確認し、アプリを正規の配布元から更新することが基本です。新しいFrame機能が提供されても、回復方法やガス代負担者、権限設定を理解してから有効にしましょう。便利な機能ほど、誰にどの権限を与えるかが安全性を左右します。
開発者向け：新取引形式と移行互換性を確認
ウォレット開発者は、EIP-8141の仕様変更、テストベクトル、クライアント実装を追い、署名、シミュレーション、ガス見積もり、エラー表示を検証する必要があります。従来型取引、ERC-4337、Frame Transactionをどの期間併用するかも設計課題です。
回復や複数承認では、正常系だけでなく、鍵紛失、保護者の不在、競合する回復要求、チェーン再編、スポンサー停止などを試します。利用者へは「誰が支払うか」「どの署名が必要か」「後から取り消せるか」を取引前に示すことが重要です。関連候補EIPは区分が変わり得るため、採用前提で製品の公開日を固定しない方が安全です。
運用者向け：更新と検証負荷に備える
バリデータとノード運営者は、利用するコンセンサスクライアントと実行クライアントの対応版、推奨更新手順、ディスク・帯域・CPUへの影響を確認します。FOCILでは包含リストの送受信、適合性判定、ビルダーとの接続が加わるため、遅延や欠落を観測できる監視項目も必要です。
本番直前に初めて更新するのではなく、対応テストネットで構成を再現し、フェイルオーバーや再起動を含めて確認することが望まれます。ただし、具体的なバージョンや起動epochは今後の正式発表に従います。古い記事のコマンドや非公式バイナリを流用せず、各クライアントの公式リリースを参照してください。
テストネットとメインネットの日時は正式発表を追う
継続確認では、第一にEIP-8081の採用区分、第二にethereum.orgのHegotáページ、第三にAllCoreDevsや各クライアントのリリース情報を見ます。テストネットの対象と日時、クライアントの最低対応版、既知の問題が揃ってから、運用計画へ反映します。
利用場面で整理する2機能の違い
通常の送金を例にすると、FOCILが扱うのは「有効な取引がブロックへ届き続ける経路」です。利用者が正しい残高とnonceで取引を送っても、取引選択を担う主体が繰り返し外せば確定へ進みにくくなります。複数のバリデータが包含リストを作り、要件に従わないブロックへ投票しないことで、一主体の判断だけでは排除を続けにくくします。取引の有効性やブロック容量の条件は残るため、混雑時の即時確定を約束する機能ではありません。
一方、Frame Transactionが扱うのは「誰を正当な操作主体と認め、どの処理を実行し、誰が費用を払うか」です。たとえば日常の少額操作は一つの端末で承認し、高額操作は複数承認にする設計や、初回利用のガス代をアプリ側が負担する設計を、アカウントコードへ組み込みやすくなります。ネットワークへの到達を支えるFOCILと、取引内部の認証・実行・支払いを柔軟にするFrame Transactionは、役割が異なるからこそ組み合わせに意味があります。
一般利用者が確認するのは製品として提供された後の条件です。回復機能なら回復者が誰か、何人の承認が要るか、待機時間や取消手段があるかを見ます。ガス代の肩代わりなら負担者、上限、対象操作、スポンサー停止時の挙動を確認します。プロトコルが柔軟性を与えても、具体的な安全性と分かりやすさはウォレットやアプリの実装で決まります。
開発者は従来経路との併存を前提に検証します。従来型取引、ERC-4337、Frame Transactionの署名・シミュレーション・ガス見積もり・エラー表示を分け、失敗理由が利用者へ正しく伝わるかを試します。鍵紛失、回復者不在、競合する要求、スポンサー停止といった異常系も対象です。採用予定は全製品の同日対応を意味しないため、対応状況を機能単位で表示することが誤操作の防止につながります。
運用者はFOCILの通信と判定を観測可能にします。包含リストの到着時刻、欠落、矛盾、ペイロードへの反映、クライアント間の判断差を記録し、帯域やCPU負荷と併せてテストします。障害時には、悪意ある無視なのか、単純な遅延や接続不良なのかを切り分けられるログが重要です。対応版の導入だけでなく、監視と復旧手順までテストネットで確かめる必要があります。
理解を深めるには、内部解説のブロックチェーンの耐量子移行と自己管理ウォレットの仕組みも参照できます。
検証情報：責任編集部が2026年9月25日に、ethereum.orgのロードマップ、HegotáメタEIP、個別EIPを照合しました。採用区分はEIP-8081、仕様は各EIP、日程は公式ロードマップの順で確認しています。出典欄には参照日と、どの主張を支える資料かを記載しています。
まとめると、Hegotáの現在の柱は、取引を外し続ける力を分散するFOCILと、認証・実行・支払いを柔軟にするFrame Transactionです。両者は検閲耐性、使いやすいウォレット、将来の署名移行を前進させる可能性がありますが、関連EIPの多くはなお検討段階です。採用区分と実装状況を分けて読み、確定日や性能、価格への影響を先回りして断定しないことが、更新を正しく理解する近道です。
