現実世界を動かす技術をシェアしよう！～身近なものづくりから最先端テクノロジーまで大募集！～

量子耐性の鍵は「暗号を選び直せること」〜Account Abstractionの役割と運用設計〜

Last updated at 2026-08-26Posted at 2026-08-26

はじめに

2026年8月時点、量子コンピュータ対策はブロックチェーン領域では将来的な課題ではなく、具体的なプロトコル設計段階に入っています。Ethereum Foundationは2026年1月にPost-Quantum Security専任チームを設立し、BitcoinコミュニティでもBIP-360 / BIP-361という具体的な移行案がDraftとして提出されています。

本記事では、まず量子コンピュータがブロックチェーンに与える脅威と現在の対策の全体像を整理し、その中でAccount Abstraction（以下、AA）が「Crypto Agility（暗号方式の交換可能性）」の実現手段としてどのような役割を果たすのかを説明します。そのうえで、筆者がEthereum Magiciansで提案している、DDD（ドメイン駆動設計）のBounded Contextの考え方を用いたAA運用管理設計（DDD-likeなAA設計）が、この量子移行の文脈でどう機能するのかを紹介します。

なお、本記事における耐量子暗号はPQC（Post-Quantum Cryptography）と表記します。また、本記事で紹介する提案・実装は筆者が個人活動として行っているものであり、所属組織の見解を代表するものではありません。

提案スレッド: Operational primitives for AA: lane separation, fixed execution phases, and versioned upgrades

1. 量子コンピュータがブロックチェーンに与える脅威とは？

1-1. 破られるのはハッシュではなく「公開鍵署名」

量子コンピュータで最初に危険にさらされるのはハッシュ関数ではなく公開鍵署名です。

現在のブロックチェーンの署名は次の一方向性に依存しています。

現在

private key
   ↓
public key
   ↓
signature

ECDSA / Schnorr / BLSの安全性は、楕円曲線上の離散対数問題が「解けない」ことに依存しています。しかし十分強力な量子コンピュータがShor's algorithmを実行できるようになると、

public key
   ↓
[ Quantum Computer ]
   ↓
private key

という逆算が現実的になり、他人の秘密鍵を復元して署名を偽造できる可能性が出てきます。

Ethereum Foundationの公開資料（2026年8月時点）では、現実的な主リスクは「チェーン履歴の全書き換え」よりも、EOAやValidatorの鍵を盗まれて資産移動・なりすましをされることだと整理されています。つまり脅威の中心は「チェーンが壊れる」ことではなく「アカウントが乗っ取られる」ことです。

1-2. 対策の全体像

2026年8月時点の主要な対策は大きく5つに整理できます。

対策	代表技術	状況
PQC署名	ML-DSA / SLH-DSA / XMSS	実装・標準化進行
Crypto Agility	Account Abstraction	Ethereumで中心的な位置づけ
PQC署名の集約	zkVM / SNARK aggregation	Ethereumで開発中
PQCコミットメント	STARK / lattice	KZG置換研究
旧アドレス移行	P2MR / PQC output	BitcoinでBIP提案

主な論点は以下のとおりです。

PQC署名の標準化は完了しつつあります。 NISTではML-DSA（旧CRYSTALS-Dilithium、FIPS 204）とSLH-DSA（旧SPHINCS+、FIPS 205）が正式標準となっています。ただし単純な置き換えはできません。EthereumのBLS署名が96 bytes程度であるのに対し、Ethereumが研究しているハッシュベースのleanXMSSは約3 KBになります。この課題に対し、Ethereum Foundationは大量のPQC署名をZK proofにまとめる「leanXMSS + leanVM」の組み合わせにより、署名データを約250倍圧縮する方向性を示しています（出典：ethereum.orgロードマップ「Post-quantum cryptography on Ethereum」、2026年8月時点）。

Bitcoinでは公開鍵を露出させない方針が採られています。 BIP-360（Pay-to-Merkle-Root、2026年2月にBIPリポジトリへDraftとしてマージ）はTaprootからkey pathを取り除き、公開鍵を長期間チェーン上に露出させないようにします。さらにBIP-361では、ECDSA/Schnorrアドレスへの新規送金を段階的に禁止し、古い鍵を退役させる移行案が提示されています。

そしてEthereum FoundationがExecution層の対策の中心に据えているのが、本記事の主題であるCrypto Agility、すなわち「暗号方式を交換可能にする設計」です。

1-3. 本質的な問いは「どのPQC署名方式が定着するか」ではない

ML-DSA、SLH-DSA、Falconのうち、どのPQC署名方式が標準として定着するかは現時点では分かりません。新しい暗号方式に将来脆弱性が見つかる可能性もあります。

そのため本当に必要なのは、

ECDSA
 ↓
ML-DSA
 ↓
次世代PQC
 ↓
...

と安全に移行（migration）し続けられる構造そのものです。Ethereum Foundationもこの考え方（Crypto Agility）をPost-Quantum戦略の中心に置いています。

