イーサリアムの短期プライバシーロードマップ：ヴィタリック・ブテリンの3つのエンジニアリング施策

2. キー付きノンス（EIP‑8250）：並列トランザクションを可能に

次の課題は、イーサリアムのトランザクション順序管理です。

現在のイーサリアムでは、アカウントごとに**1本の連続したノンス（nonce）**が使われています。これはリプレイ攻撃を防ぐための仕組みですが、欠点もあります。もし1つのトランザクションが遅延すると、その後に送ったトランザクションがすべて待たされてしまうのです。

そこで提案されているのが**EIP‑8250の「キー付きノンス」**です。

この仕組みでは、トランザクションに次の2つの値が含まれます。

• nonce_key：どのリプレイ防止ドメインを使うか
• nonce_seq：そのドメイン内での順序番号

異なるキーを使うトランザクションは互いに独立して進行できるため、1つの取引が止まっても他の取引をブロックしません。

これは特にプライバシープロトコルにとって重要です。多くの仕組みでは、複数ユーザーの操作をリレイヤーや共有アドレスを通じて処理するため、現在の単一ノンス方式ではボトルネックが発生します。

キー付きノンスを導入すれば、複数のプライバシー取引を並列処理でき、パフォーマンスと匿名性の両方が向上します。

この提案も、Hegotaアップグレードへの組み込みが検討されています。

3. アクセス層のプライバシー：ウォレットとKohaku

3つ目は、意外と見落とされがちな問題です。

それはウォレットやRPCプロバイダーによるメタデータの漏えいです。

たとえトランザクション自体がプライベートになっても、ユーザーが

• 残高を確認する
• スマートコントラクトを読む
• 特定のアプリにアクセスする

といった操作を行うだけで、RPCノード運営者はその行動を観測できます。

そこでブテリンは、ウォレットやインフラ側でプライバシーを守る「アクセス層」の改善を提案しています。その代表例がKohakuと呼ばれるウォレット向けプライバシーフレームワークです。

Kohakuは、プライバシー機能を独立したアプリではなく通常のウォレットの中に直接組み込むことを目的としています。

さらに、ライトクライアント技術を利用してウォレット自身がブロックチェーンデータを検証できるようにする設計も検討されています。これにより、Infuraなどの集中型RPCサービスへの依存を減らすことができます。

結果として、ウォレット利用時に発生する「どのアドレスやコントラクトを調べているか」という情報漏えいを大きく減らせます。

なぜこのロードマップが重要なのか

今回のロードマップが示しているのは、イーサリアムのプライバシー戦略の変化です。

以前は「完全なプライバシープロトコル」が登場するのを待つ傾向がありました。しかしブテリンの提案は、次のような複数レイヤーの改善を同時に進めるアプローチです。

• トランザクションの検閲耐性
• トランザクション処理モデル（ノンス）
• ウォレットとデータアクセス

これらは、現在のブロックチェーンが抱える2つの大きな問題に直接対応しています。

• トランザクション検閲：ビルダーやバリデータが取引を排除できる
• メタデータ漏えい：ウォレット操作やRPCクエリからユーザー行動が追跡される

ブロックへの確実な取引掲載、並列処理可能なトランザクション構造、そしてウォレットレベルのプライバシー保護。この3つが揃うことで、イーサリアムは研究段階のツールではなく、日常的なウォレットやアプリで使える実用的プライバシーへ近づくと期待されています。

最終的な目標は、ユーザーや企業がイーサリアム上で活動する際、すべての行動が公開されることなく、それでもブロックチェーンの透明性と検証可能性を維持できるエコシステムを作ることです。