Ethereum EIP-8250解説：プライバシーとステート肥大化に効く「キー付きナンス」

EthereumのEIP-8250は、名前だけを見ると大きなプライバシー機能のように聞こえるかもしれません。ですが、単独で送金を匿名化する仕組みではなく、すべてのEthereum取引を一気に並列化する変更でもありません。中核はもっと限定的です。EIP-8141のフレームトランザクションで、送信者ごとに1本だけだったナンスを

(nonce_key, nonce_seq)

nonce_key == 0

この小さな変更が注目されるのは、プライバシー系プロトコルで起きやすい実務上の詰まりに効く可能性があるためです。ETH Dailyは、複数の独立した利用者を1つの共有送信者アドレス経由で扱うプライバシープロトコルにとって、EIP-8250は特に有益だと説明しています。さらに、Vitalik Buterin氏の発言を伝える複数の報道では、キー付きナンスがプライバシー対応だけでなく、特定用途向けのステート保存というEthereumの拡張戦略にもつながる可能性があるとされています。

まず押さえたいポイント

• 対象はEIP-8141のフレームトランザクションです。 EIP-8250は、送信者全体で1本だったナンス列を

  (nonce_key, nonce_seq)

  に分け、

  nonce_key == 0

  では従来のアカウントナンスを使う設計です。
• 0以外のキーは独立した再利用防止ドメインになります。 それぞれの非ゼロキーがプロトコル管理のナンス列を選び、異なる非ゼロキー上の取引はリプレイ、つまり同じ取引の再利用に対して独立します。
• プライバシー面での主な利点は秘匿そのものではなく、処理の詰まりを減らすことです。 共有送信者アドレスを使う仕組みでは、1つの遅延が後続の取引全体を止めることがあります。
• 大きな論点はステート拡張です。 報道では、プライバシー取引で使われるヌリファイアが増え続け、いったん入ると削除しにくいことが問題例として挙げられています。
• まだ提案段階です。 ここで確認できる主要な技術情報は、EIPプルリクエストに紐づくEthereum Magicians上の議論であり、仕様や導入時期は変わる可能性があります。

ナンスを「1本の列」から「複数レーン」へ

Ethereumにおけるナンスは、ざっくり言えば取引の順序と再利用防止を管理するための番号です。現在のフレームトランザクションでは、1人の送信者に対して1本の線形ナンス列を消費します。そのため、あるフレームトランザクションが遅れると、同じ送信者から出る後続のフレームトランザクションも止まり得ます。

EIP-8250は、ここに2つのフィールドを導入します。

• nonce_key：どの再利用防止ドメインを使うかを選ぶキー。
• nonce_seq：そのキーの中での順序番号。

たとえるなら、これまで1本の窓口に並んでいた取引を、キーごとに複数のレーンへ分けるイメージです。ただし、順序が完全になくなるわけではありません。異なる非ゼロキーの間ではリプレイ防止が独立しますが、それぞれのキーの中には引き続き順序があります。したがってEIP-8250は、Ethereum全体のすべての取引を対象にする並列実行スイッチではなく、特定の取引形式に対する再利用防止の設計変更と見るのが正確です。

なぜプライバシープロトコルが注目するのか

プライバシープロトコルでは、複数の利用者の操作を1つの共有送信者アドレス経由で流す設計があり得ます。ETH Dailyは、EIP-8250がそのようなケースで特に有益だと説明しています。従来のように共有送信者に対して1本のナンス列しかないと、ある利用者に関係する取引が詰まっただけで、同じ送信者から出る別の利用者の取引まで待たされる可能性があります。

キー付きナンスなら、無関係な処理を別々の非ゼロキーに割り当てることができます。あるキーの取引が遅れても、別のキーの取引まで必ず止まるとは限りません。ここで重要なのは、リプレイ防止を弱めるのではなく、キーごとに独立した再利用防止の列を持たせる点です。

それだけで送金が非公開になるわけではない