2. 不変性の強いブロックチェーン上でカスタマイズ可能な認証機能を付与するAA設計

2-1. EOAの問題：署名アルゴリズムがアカウントのアイデンティティに固定されている

従来のEOAでは、アドレス自体がsecp256k1の公開鍵から導出されます。つまり署名アルゴリズムとアカウントのアイデンティティが不可分です。ECDSAが破られた場合、アカウントそのものが危険にさらされ、移行するにはアドレスを変えて資産を移すしかありません。

EOAのこの構造は、ブロックチェーンの「不変性」という強みが、暗号移行においてはそのまま制約となる構造です。

2-2. AAは署名検証を「差し替え可能なモジュール」にする

AA（ERC-4337）では、アカウントはスマートコントラクトであり、署名検証ロジックはコードとして定義されます。さらにERC-6900 / ERC-7579のモジュラーアカウント設計では、その検証ロジック自体を外部のValidator Moduleへ委譲できます。

ポイントは、ERC-1271（外部向け署名検証インターフェース）とERC-4337の validateUserOp() の両方が共通のValidator layerを使えることです。

これにより、次のような段階的な移行がアカウントアドレスを変えずに可能になります。

Phase 1
ECDSA

Phase 2
ECDSA + PQC (Hybrid)

Phase 3
PQC

Phase 4
PQC v2

Ethereum全体を一度にハードフォークするのではなく、

Alice
ECDSA → PQC

Bob
ECDSA

Company Wallet
ECDSA + PQC hybrid

とアカウント単位で段階的に移行できます。これがEthereum FoundationがAAをPost-Quantum戦略の中心に置く理由であり、Ethereumコミュニティで議論中のEIP-8141（Frame Transaction）でも、アカウントごとに独自のsignature verificationを選択できる方向性が示されています。

AAの長期的な価値の一つは、UXではなくCrypto Agilityにあります——これが2026年8月時点での筆者の考えです。

3. 筆者が提案しているDDD-likeなAA運用管理設計の紹介

「Validatorを差し替えられる」こと自体はERC-6900 / ERC-7579が既に示しています。しかし実運用を考えると、次のような問いが残ります。

なお、本章で用いる「lane」とは、1つのSmartAccount内部に設けた実行コンテキストの区画を指します（詳細は3-1で説明します）。

誰が、どこで、その差し替えを管理するのか？
業務ドメインごとに異なる認証要件（例：決済laneはHybrid署名必須、ゲームlaneはPasskeyのみ）をどう表現するのか？
移行に失敗したとき、どう切り戻し（rollback）するのか？

筆者はEthereum Magiciansで、この運用面に焦点を当てた3つのprimitiveを提案しています。

lane-keyed context domains（laneKeyによるコンテキスト分離）
fixed execution phases（変更しない実行フェーズ + 差し替え可能なモジュール）
versioned operational primitives（upgrade / rollback可能なバージョン管理）

図1：現状のSmartAccountベースAAの全体像（筆者による自己分析）

図2：提案の概要図。ピンクで示した領域（laneKeyドメインとValidator/Executor Aggregator周辺）が提案箇所です

3-1. laneKey：業務ドメイン単位の認証カスタマイズ

laneKeyは、1つのSmartAccountの内部にドメイン／実行コンテキストごとの名前空間を作るprimitiveです。各laneは独自のmodule slot（validator / executor / hooks）を持ちます。

Lane
 ├─ validator
 ├─ validationHook
 ├─ executor
 └─ execHook

これを量子移行の文脈に置くと、次のようになります。

Lane A（一般利用）
validator = ECDSAValidator

Lane B（日常決済）
validator = PasskeyValidator

Lane C（高額資産管理）
validator = PQCValidator

Lane D（移行期間中の重要操作）
validator = HybridValidator（ECDSA + ML-DSA）

つまり「アカウント単位でPQCに移行する」よりもさらに細かく、業務ドメイン（ユースケース）単位で暗号方式を選択できるようになります。リスクの高いドメインから先にPQC化する、といった段階的な移行戦略がアカウント内部で完結します。

3-2. Validator Aggregator：ERC-1271検証ロジックのプラグイン化とバージョン管理

提案のうち運用面に関わるのが、validator/executor aggregatorを「エンジニアが管理する共有の運用基盤」として扱い、そこにバージョン管理を付けることです。

実装上の分離は次のとおりです。

account-local：ユーザー固有のidentity material（Passkey credential等）はSmartAccountに保存する
shared / engineer-managed（エンジニア管理）：Validatorはstatelessであり、accountからcredentialを読む。lane別のvalidator群はAggregatorの配下に共有child moduleとして配置される

ERC-1271の isValidSignature() はSmartAccountが入口を維持しつつ、実際の検証ロジックはAggregator経由でプラグイン形式のValidatorへルーティングされます。そしてversion tagはchild module単位ではなく、Aggregator（複数のmoduleを束ねる共有の結合点）単位で付けます。

