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

Ethereum、L1ロードマップから Poseidon を外し SHA／BLAKE へ——8年のZKフレンドリー・ハッシュ探索が終わり、耐量子の前提が変わる

Ethereum、L1ロードマップから Poseidon を外し SHA／BLAKE へ——8年のZKフレンドリー・ハッシュ探索が終わり、耐量子の前提が変わる

何が起きたか

2026年8月13日、EF の研究者 Justin Drake が X で「Goodbye, Poseidon!」と投稿し、Ethereum Foundation が L1 について Poseidon を放棄し、SHA または BLAKE へ転じることを明らかにした。本人はこれを「8年・8桁ドル規模の、耐量子暗号における壮大な深掘りが理想的な結論に到達した」と表現している。撤回ではなく到達点として位置づけられている点が、この発表の性格を示している。

前提となる文脈を整理しておく。Poseidon は2019年に登場したハッシュ関数で、SNARK（Succinct Non-interactive Argument of Knowledge、簡潔な非対話型証明）の回路内部で評価するコストが、AND や XOR のようなビット演算を多用する従来型ハッシュより大幅に低くなるよう設計されている。ZKロールアップやステートツリーの設計では、証明の生成コストがハッシュの回路コストに強く依存するため、この10年ほど「ZKフレンドリーなハッシュを選ぶ」ことが半ば当然の前提になっていた。EF は Poseidon の安全性を固めるために100万ドルの Poseidon Prize を含む懸賞も設けている。

EF の耐量子作業そのものは、2026年3月24日に pq.ethereum.org として集約・公開された。実行層・コンセンサス層・データ層のそれぞれで耐量子化が何を意味するかを整理し、名前のついたフォーク群にまたがる段階的な移行を示す構成である。コンセンサス層では、バリデータ署名の集約に使っている BLS 署名を、ハッシュベースの leanXMSS へ置き換える方針が示されている。実行層では、ベクトル演算のプリコンパイルを通じた耐量子署名検証により、アカウント抽象化経由で「全員が同時に切り替える flag day」を回避しながら移行する設計が語られている。

なぜ従来型ハッシュへ戻れるのか

転換を可能にしたのは、証明系の側の変化だと考えられる。EF の耐量子チームは、leanVM——証明の検証と集約のための最小限のゼロ知識仮想マシン——において、バイナリフィールド上のインフラを整備している。ビット演算を基本単位とする体の上で証明系を構築すれば、SHA や BLAKE のようにビット演算で構成されたハッシュの回路コストは相対的に下がる。逆に言えば、Poseidon が有利だったのは、素体（prime field）上の証明系という前提があってのことだった。前提が変われば、最適解も変わる。

この判断は、暗号設計における保守性の観点からも説明がつく。Poseidon のような代数的構造の強いハッシュは、代数攻撃に対する解析の歴史が短い。一方 SHA-2 / SHA-3 や BLAKE は、標準化と長期の暗号解析を経ており、実装も広く枯れている。「センチュリー単位で持たせる」ことを掲げる耐量子ロードマップにおいて、性能上の理由でしか選ばれない新しい構造を最深部に置くことの合理性は下がる。性能面の不利が leanVM で解消するなら、枯れた選択肢に戻るのが自然という判断だろう——これは筆者の見立てであり、EF が同じ順序で説明しているわけではない。

補足しておくと、ここでいう「体（field）」は、証明系が算術を行う数の世界のことである。素体上の証明系では加算と乗算が基本演算になるため、代数的に構成された Poseidon が安く済む。バイナリフィールドでは XOR や AND が基本演算になるため、そうした演算で組まれた従来型ハッシュが安くなる。ハッシュの優劣ではなく、下の層がどちらの演算を得意とするかで順位が入れ替わる、という構造である。

EF が懸賞を設けていた事実も、この転換の意味を理解するうえで参考になる。100万ドルの Poseidon Prize は「STARKフレンドリー」なハッシュ関数の安全性を固めるため、同額の Proximity Prize はより効率的な耐量子署名の研究のために設定されたものである。つまり EF は、Poseidon を採用する前提で外部の暗号解析を積極的に募っていた。その過程を経たうえでの方針転換であり、検証が足りないまま撤回したというより、検証を尽くした結果として別の解が優位になった、と読むのが妥当だろう。