EIP-8250だけで残高、送信先、金額が隠れるわけではありません。プライベート送金には、別の仕組みが必要です。たとえばEIP-8182は、プライベートなETHおよびERC-20送金のために、システムコントラクト、証明検証用プリコンパイル、ノート、入金、プライベート転送、出金といった構成要素を説明しています。

つまり、EIP-8250はプライバシー機能の「本体」というより、プライバシー機能が高い処理量で動くための土台の一部と捉えるほうが自然です。共有送信者アドレスのナンス待ちを減らすことで、上位のプライバシープロトコルが運用しやすくなる可能性があります。

ヌリファイアとステート肥大化の問題

EIP-8250がより広い文脈で語られる理由は、ヌリファイアと呼ばれるデータにあります。プライバシーシステムでは、秘密の状態やノートが二重に使われないようにするため、使用済みを示す記録を確認可能な形で残す必要があります。報道では、こうしたヌリファイアは時間とともに増え、システムに入った後は削除できない、あるいは削除しにくい負荷として説明されています。

規模感を示す例として、オンチェーンのプライベート取引が8年間にわたって2,000件/秒（TPS）で続いた場合、約5,000億件のヌリファイアが生成されるという試算が複数の報道で紹介されています。これはストレステスト的な例であり、Ethereumが実際に必ず5,000億件の記録を保存する、あるいはEIP-8250がすでに有効化されると決まった、という意味ではありません。

専用ストレージという発想

Ethereumのステート拡張をめぐる議論では、すべてのデータを同じ汎用的な動的ステートに入れるべきか、という問題があります。報道では、キー付きナンスが、特定用途に合わせた専用ストレージ型へ進む第一歩になり得ると説明されています。

ヌリファイアは、任意のコントラクトストレージのように柔軟な読み書きが必要なデータではありません。主な役割は、過去に使われたかどうかを確認できるようにすることです。このため、一部の報道では、ヌリファイア専用の保存領域を用意し、シャーディングやブルームフィルターのような技術でノードが扱いやすくする案が紹介されています。

この見方では、EIP-8250の意味はナンス変更にとどまりません。直接の提案内容はフレームトランザクション向けのキー付きリプレイ防止ですが、その背後には、量が多く用途が明確なデータをプロトコル管理の構造に逃がすという設計方向があります。

期待できること、できないこと

期待できること

• 共有送信者アドレスを使うプライバシープロトコルで、1本のナンス列による待ち行列の詰まりを減らせる可能性があります。
• 非ゼロキーごとにリプレイ防止ドメインを分けられるため、異なるキー上の取引はリプレイ面で独立します。
• 報道では、Buterin氏がオンチェーンプライバシーシステムへのより強いプロトコルレベルの支援としてキー付きナンスを位置づけたとされています。
• 特定用途向けストレージを使うステート拡張戦略の一部として議論されています。

できないこと

• Ethereum上のすべてのナンスを置き換えるわけではありません。対象はEIP-8141のフレームトランザクションであり、キー0は従来のアカウントナンス経路を保ちます。
• 取引を自動的に非公開にするわけではありません。プライベート送金には、ノート、証明検証、入金、転送、出金など別の仕組みが必要です。
• 約5,000億件という数字は、2,000件/秒のプライベート取引が8年間続くという例から出たものであり、確定した保存量ではありません。
• すでに有効化されたプロトコル動作ではありません。EIPプルリクエストに関連する議論段階の内容であり、実装の詳細は変わり得ます。

結論

EIP-8250は、プライバシー機能そのものというより、プライバシーを支える処理基盤に近い提案です。短く言えば、フレームトランザクションのナンスを1本の列からキー付きの複数レーンへ分ける仕組みです。その結果、共有送信者アドレスを使うプロトコルで待ち行列の詰まりを減らせる可能性があります。

より大きな意味では、Ethereumが高頻度で増え続ける特殊なデータをどう扱うかという問題に関わります。ヌリファイアのように削除しにくく用途がはっきりしたデータを、汎用ステートにすべて押し込むのではなく、専用のプロトコル管理構造で扱う。この方向性こそ、EIP-8250が単なる小さなナンス変更以上に注目されている理由です。