その理由は、運用上の本当の問いが「どのchild moduleが存在するか」ではなく、

どの認証方式とlane policyの組み合わせがactiveか
あるlaneに対してどの実行モジュール群がactiveか
その組み合わせをどう段階的展開（rollout）／交換していくか

だからです。

この設計が量子移行で有効に機能するのは、PQC移行そのものを「upgrade / rollback可能なcryptographic policy」として扱えるようになる点です。

AggregatorVersion v3
  Lane C: ECDSAValidator

        ↓ upgrade

AggregatorVersion v4
  Lane C: HybridValidator (ECDSA + ML-DSA)

        ↓ 問題発生時

AggregatorVersion v3 へ rollback

新しいPQCアルゴリズムに脆弱性や実装バグが見つかっても、バージョン履歴を持つ共有基盤として管理していれば、影響範囲を明示しながら安全に切り戻せます。「どのPQC署名方式が定着するか分からない」時代の移行に必要なのは、この性質です。

3-3. 運用主体がロジックを管理する領域を、オンチェーン上で明示する

本提案のもう一つの効果は、開発体制の面にあります。

この設計では、AccountFactory がlaneKey別の共有aggregator moduleを事前登録し、新規SmartAccount作成時にそのlane構成をattachします。つまりlaneKeyは単なるルーティングの名前空間ではなく、

module slot名
factoryのbootstrapターゲット
段階的展開（rollout）／保守の運用単位

という3つの役割を持ちます。

これはDDDでBounded Contextを切るのと同じ発想です。「どのドメインの認証ロジックを、誰が、どこで開発・更新するのか」がオンチェーン上の構造として明示されます。 不変性の強いブロックチェーンの上で、可変であるべき部分（暗号方式・業務ロジック）とその責任境界を、明示的に管理された領域へ切り出す設計です。

筆者は執筆時点（2026年8月）で、この設計をOP Sepolia上で eth_estimateUserOperationGas → Passkey署名 → eth_sendUserOperation → オンチェーン実行までのend-to-endフローとして動作確認しています。

図3：提案するAA設計の全体像（各コントラクトの関係と利点の整理）

実装リポジトリ: cancan007/LCG_contracts

3-4. 概念的なまとめ

量子耐性を念頭に置いたとき、筆者が設計の本体だと考えている構造は次のとおりです。

SmartAccount
     │
Validation Router / Aggregator（versioned・laneKey別）
     │
Pluggable Cryptographic Validator
（ECDSA / Passkey / ML-DSA / Hybrid / ...）

そしてERC-1271 / ERC-4337 / 将来のNative AA（EIP-8141）は、この共通Validator layerの上に乗るAdapterとして位置づけます。署名アルゴリズムをアカウントの不変のアイデンティティから切り離し、さらにその差し替え操作自体をバージョン管理された運用primitiveにする——これが提案の核です。

4. 感想

今回、量子コンピュータ対策の動向を追いながら改めて感じたのは、「正解の暗号を選ぶこと」より「選び直せる構造を持つこと」の方が本質的だということです。

ML-DSAが標準化された現在でも、10年後にそれが安全である保証はありません。Ethereum Foundation自身がCrypto Agilityを戦略の中心に置いているのは、この不確実性を前提とした方針だと考えます。

この「選び直せる構造を持つ」という考え方は、ブロックチェーンに限った話ではありません。技術の進展が速い現代では、「現時点の最適解を固定する設計」はそれ自体がリスクになります。問われているのは、変化に柔軟に対応できるカスタマイズ性を、責任境界と切り戻し（rollback）可能性を保ったまま維持する設計ができるかどうかです。

不変性を特徴とするブロックチェーンの上では、「何を不変にし、何を可変にし、可変な部分を誰がどこで管理するのか」という境界設計が重要になります。laneKey / fixed phases / versioned aggregatorsという本提案は、その一つの回答として位置づけています。

ご意見・ご議論をお待ちしております。Ethereum Magiciansのスレッド、または本記事のコメント欄へお寄せください。

5. 最後に、記事を面白いと思ってくれた方へ

今回紹介したAA運用管理設計は個人での提案ですが、「変化に柔軟に対応できる仕組みをつくる」という考え方は、普段Sapeetで取り組んでいる開発にも通じています。

Sapeetでは、開発の取り組みや、働く人・会社の雰囲気を知っていただくための交流イベント「Open Sapeet」を開催します。
当日は、Sapeetのエンジニアをはじめとする社員が、AIやプロダクト開発、これからの働き方についてお話しします。軽食とドリンクを片手に、社員と気軽に交流できる時間も用意しています。
技術の話をもう少し聞いてみたい方や、Sapeetのメンバーと話してみたいと思っていただけた方は、ぜひお気軽にご参加ください。

日時：2026年9月11日(金) 19:30~21:30
会場：Sapeet本社オフィス
所在地：東京都港区芝5-13-18いちご三田ビル8階
イベント詳細・お申し込みはこちら

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up