時間軸は長い。Drake の説明では、本番品質の leanVM が2027年、Ethereum のコンセンサス層・データ層・実行層への展開が2028年という想定である。ただしこれらは Strawmap という技術調整文書の上の想定であって、確定した活性化カレンダーではない。各プロトコル変更は、実装・テスト・独立したクライアントチーム間の合意という通常の手続きを経る必要がある。Strawmap 自体は2029年まで、約6か月間隔で7つのフォークを描いており、耐量子L1はその5つの「北極星」（高速L1、ギガガスL1、テラガスL2、プライベートL1と並ぶ）の一つに位置づけられている。なお、EF の FAQ は暗号学的に意味のある量子計算機の登場を「2030年代前半から中盤」とする工学ロードマップが多いと述べたうえで、分散したグローバルインフラの更新には何年もかかるため早期の準備が必要だと説明している。

想定される落とし穴

第一に、これは「L1 の」判断である。EF は自身が Ethereum ではなく、プロトコルの方向を決める中央権威でもないと明記している。L2 やアプリケーション層が Poseidon を使い続ける理由は依然として存在しうるし、既に本番で使っている証明系を今すぐ差し替える必要があるという話ではない。

第二に、影響が出るのは「今のコスト」ではなく「将来の設計判断」である。ハッシュ選定は、ステートツリーの形、コミットメントの互換性、監査済みライブラリの選択に波及し、いったん本番に入れると差し替えが難しい。今後2〜3年で新規に設計する証明系については、前提を Poseidon 固定で置かないほうがよい。

第三に、Strawmap の年号を日程として扱わないことである。2027年・2028年という数字は、実装が順調に進んだ場合の想定であり、フォークの活性化日ではない。ロードマップ文書の年号を社内資料で「予定」と書き換えると、後で説明がつかなくなる。

第四に、耐量子への移行は署名方式の変更を含むため、鍵管理と署名器（リモートサイナー、HSM、マルチシグ）の側に長期の作業が発生する。leanXMSS のようなハッシュベース署名は、状態を持つ方式では署名回数の管理が必要になるなど、運用要件が ECDSA や BLS と異なりうる。ここは仕様が固まってからでは間に合わない領域である。

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

  1. 「ZKフレンドリーなハッシュを選ぶ」という前提自体が、素体上の証明系という別の前提に依存していた。基盤層の技術選択は、それを支えるさらに下の層が変わると合理性ごと反転しうる。自社の設計で「業界標準だから」と採用した部品は、その標準を成立させている前提を書き出しておくと、こうした転換に追随できる。 ［アーキテクト・暗号実装担当］ 今四半期内に、自社の証明系・コミットメント設計で採用しているハッシュと体（field）の選択について、選定理由と依存する前提を文書化し、前提が崩れた場合の影響範囲を明記する。
  2. ロードマップ文書の年号は日程ではない。Strawmap のような技術調整文書は方向と順序を示すもので、活性化日は各クライアントチームの合意を経て別途決まる。ここを取り違えると、準備が早すぎるか遅すぎるかのどちらかになる。 ［全員］ 社内共有では Strawmap の年号を「想定」と明記し、確定日程は All Core Devs の議事と各クライアントのリリースノートで別途追跡する運用に切り替える。
  3. 耐量子移行で最も工数がかかるのは、アルゴリズムの差し替えではなく鍵と署名器の運用変更である。ハッシュベース署名は ECDSA / BLS と運用要件が異なりうるため、HSM やリモートサイナーのベンダー対応が律速になる可能性がある。 ［ノード運用者・鍵管理責任者］ 今年度内に、利用中の署名器・HSM ベンダーに耐量子署名方式（ハッシュベース署名を含む）の対応方針と時期を照会し、回答を調達要件へ反映する。

【引用：出典】

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