アルゴランド・ポスト量子レジャー（台帳）
- 2 時間前
- 読了時間: 39分
アカウント・タイプごとにレジャーの安全性を確保
量子コンピューティングの登場は、現代の公開鍵暗号システムが前提としているセキュリティの仮定を根本から覆します。アカウント、トランザクション、そしてコンセンサス（合意形成）メッセージのすべてが公開鍵とデジタル署名に依存しているブロックチェーンは、特にその脅威に晒されています。ショアのアルゴリズムを実行する十分な性能を持った量子コンピュータは、公開鍵から秘密鍵を導き出し、署名を偽造することができてしまいます。
Algorandのポスト量子戦略は、以下の3部構成のロードマップとして理解できます。
過去の防衛（Secure the past）: 攻撃者が過去のブロックやトランザクションのシーケンスを書き換えて現在のレジャー（台帳）状態を改ざんできないよう、ブロックチェーンの履歴を保護する。Algorandは2022年の「ルネサンス・ブロック」で実装されたステート・プルーフ（State Proofs）によってこの取り組みを開始し、Falcon署名を用いて過去の証明を耐量子仕様にしました。
現在の防衛（Secure the present）: レジャーそのもの、つまりすべてのアカウントの「現在の状態」を保護する。量子攻撃者がアカウントの制御をバイパス（迂回）できないようにする必要があります。
未来の防衛（Secure the future）: ブロックを提案・投票する参加者を決定する暗号学的抽選（暗号学的ソートジション）メカニズムを含む、コンセンサス自体を保護する。これは、Pure Proof-of-Stake（PPoS）プロトコルの核心である「検証可能ランダム関数（VRF）」をポスト量子対応のものへと置き換える研究が必要なため、最も難度の高いステップです。
この記事では、2番目のステップである「Algorandアカウントの安全性を確保し、稼働中のレジャーをポスト量子セーフにする戦略」に焦点を当てます。これは、2025年11月に達成されたマイルストーン（アカウント抽象化を通じてメインネット上で初めてFalcon署名によるトランザクションを承認した実績）を基盤としています。ここでは、その概念をレジャー全体のアカウント戦略へとどのように拡張していくかという、より広い問いを扱います。
1. レジャーの安全性を確保するとはどういう意味か？
アカウント戦略を理解するためには、まず「ブロックチェーン」という言葉の中で混同されがちな2つの概念を区別する必要があります。
「ブロックチェーン」には歴史（ヒストリー）が含まれています。それは、すでに発生したトランザクションとブロックの順序づけられたシーケンス（一連の配列）です。一方で「台帳（レジャー）」には、その歴史の結果として生じた現在の状態（現在のステート）が含まれています。これには、残高、資産（トークン）、アプリケーションの状態、アカウントの設定、および「今」存在しているその他のデータが該当します。
この区別は、UTXOベースのブロックチェーンとアカウントベースのブロックチェーンを比較すると、特に明確になります。
UTXOベースのブロックチェーンでは、システムは「ジェネシス・ブロック（初期ブロック）」から始まります。このブロックは、通常の意味でのブロックと同じです。つまり、最初の「未使用のトランザクション出力（UTXO）」を生成する、初期のトランザクション群が含まれています。そこから、全トランザクションの履歴をたどり、どの出力がまだ使われていないかを追跡することによって、現在の所有権の状態が再構築されます。
これに対して、アカウントベースのブロックチェーンでは、出発点は「ジェネシス状態（初期ステート）」として理解する方が適切です。ブロックチェーンの用語との一貫性を持たせるために、今でも「ジェネシス・ブロック」と呼ばれることが多いですが、概念としては、通常のトランザクションのリストによって定義されているわけではありません。最初のアカウント、その残高、そして最初から存在する特殊なプロトコル・アカウントやパラメータなど、初期の台帳状態を直接定義しているのです。
Algorandは、アカウントベースのブロックチェーンです。UTXOベースのブロックチェーンのように、未使用のコインを独立したオブジェクトとして追跡する代わりに、ネットワークはアカウントを保持し、有効なトランザクションが確定（ファイナライズ）されるたびにその状態を更新します。このモデルにおいて、台帳は「アカウントのテーブル（表）」と見なすことができ、各行に1つのアカウントの現在の状態が記録されています。
この「ジェネシス状態」という概念は、後ほどAlgorandの「特殊アドレス」について議論する際に非常に役立ちます。一部のアドレスは、通常のアカウント活動を通じて作成された一般的なユーザーアカウントではなく、ネットワークの初期状態やプロトコルの構成の一部であるという理由で存在する、プロトコル定義のアドレスだからです。
したがって、台帳（レジャー）を安全に保つということは、「アカウントの管理権限」を安全に保つことを意味します。もし、すべてのアカウントが「耐量子（ポストクォンタム）で安全な認可経路」を通じてのみ管理できるようになれば、台帳の現在の状態は、量子コンピューターによる鍵復元攻撃から保護されることになります。
これは単純なことのように聞こえますが、Algorandには複数種類のアカウントが存在し、すべてのアカウントが同じ方法で管理されているわけではないのです。
2. アカウントを制御する2つの方法：秘密（鍵）とプログラム
大まかに言うと、Algorandのアカウントを管理（制御）する方法には2つの道筋があります。
1つ目の方法は、「秘密（シークレット）」による管理です。ユーザーが秘密鍵を知っており、それを使ってトランザクションに署名します。ネットワークは、その署名が対応する公開鍵と一致するかを検証します。これは、標準的な単一署名（Single-signature）アカウントで使われている、お馴染みのモデルです。マルチシグ（Multisignature）アカウントは、この概念を拡張したものであり、1つではなく複数の秘密を必要とします。
2つ目の方法は、「プログラム」による管理です。秘密鍵が署名したからという理由でトランザクションを受け入れるのではなく、プログラムが承認、またはプログラム自体が開始（発行）したからという理由で、ネットワークがトランザクションを受け入れます。Algorandにおいて、これにはロジック署名（Logic Signatures）とアプリケーション（Applications）が含まれます。プログラム管理下のアカウントは、秘密鍵ではなく、コードによって統治（制御）されるように設計されています。
この区別こそが、耐量子アカウント戦略の中核となります。
「秘密」によって管理されているアカウントは、Ed25519のような量子に対して脆弱な署名スキームから移行（マイグレーション）しなければなりません。
「プログラム」によって管理されているアカウントは、意図しない秘密ベースの管理経路によって、そのプログラムロジックがバイパス（迂回・悪用）されないように確実に保護しなければなりません。
1つ目の課題は直感的に理解しやすいものですが、2つ目の課題はより繊細（複雑）な問題です。
3. アドレスと公開鍵は必ずしもイコールではない
アカウント・タイプを見る前に、もう一つの重要な区別があります。Algorandのアドレスは、必ずしも公開鍵そのものとは限りません。
Algorandのアドレスは、32バイトの識別子（識別データ）にチェックサム情報を加えてユーザーフレンドリーにエンコードしたものです。すべてのアカウント・アドレスは見た目が同じフォーマットであるため、アドレスだけを見ても、それがシングルシグ、マルチシグ、ロジック署名（LSig）、アプリケーションのどれに属しているかは判別できません。
これによりインターフェースが統一されるメリットがありますが、裏を返せば、標準のシングルシグ・アカウントにおいて、暗号検証に必要なEd25519公開鍵がアドレス（ハッシュ化されていない）に直接露出していることを意味します。そのため、アドレスが知られた瞬間に、量子攻撃の対象となる公開鍵が露出してしまいます。
各アカウント・タイプは、以下の異なる入力から32バイトの識別子を導出（ハッシュ化）しています。
シングルシグ：Ed25519公開鍵から導出。対応する秘密鍵の知識によって制御。
マルチシグ（MSig）：バージョン、閾値、参加するEd25519公開鍵などの構成のハッシュから導出。
ロジック署名（LSig）：プログラムのバイトコードのハッシュから導出。
アプリケーション（App）：アプリケーションIDのハッシュから導出。
このハッシュ導出アドレスの設計は、量子時代において2つの異なるリスクをもたらします。
グローバー（Grover）のアルゴリズム：ハッシュ導出アドレスに対する総当たり検索（ブルートフォース）に関係。
ショア（Shor）のアルゴリズム：Ed25519公開鍵から秘密鍵を復元することに関係。
最初の課題は、ハッシュ由来のアドレス全般に広く共通するもので、これについては次節で詳しく述べます。2番目の課題はより複雑（テクニカル）であり、そのアドレスが意図的であるか否かに関わらず、Ed25519の公開鍵として解釈できてしまうようなアカウントにおいて問題となります。
4. 衝突耐性を持つハッシュベースのアドレス
マルチシグ（Multisig）アカウント、ロジック署名（LSig）アカウント、アプリケーションアカウント、あるいは将来のネイティブな耐量子アカウントのいずれであるかを問わず、ハッシュから生成されるすべてのアドレスは、1つの根本的な要件を満たさなければなりません。それは、32バイトのアドレス空間が、そのアカウントモデルにおいて十分な「衝突耐性（コリジョン・レジスタンス）」を維持し続ける必要があるということです。
ここでのリスクは、後述するEd25519の鍵復元リスクとは性質が異なります。ショアのアルゴリズム（Shor’s algorithm）は、公開鍵と秘密鍵を結びつけている極めて困難な数学的問題を解くことができるため、Ed25519のような署名スキームを脅かします。これに対して、ハッシュ由来のアドレスは、「同じアドレスを生成する別の入力データをいかに見つけにくいか（困難であるか）」という点に依存しています。
アカウントのセキュリティにおいて最も関連性の高いハッシュ攻撃は、通常、「ターゲットを絞った第二原像攻撃（セカンド・プリイメージ攻撃）」です。これは、攻撃者が既存のアカウントアドレスを特定した上で、その同じ32バイトの識別子へとハッシュ化される「異なるシード（元のデータ）」を見つけ出そうとする試みです。よりカジュアルな表現では、これは「アドレスの衝突」としばしば描写されますが、重要な点は、攻撃者が単に衝突する2つの入力データの組み合わせを探しているのではなく、「特定の既存アドレス」を標的にしているということです。
量子攻撃者は、グローバーのアルゴリズム（Grover’s algorithm）を使用して、総当たり攻撃（ブルートフォース検索）を高速化することができます。しかし、アドレスの派生に適切な暗号学的ハッシュ、明確なドメイン分離（Domain Separation）が使用され、入力フォーマットに構造的な弱点がないと仮定すれば、32バイトのハッシュ出力は、この種のターゲットを絞った探索に対して依然として非常に大きなセキュリティマージン（安全域）を提供します。
これは、何らかのシードをハッシュ化することによってAlgorandの32バイトのアドレス空間に派生させる、すべてのタイプのアカウントに共通する要件です。
5. 潜在的な問題：意図して鍵を作っていなくても、数学的に存在してしまうリスク（プログラム・アカウントの罠）
ロジック署名（LSig）アカウントやアプリケーションアカウントの場合、アカウントの作成者がそのアカウントアドレスに対応する「Ed25519の秘密鍵」を生成することはありません。アドレスは、ロジック署名の場合はプログラムのハッシュ値から、アプリケーションの場合はアプリケーションIDのハッシュ値から生成されるからです。
そのため、当然次のような疑問が生じます。「秘密鍵が作られていないのであれば、量子攻撃者はいったい何を盗むことができるというのか？」
その答えは、「秘密鍵が意図的に作られなかった」ということは、「数学的に秘密鍵が存在し得ない」ということと同義ではない、という点にあります。
Algorandアドレスの背景にある32バイトの識別子は、有効なEd25519公開鍵としても解釈できてしまう可能性があります。大雑把に言うと、これは約2分の1（50%）の確率で発生します。もしその識別子が有効なEd25519公開鍵であるならば、たとえ今日まで誰もそれを生成しておらず、誰も知らなかったとしても、数学的な意味における「対応する秘密署名鍵」がそこに存在していることになります。
古典的（現代の標準的な）コンピューターの前提に立つならば、これは問題になりません。なぜなら、Ed25519の公開鍵が与えられたとしても、それに対応する秘密鍵を見つけ出すことは計算上不可能だからです。したがって、プログラム管理下のアカウントは、あくまでプログラムによって管理され続けます。有効な公開鍵として解釈できてしまう状態が偶発的に存在していたとしても、攻撃者にとっては何の役にも立ちません。
しかし、十分に巨大な量子コンピューターが登場すると、この前提が覆ります。ショアのアルゴリズム（Shor’s algorithm）は、Ed25519が依拠している離散対数問題を解くことができます。もしプログラム管理下のアカウントアドレスが、たまたま有効なEd25519公開鍵としてデコード（解釈）できてしまった場合、量子攻撃者はそのアドレスに対応する署名鍵を導き出し、通常のEd25519署名によって認可されたトランザクションを提出できてしまう可能性があるのです。
そうなれば、プログラムは完全にバイパス（迂回・無視）されてしまいます。
これこそが、耐量子（ポストクォンタム）環境におけるプログラム管理型アカウントの核心的な課題です。すなわち、「プログラム自体には何の秘密（鍵）も含まれていないかもしれないが、アドレス自体が偶発的に秘密ベースの解釈を認めてしまうかもしれない」という問題です。
この「偶発的なアドレス（Ed25519解釈）」という概念は、マルチシグ（MSig）、ロジック署名（LSig）、アプリケーション（App）アカウントといった、ハッシュ由来のすべてのアカウントタイプに関係してきます。アカウントのタイプごとに異なってくるのは、「その偶発的なEd25519解釈が、有効な認可経路になってしまう事態を、プロトコルによっていかに防ぐか」というアプローチの手段です。
6. なぜ単純に「プログラム・アカウントに対するEd25519署名を拒否する」というプロトコル・ルールにしないのか？
自然な解決策としては、プロトコルのルールとして「アカウントがプログラムによって管理されている場合、Ed25519署名によるそのアカウントの操作（管理）の試みはすべて拒否する」というものが挙げられます。
概念としては魅力的ですが、実務上は複雑です。なぜなら、Algorandのアドレスは自己記述型（それ単体で属性を説明できる構造）ではないからです。
アカウントが最初に使用される前は、アドレス単体を見ただけでは、それが公開鍵（単一署名）、マルチシグ（Multisig）の構成、ロジック署名（Logic Signature）プログラム、あるいはアプリケーションID（Application ID）のどれに由来するものなのかを判別できません。台帳（レジャー）がそのアカウントの有効な「管理経路（コントロールパス）」を認識できるのは、そのアカウントが最初に有効なアクションを実行したときだけです。
単一署名（Single-signature）アカウントは、Ed25519の認可経路を明かします。
マルチシグ（Multisig）アカウントは、マルチシグの認可経路を明かします。
ロジック署名（Logic Signature）アカウントは、プログラムによる認可経路を明かします。
アプリケーション（Application）アカウントは、そのアプリ自身が発行するインナートランザクション（内部トランザクション）を通じて、アプリケーションベースの管理経路を明かします。
あるアドレスがプログラム管理下にあることを台帳が一度認識すれば、理屈の上では、それ以降はその解釈を強制することができます。しかし、プロトコルは依然として、「すでに存在するアカウント」「まだ資金が投入（入金）されていないアカウント」「対応するアプリケーションが生成される前に計算（算出）される可能性のあるアドレス」を処理できなければなりません。
これが、アカウントの種類によって戦略（アプローチ）が異なる理由です。
7. ロジック署名（LSig）アカウント：「コイントス」としてのハッシュ活用（ソルトによる回避）
ロジック署名（LSig）アカウントは、プログラム管理下のアカウントの中で最も容易にセキュリティを強化（ハーデニング）できます。
ロジック署名のアドレスは、プログラムのバイトコードから派生（算出）されます。ハッシュ関数には「雪崩効果（アバランチ効果）」という特性があり、入力データをわずか1バイト変更しただけでも、全く異なる出力が生成されます。つまり開発者は、プログラムの挙動を変えることなく、バイトコードを少しだけ変更するだけで、新しいアドレスを取得できるのです。
耐量子（ポストクォンタム）の安全性を確保するための戦略は、次のようにシンプルなものになります。
ロジック署名プログラムをコンパイルする。
そのアドレスを算出する。
その32バイトの識別子が、有効なEd25519公開鍵としてデコード（解釈）できるかどうかをチェックする。
もし解釈できてしまう場合は、プログラムに害のないソルト（ダミーデータ）を追加して、最初からやり直す。
算出されたアドレスが「オフカーブ（楕円曲線上外）」、すなわち有効なEd25519公開鍵として解釈できない状態になるまで、このプロセスを繰り返す。
各試行はそれぞれ独立した「コイントス」のように機能するため、必要な予想試行回数はわずかで済みます。
重要な点は、追加するソルトがプログラムのロジック（論理）を変更してはならないということです。ソルトは、異なるアドレスを生成するのに十分な程度にバイトコードを変化させるだけです。これは、ダミー値を手動で追加するか、コンパイラがサポートするソルト機能を利用することで実現できます。
このアプローチは、すでにLSigベースのFalconアカウント抽象化において採用されています。このロジック署名アカウントは、偶発的にEd25519の管理経路が生じてしまう事態を絶対に避けなければなりません。さもなければ、そのアカウントはプログラム層で耐量子署名を検証しているにもかかわらず、アドレス層でのEd25519解釈を通じて脆弱なままになってしまう（攻撃の余地を残してしまう）からです。
長期的な目標は、開発ツールによってこのプロセスをすべてのLSigで自動化することです。新しいバージョンのTEALでは、（このプルリクエストで開発された）提案アプローチとして、プログラムのプレフィックスにソルトバイトを導入し、アセンブラが「オフカーブ」なロジック署名アドレスを生成するソルトを決定論的に（確実に見つかるまで）自動探索する仕組みが検討されています。開発者が明示的にソルトを指定することも可能ですが、デフォルトの処理経路では、意図せず脆弱なロジック署名アカウントを作ってしまうことから開発者を保護するべきです。
この手法が強力な解決策である理由は、プロトコルのアップグレードや、ロジック署名アドレスの根本的なモデル変更を必要としない点にあります。既存のハッシュ由来のアドレス設計をそのまま活かし、安全な結果を「デフォルト（初期設定）」にできるのです。
8. アプリケーション・アカウント：より困難なプログラムアカウントのケース
アプリケーション・アカウントのセキュリティ強化は、より困難です。なぜなら、そのアドレスが「アプリケーションのプログラム」から派生するわけではないからです。アドレスは「アプリケーションID（Application ID）」から派生しますが、このIDはプロトコルによって管理される、一意の連番（インクリメンタルなカウンター）であり、アプリの作成者が操作できるものではありません。
つまり、アプリケーションのコードを変更しても、アプリケーション・アカウントのアドレスは変わりません。アプリの作成者は、ロジック署名（LSig）で行えたように「プログラムに害のない1バイトを追加して、新しいアカウントアドレスを取得する」という手法を単純に使うことができないのです。
アプリケーション・アカウントの安全性を確保するには、相互に排他（矛盾）しない2つの方法があります。
選択肢A：アプリケーションアドレスにソルト（Salt）を加える
1つ目の選択肢は、アドレスの派生メカニズムを拡張し、プロトコル駆動のアプリケーションIDに何らかのソルト（またはナンス）を組み合わせる方法です。アプリケーションの作成時に、有効なEd25519公開鍵としてデコード（解釈）されないアプリケーションアドレスが見つかるまで、プロトコルがソルトを試行し続けます。
これはロジック署名での戦略を反映したものです。メリットとしては、将来作成されるアプリケーションアカウントを、最初から直接「オフカーブ（楕円曲線上外）」のアドレスとして生成できる点にあります。
デメリットは互換性です。既存のアプリケーション、開発ツール、インデクサー、スマートコントラクト、およびオフチェーンシステムは、多くの場合「アプリのアカウントアドレスは、現在の派生ルールを使用してアプリケーションIDから決定論的に（一意に）計算できる」という前提で動いています。新しい派生ルールを導入する場合は、既存の前提を壊さないよう慎重に設計する必要があります。
選択肢B：アプリケーションアカウントに「タイプ（型）」を定義する
2つ目の選択肢は、アカウントのタイプ（種別）を台帳（レジャー）に記録し、そのタイプに一致しない認可経路を拒否する方法です。あるアドレスがアプリケーションアカウントであることが判明している場合、そのアドレスのバイト列がたまたま有効なEd25519公開鍵としてデコードできてしまったとしても、そのアドレスに対する通常のEd25519署名は受け付けない（拒否する）ようにします。
このアプローチには、個別に扱うべき2つのケースがあります。
既存のアプリケーション・アカウント： プロトコルのアップグレード時に台帳のマイグレーション（移行処理）を行い、すでに存在するアプリ用アカウントに対して「アプリケーション管理下」である旨のマーク（識別子）を付与します。
将来のアプリケーション・アカウント： アプリ用アカウントが作成されたとき、またはそのアカウントが台帳上に存在するために必要な最低残高（MBR：Minimum Balance Requirement）を受け取った時点で、プロトコルがそのアカウントを「アプリケーション管理下」としてマークします。
この方法であれば、お馴染みの「アプリケーションIDからアドレスを算出する派生ルール」をそのまま維持できます。しかし、根本的な原因が共通している2つのエッジケース（例外的な状況）が残るため、これらを明示的に処理しなければなりません。
1つのエッジケースは、「アプリケーションIDは発行されているが、まだ資金が投入（入金）されていないアプリケーション・アカウント」です。もう1つは、「将来発行される予定のアプリケーションIDに対応するアドレス」です。アプリケーションIDは予測可能であるため、将来的にアプリ用アカウントとなる予定のアドレスが、それより前に（Ed25519などの）別の認可経路の下ですでにアクティビティ（取引など）を行っている可能性があるからです。
目指すべきゴールは明確です。それは、Ed25519署名によってアプリケーションのロジックがバイパス（迂回）されるのを防ぐことです。具体的なマイグレーションの経路は、互換性を維持し、ユーザーや開発者に予期せぬ混乱を与えないものでなければなりません。
9. 単一署名（Single-signature）アカウント：承認者をFalconへ移行する
単一署名アカウントはEd25519の秘密鍵によって管理されているため、耐量子（ポストクォンタム）リスクに直接さらされています。もし公開鍵が（ネットワーク上に）露出すると、将来的に量子コンピューターを用いた攻撃者によって、対応する秘密鍵が導き出されてしまう可能性があります。
これらのアカウントに対するAlgorandの最初の施策が、Falconアカウント抽象化（Falcon account abstraction）です。
Falconアカウントは、Falcon署名を検証する「ロジック署名（LSig）」によって表現できます。ユーザーは、最初からFalconによって管理される新しいアカウントを作成することもできますし、Algorandの「リキー（rekeying、鍵の再割り当て）」機能を利用して、既存のEd25519アカウントを移行することもできます。
リキー機能が重要である理由は、「アカウントの公開アドレス」と「そのアカウントからの支出を現在承認（認可）されているアカウント（鍵）」を分離できる点にあります。ユーザーは、Algorandのアカウントアドレスをそのまま維持したまま、承認者（管理権限）だけを変更することができます。このケースでは、アカウントの承認者をEd25519から、Falconを検証するロジック署名（LSig）承認者へとリキーすることができます。
これにより、ユーザーには以下のような実用的な移行経路（マイグレーションパス）が提供されます。
CLI（コマンドラインインターフェース）を使用して、Falcon管理下のロジック署名アカウントを作成または取得する（この時点で、ツール側がロジック署名アドレスが「オフカーブ」であることを自動的に保証します）。
既存のEd25519アカウントを、そのFalcon承認者へとリキーする。
今後のトランザクションは、元のEd25519鍵ではなく、Falcon署名を通じて承認する。
ただし、利便性の面でまだいくつかの制約が存在します。Falconの公開鍵（LSigプログラムに埋め込まれる）と署名（LSigの引数として渡される）は、Ed25519の鍵や署名よりもサイズが大きくなります。そのため、現在のアカウント抽象化フローでは、必要なバイト数（容量予算）を確保するために（LSigプログラムと引数で容量を共有するため）、単一のトランザクションではなく、4つのトランザクションで構成されるグループを組む必要があります。これにより、「正確に1つの承認トランザクション」を想定しているアプリケーションや、「すでに4つ以上の承認トランザクション」が含まれているグループと相互作用（インタラクト）する際に、摩擦（不都合）が生じる可能性があります。
考えられる回避策の1つとして、アトミックな「フラッシュ・リキー（瞬間的なリキー）」パターンが挙げられます。
Falcon管理下のアカウントの権限を、一時的に（その場限りの）エフェメラル・アカウントへリキーする。
そのエフェメラルアカウントが、必要なアプリケーションとの相互作用（取引など）を実行する。
同じアトミックグループ（一連の不可分な処理）の中で、アカウントの権限を再びFalcon管理下の承認者へと戻す（リキーし直す）。
このパターンは現在の仕様でも技術的には可能ですが、運用の難易度（複雑さ）が高くなります。この摩擦を解消するには、プロトコルのアップグレードによってLSigのサイズ制限を緩和し、トランザクション・グループによる容量の「プール（共有）」に頼るのを避け、1つの抽象化されたFalconアカウントの承認を単一のトランザクションに削減する必要があります。もう1つの選択肢は、本記事の後半で定義されているような、LSigによる抽象化を挟まないネイティブな耐量子アカウントを導入することです。
しかし、プロトコル側の摩擦が完全に解消されたとしても、Falconアカウントが広く普及するかどうかは、ウォレット、カストディプロバイダー、暗号資産取引所、そして開発者向けツールが、一般ユーザーにとって「Falcon鍵の生成、保管、署名、および復元（リカバリ）」を安全に行える環境を整えられるかどうかにかかっています。
10. マルチシグ（Multisignature）アカウント：2つの異なる量子リスク
マルチシグ・アカウントは、2つの異なる耐量子リスクに直面しているため、特別な処理（対策）を必要とします。
1つ目のリスクは、ハッシュから生成される他のアカウントタイプ（LSigやアプリ用アカウントなど）にも共通する、「偶発的なアドレス（Ed25519解釈）」のリスクです。マルチシグ・アドレスは、マルチシグの構成情報（閾値や公開鍵のリスト）から派生する32バイトの識別子です。もしこの識別子が、有効なEd25519公開鍵としてもデコード（解釈）できてしまう場合、量子コンピューターを用いた攻撃者によって、そのマルチシグアドレス自体に対応する「単一の秘密鍵」が導き出されてしまう可能性があります。そうなると、せっかくの閾値（しきいち）管理アカウント（複数人の署名が必要な口座）が、単一の鍵で動かせるアカウントへと崩壊してしまいます。
2つ目のリスクは、マルチシグに特有のリスクです。マルチシグアカウントには、サブ署名者（構成員）として複数のEd25519公開鍵が含まれています。これらの公開鍵が（ネットワーク上に）露出すると、量子攻撃者はそれらを個別に標的にすることができます。もし攻撃者が、マルチシグの閾値（承認に必要な人数）を満たすのに十分な数の秘密鍵を割り出すことができれば、本来意図されていたマルチシグの経路を通じてアカウントが完全に乗っ取られてしまいます。
1つ目のリスクについては、ロジック署名（LSig）やアプリケーションアカウントのセクションで議論したような、ソルト（Salt）を追加する、あるいは「タイプ（型）」を定義するという戦略で対処できます。しかし、それでは2つ目のリスクを解決できません。サブ署名者自体が依然として（脆弱な）Ed25519公開鍵のままだからです。
ここで当然、「マルチシグの各サブ署名者を、それぞれ単にFalconへとリキー（鍵の再割り当て）すればよいのではないか？」という疑問が生じます。しかし、その答えは「ノー」です。なぜなら、マルチシグのサブ署名者は、マルチシグ構成の内部に存在する「独立したアカウント」ではないからです。それらは単なる生のEd25519公開鍵（データ）にすぎません。リキー機能は「アカウント」に対して適用されるものであり、マルチシグのテンプレート内に埋め込まれた「公開鍵」に対して適用することはできないのです。
このことは、既存のネイティブなマルチシグ構造を維持したまま耐量子セキュリティを確保するには、新しいバージョンのマルチシグ、プログラムベースのマルチシグ、あるいは耐量子プリミティブ（暗号論的原子）に基づく新しい閾値署名（しきいちしょめい）の設計が必要であることを意味しています。
既存のマルチシグアカウントの所有者にも、資金の移動や、ガバナンスモデル（運用のルール）が許すのであればアカウントを別の（安全な）承認者へとリキーするなど、いくつかの移行の選択肢は残されています。しかし、「同じアドレス」「同じ閾値ポリシー」「同じネイティブマルチシグのセマンティクス（意味論・仕様）」のすべてを維持することは、プロトコル側による受動的なマイグレーション（移行処理）だけでは保証できません。これにはマルチシグ所有者による主体的な調整（対応）と、最終的にはプロトコル側による新しい「耐量子マルチシグ」のサポートが不可欠です。
11. ネイティブな耐量子（ポストクォンタム）アカウント
LSig（ロジック署名）ベースのFalconアカウント抽象化は、重要な第一歩です。それは、Algorandのアカウントが現在でも耐量子秘密鍵によって管理できることを示しています。しかし、アカウント抽象化は、ネイティブなEd25519アカウントと完全に同等の機能（機能パリティ）を提供するわけではありません。
現在の（Algorandの）アカウントモデルでは、いくつかの箇所にEd25519公開鍵が深く組み込まれています。それらは通常の単一署名アカウントだけでなく、マルチシグ（Multisig）構成内の生の鍵として、あるいは委任ロジック署名（Delegated Logic Signatures）の署名鍵としても使用されています。Falconアカウント抽象化はプログラムを介してアカウントを管理できますが、プロトコルが現在「生のEd25519公開鍵」を想定しているすべての場所を、単純に置き換えることはできません。
完全な機能パリティを達成するためには、Algorandは最終的にネイティブな耐量子署名とネイティブな耐量子アカウントを必要とすることになります。
設計上の主な課題は、そのサイズ（データ容量）です。
Ed25519の公開鍵はわずか32バイトです。この小ささこそが、現在のアドレスモデルがこれほど優雅に機能している理由の一つです。標準的な単一署名アカウントでは、アドレスは実質的に公開鍵から構築されており、トランザクションの送信者（Sender）フィールドには、添付された署名を検証するために必要な鍵データがすでに含まれている状態になります。
耐量子デジタル署名アルゴリズムは、ハッシュベースおよび格子ベースのスキームのいずれにおいても、鍵と署名のサイズが大きくなります。Falconは、耐量子署名の候補の中で、特に公開鍵と署名のサイズに関して最も優れたトレードオフ（バランス）を提供していますが、それでもEd25519に比べるとはるかに巨大です。Falcon-512の公開鍵は897バイト、Falcon-1024の公開鍵は1,793バイトあります。
これが互換性の問題を引き起こします。Algorandのアドレスは、お馴染みのアドレスフォーマットにエンコードされた32バイトの識別子です。Falconの公開鍵をそのフォーマットに直接収めることはできません。
したがって、ネイティブなFalconアカウントは、ネイティブなEd25519アカウントと同じアドレス構築方法を使用できません。その代わりに、マルチシグ、ロジック署名、アプリケーションアカウントの思想に似た、ハッシュベースのアドレスが必要となります。
このような設計では、ドメイン分離（Domain Separator）および決定論的なソルト（Salt）とともに、Falconの公開鍵がアドレス派生のシード（種）として機能します。計算結果は依然として32バイトのアカウント識別子となり、既存のアドレスフォーマットが維持されます。生成されたアドレスは自己記述型ではありません。つまり、オブザーバー（第三者）がアドレス単体を見ただけでは、それがFalconの公開鍵から派生したものかどうかを判別することはできません。ドメイン分離は、Falconアドレスの派生ルールを他のハッシュアドレスの派生ルールと区別するための、内部的な派生安全策としてのみ機能します。これが厳密に必要かどうかは最終的なプロトコル設計に依存しますが、一般的には暗号論的な衛生管理（適切な作法）として望ましいものです。そしてソルトは、生成されたアドレスにEd25519の認可経路が偶発的に生じないことを確実にします。
これによりアドレスサイズの問題は解決しますが、新たな問題として「情報の損失」が発生します。
Ed25519では、アドレスが公開鍵と密接に結びついています。公開鍵のデータがアドレスモデルによって直接表現されているため、署名の検証には送信者アドレスと署名があれば十分です。
しかしFalconでは、アドレスは公開鍵の「ハッシュ値」にすぎなくなります。ハッシュは意図的に一方向性を持たせてあります。アドレスからFalconの公開鍵を復元（逆算）することは検証者には不可能です。そのため、ネイティブなFalconアカウントによって署名されたトランザクションは、どうにかしてFalconの公開鍵を利用可能な状態に（検証者に提示）しなければなりません。
これを行うには、大きく分けて2つの方法があります。
ステートレス（Stateless）なFalcon認可
ステートレス設計では、各トランザクションが以下の3つの情報を保持します。
送信者アドレス
Falcon公開鍵
Falcon署名
検証者はまず、Falcon公開鍵、ドメイン分離、およびソルトから送信者アドレスが正しく派生（算出）されるかをチェックします。その後、その公開鍵に対して署名の検証を行います。
これは、現在の通常の署名検証に最も近い形です。トランザクション自体に、Falconの認可経路を検証するために必要なすべての暗号データが含まれています。署名チェック自体のために、追加のアカウント状態（ステート）をルックアップ（照会）する必要はありません。
最大のメリットは並列処理（パラレリズム）にあります。ステートレスな署名は、一度有効であれば、台帳の状態（ステート）とは無関係に有効であり続けます。これにより、検証経路がシンプルになり、高度な並列処理が可能になります。
トランザクション自体が検証に必要な公開鍵を提供します。そのトランザクションがそれ以外の点で有効（残高や最低残高要件を満たしているかなど）であるかどうかは、依然として通常のプロトコルルールに依存します。
デメリットはトランザクションのサイズです。すべてのトランザクションにFalconの公開鍵を添付すると、シリアライズされたトランザクションのサイズが増大します。バイト数（データ量）に依存する手数料モデルの下では、ステートレスなFalconトランザクションは、一般的にEd25519トランザクションや、毎回公開鍵を繰り返す必要のない設計に比べてコストが高くなります。
ステートフル（Stateful）なFalcon認可
ステートフル設計では、Falcon公開鍵が最初に導入（提示）された後、その公開鍵をアカウントの記録（台帳）に保存します。そのアドレスからのそれ以降のトランザクションは、毎回公開鍵を添付する必要がなくなります。トランザクションは署名のみを保持し、検証者はアカウントのステート（状態）から公開鍵をルックアップします。
これは、リキー（Rekey）されたアカウントが、現在の承認者を決定するためにすでにアカウントステートに依存している仕組みと本質的に似ています。しかし、重要な違いがあります。ネイティブなFalconアカウントの場合、アドレスとFalcon公開鍵のマッピングは不変（イミュータブル）です。公開鍵は、単にアカウントに割り当てられた承認者というわけではなく、アドレスが派生したシード（原資）そのものだからです。暗号学的ハッシュに関する標準的な前提に立てば、そのアドレスにマッピングできる既知の鍵は、その公開鍵以外に存在しません。
実用的なアプローチの1つは、Falconの公開鍵をアカウント上の「ソフトステート（Soft State）」として扱うことです。システム設計においてソフトステートとは、利用可能であれば特定の処理を効率化できるものの、後から再構築や供給が可能であるため、システムの正確性（正当性）には必須ではない状態のことを指します。ここでのアカウントは、ステートレスなFalcon認可において最初に登場したFalcon鍵を記録（保存）します。それ以降のトランザクションでは公開鍵を省略し、台帳に記録された鍵に依存することができます。
メリットは、2回目以降の利用においてトランザクションサイズを小さく抑えられる点です。公開鍵がソフトステートとして記録されれば、それ以降の各トランザクションは、完全なFalcon公開鍵を添付するためのバイトコストを支払う必要がなくなります。
デメリットは、トランザクションが公開鍵を省略した場合、署名検証がステートフル（状態依存）になる点です。検証者は、署名をチェックする前に送信者のアカウントステートをルックアップして公開鍵を取得しなければなりません。検証の並列化自体は可能ですが、比較的低速な「台帳の読み込み（レジャー・リード）」に依存することになります。なお、Falcon公開鍵はあくまでソフトステートであるため、アカウントを一度閉じたとしてもアカウントモデルが永久に壊れるわけではありません。後から再びステートレスなトランザクションを通じて公開鍵を供給し直すことができるからです。
ステートレスおよびステートフルの両方の設計において、アドレスの派生は決定論的（デタミニスティック）かつ検証可能でなければなりません。Falconの公開鍵単体から、一意の「カノニカル（標準的）なアカウントアドレス」が決定される必要があります。もし偶発的なEd25519認可経路を避けるためにソルトを使用する場合、そのソルトはプロトコルで定義された決定論的なルール（例えば、許容可能なアドレスを生成する最も低いソルト値を選択するなど）に従って選ばれなければなりません。これにより、Falconの公開鍵を見た人なら誰でもアドレスを派生させ、それが提供された鍵と一致することを確認できます。この標準的な派生ルールがなければ、同じFalcon公開鍵が複数のアドレスに対応できてしまう可能性があり、ユーザー、ウォレット、バリデータ（検証者）にとってアカウントモデルの推論（理解や追跡）が困難になります。
ネイティブなFalconアカウントを導入したとしても、慎重な移行計画、ウォレットのサポート、あるいはアカウントごとのセキュリティ強化（ハーデニング）の必要性がなくなるわけではありません。しかし、これによって重要なギャップが埋まることになります。すなわち、アカウント抽象化だけに頼るのではなく、Ed25519と同等の機能パリティ（委任LSigやマルチシグのサブ署名者などのユースケースを含む）を備えた、プロトコルの一級市民（最優先されるプリミティブ）として耐量子署名が位置づけられるようになるのです。
12. 特殊なプロトコルアドレス
Algorandには、そのセキュリティ特性が通常のアカウントとは異なる「特殊なアドレス」も含まれています。これらのアドレスの一部はネットワーク固有（network-specific）であり、ジェネシス状態（台帳の初期状態）において定義されています。また、別の一部はプロトコルの定数（固定値）であり、どのネットワークでも共通しています。いずれの場合も、これらはユーザーが管理する通常のアカウントアドレスとは区別して考える必要があります。
ゼロアドレス（Zero address）
これはヌル（空）アドレスです。ネットワーク間で共通の定数であり、ジェネシス状態によって定義されているものではありません。このアドレスは、とりわけ、Algorand標準資産（ASA）のロールベース・アクセス制御（RBAC）の認可を不可逆的に無効化するためや、ALGOをバーン（焼却）するためなどに使用されます。純粋に数学的な意味では、すべてがゼロである32バイトの値をEd25519曲線上の点として議論することは可能ですが、これは「低位数（small-order）」の点であり、通常のアカウント認可に使用されるような有効な「カノニカルなEd25519公開鍵」ではありません。したがって、これは通常の方法で資金を支出できるアカウントではなく、耐量子のマイグレーション（移行措置）も必要ありません。
手数料シンクアドレス（Fee Sink address）
これはジェネシス状態において定義されている、ネットワーク固有の単一署名（Single-signature）アカウントです。トランザクション手数料を回収し、ブロック提案者（プロポーザー）への報酬支払いの原資となります。運用上は（対応する）秘密鍵が存在しますが、このアカウントはすでにプロトコルルールによって制限されており、通常の「決済トランザクションタイプ（ALGOの送金）」による支出行動ができないようになっています。他のトランザクションタイプに関しても、この特殊アドレスに対する秘密鍵による操作（管理権限）を完全に防止するために、追加のプロトコル制限が必要です。
報酬プールアドレス（Rewards Pool address）
このアドレスは、歴史的に「レガシー（旧仕様）なプロトコル報酬」のために使用されていました。ネットワーク固有であり、ジェネシス状態において定義されています。主要なAlgorandパブリックネットワーク（MainNet、TestNet、BetaNet）においては、このアドレスが有効なEd25519アカウント公開鍵として使用できないように定義されており、プロトコルで定義された認可経路のみが保証されています。ただし、この特性が「考えられるすべてのAlgorandネットワーク」に当てはまると想定すべきではありません。新しいネットワークが、有効なEd25519の点に対応する報酬プールアドレスを（ジェネシス設定で）選択してしまう可能性があるからです。耐量子レジャー（台帳）の安全性の保証をジェネシス状態の選択に依存させないためにも、プロトコルは報酬プールアドレスが「オフカーブ（楕円曲線上外）」であること、あるいは通常の秘密鍵認可によって支出できない仕様であることを義務付けるべきです。
状態証明アドレス（State Proofs address）
これは、状態証明（State Proofs）トランザクションの送信者（Sender）として唯一許可されているアドレスです。ネットワーク間で共通の定数であり、ジェネシス状態では定義されていません。これは合成されたハッシュベースのアドレスですが、ロジック署名（LSig）アカウントのようにプログラムから派生したものでも、アプリケーションアカウントのようにプロトコル全体の連番IDから派生したものでもありません。その代わりに、ドメイン分離プレフィックスである SpecialAddr と、ASCII文字列の StateProofSender を一緒にハッシュ化することで計算されます。状態証明トランザクションはプロトコルによって制約されています。さらに、このアドレスは有効なEd25519の点とも関連付けられていません。これらの条件に基づき、この特殊アドレスに対する耐量子マイグレーションは必要ありません。
ハートビートアドレス（Heartbeat address）
このアドレスは、コンセンサス参加の生存性（ライブネス）メカニズムに使用されます。ネットワーク間で共通の定数であるLSig（ロジック署名）アカウントであり、ジェネシス状態で定義されているものではないため、プロトコルの仕様書（スペック）の一部ではなく、コンセンサスのアップグレードを行わずにローテーション（変更）することが可能です。このアドレスは、デコンプレス（復元）すると有効なEd25519の点になります。したがって、耐量子環境下においては、量子攻撃者がライブネス応答を偽装したり、最悪の場合LSigをリキー（権限上書き）したりできないよう、このアドレスを「オフカーブ」なLSigアドレスへとローテーションするべきです。
重要な違い：
これら（特殊アドレス）の管理は、プロトコルのルールによって統治されています。そのため、その制御が特定の「署名スキーム」だけに依存しているような、通常のアカウントと同列に扱うべきではありません。
13. 移行（マイグレーション）の課題はプロトコルよりも大きい
耐量子（ポストクォンタム）への移行は、単なるプロトコル工学上の問題にとどまりません。それはエコシステム全体の「協調」と「標準化」の問題です。
ブロックチェーン（プロトコル層）が耐量子プリミティブを導入したとしても、ユーザーはそれをサポートするウォレットを必要とします。暗号資産取引所やカストディアン（資産管理業者）は、鍵の生成、保管、署名、および復元（リカバリ）に関する運用手順を整備しなければなりません。ハードウェア（ウォレット）プロバイダーは、安全な実装を行う必要があります。開発者は、明確なツール群と予測可能なアカウントモデルを必要とします。
また、移行にあたっては2つの極端な（行き過ぎた）状況を避けなければなりません。
1つ目の極端な例は、「目に見える量子脅威が現れるまで何もしない」ことです。これはパニック的な移行を招くリスクがあり、ユーザーが一斉にアカウントの移動やリキー（鍵変更）に殺到し、ブロック容量（スペース）を奪い合い、運用のミスを増大させる結果となります。
2つ目の極端な例は、「グローバルな移行を急進的に強制する」ことです。ユーザーの同意や十分な準備なしに、プロトコルが一方的に既存の認可経路（Ed25519など）を無効化した場合、ユーザーはアカウント、資金、アプリケーション、あるいはガバナンスにおける役割（投票権など）へのアクセスを失う可能性があります。このような強制的な移行は、防ごうとしている攻撃そのものと同等の被害をもたらしかねません。
より良いアプローチは、「段階的（漸進的）」かつ「オプトイン（任意選択）」な経路をたどることです。
考えられるモデルの1つとして、「遅延移行（Lazy Migration）」が挙げられます。このモデルでは、アカウントは通常通りに運用を続けながら、あらかじめ「耐量子用のフォールバック（代替）承認者」を事前に宣言（登録）しておくことができます。その後、将来的にネットワークが脆弱な認可経路を無効化する必要が生じた際、プロトコルはオプトイン（事前登録）しているアカウントのみを、その事前宣言された耐量子承認者へと切り替えます。
これにより、緊急事態が到来する前に、ユーザーに準備のための時間を与えることができます。また、複雑なカストディ（管理体系）やガバナンス、アプリケーションへの依存関係を持つアカウントに対して、「一画一律（ワンサイズ・フィッツ・オール）」な移行を押し付けることも回避できます。
14. 総合戦略
Algorandの耐量子アカウント戦略は、単一のメカニズム（アプローチ）だけで構成されているわけではありません。それは、稼働中の台帳（ライブレジャー）から量子的に脆弱な管理経路を排除するという同一のゴールを目指す、アカウントタイプごとの対策の集合体です。
その戦略は以下のように要約されます。
ハッシュ由来のアドレス： グローバーのアルゴリズム（Grover’s algorithmー）による量子的加速を含め、特定のターゲットを狙った「第二原像攻撃（セカンド・プリイメージ攻撃）」に対する衝突耐性を維持する。
単一署名（Single-signature）アカウント： 適切なケースでリキー（Rekeying）機能を利用し、Ed25519による認可からFalconベースの認可へと移行する。
ロジック署名（Logic Signature）アカウント： コンパイラやアセンブラによる「自動的なソルト（Salt）追加」を通じて、プログラムから派生するアドレスが確実に「オフカーブ（楕円曲線上外）」になるようにする。
アプリケーション・アカウント： ソルト付きのアドレス派生、アカウントのタイプ定義、または既存および将来のエッジケースを処理するそれらの組み合わせを通じて、プロトコルレベルの戦略を導入する。
マルチシグ（Multisignature）アカウント： 「偶発的なアドレス（Ed25519解釈）」のリスクと「露出したサブ署名者（構成鍵）」のリスクの両方を認識し、所有者による主体的な移行と、将来の耐量子マルチシグのサポートを計画する。
ネイティブな耐量子アカウント： 公開鍵の持ち運び、キャッシュ、および検証の方法を決定しつつ、Falconをプロトコルの「一級市民（最優先されるネイティブなプリミティブ）」として導入する。
特殊アドレス： プロトコルが管理するアドレスを、ユーザーが管理する通常のアカウントとは区別して別個に処理する。
ここでの核心的なアイデアは、「耐量子レジャー（台帳）のセキュリティとは、単に一つの署名スキームを置き換える以上の意味を持つ」ということです。それは、Algorandのアドレスが認可され得る「あらゆる経路」を検証し、それらの経路のいずれもが量子的攻撃者によって悪用されないことを確実にするということを意味します。
Algorandは、状態証明（State Proofs）におけるFalconの採用や、Falconアカウント抽象化によるFalconベースのトランザクション認可の実証など、すでに重要なステップを踏み出しています。残された課題は、これらのビルディングブロック（構成要素）を、包括的で「暗号俊敏（クリプト・アジャイル）」なアカウント移行戦略へと昇華させることです。すなわち、新しいアカウントにとっては「初期設定（デフォルト）で安全」であり、既存のアプリケーションと「互換性」があり、そしてユーザー、ウォレット、カストディアン、開発者にとって「実用的」な戦略を構築することです。
これこそが、Algorandが「ブロックチェーンの過去の歴史を守ること」から、「現在稼働している台帳（ライブレジャー）そのものを守ること」へとシフトするための確実な道筋です。
コメント