はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、バリデータ登録時にBLS鍵（複数の署名を1つにまとめられる署名方式）を必須化する仕組みを提案しているACP62についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。
概要
ACP62は、これまでP-Chain（Avalancheのステーキングやサブネット管理を担うチェーン）で使われてきたAddValidatorTxとAddDelegatorTxという古い登録用トランザクションを「無効化」し、今後はAddPermissionlessValidatorTxとAddPermissionlessDelegatorTxという新しい形式だけに統一する提案です。
新形式ではバリデータ（検証者）がBLS鍵（集約署名に対応した公開鍵暗号の鍵）をノードのNodeIDに登録することが必須になります。
これによりネットワーク全体でBLS鍵が広く登録・普及し、今後のP-Chainアップグレード（BLSに基づく機能）を素早く進められるようになります。
また、プライマリネットワークへの参加方法が二系統から一系統に整理され、仕様と実装の一貫性が高まります。
動機
2022年10月のBanff（v1.9.0）で、承認者の許可を要しない「Permissionless（承認不要）」型のAddPermissionlessValidatorTxとAddPermissionlessDelegatorTxが導入されました。
これにより、サブネット（独自のL1チェーン）の作成者は、自分たちのトークンを担保にして、そのサブネット上でProof-of-Stake（PoS：トークン保有量に応じて検証権限を与える方式）を有効化できるようになりました。
さらに、この新形式はプライマリネットワークのバリデータ登録にも使えるため、従来のAddValidatorTx/AddDelegatorTxと用途が重なり、同じ目的を達成する手段が二通り存在する状態になりました。
新形式と旧形式の違いは以下です。
トランザクション形式の対応関係と差分
| 対象 | 旧形式 | 新形式 | 主な差分 |
|---|---|---|---|
| デリゲータ（委任者）登録 | AddDelegatorTx |
AddPermissionlessDelegatorTx |
新形式は旧形式の全フィールドに加えてSubnetフィールドを持ちます。 |
| バリデータ（検証者）登録 | AddValidatorTx |
AddPermissionlessValidatorTx |
新形式は旧形式の全フィールドに加えてSubnetとSigner（BLS鍵登録用情報）を持ち、さらにRewardsOwnerがValidationRewardsOwnerとDelegationRewardsOwnerに分割されます（デリゲータからの報酬の受け取り先を分けられる）。 |
ここで重要なのは、新形式ではバリデータ登録時にBLS鍵をNodeIDへ確実に結び付けられる点です。
ACP62は、旧形式（AddValidatorTx/AddDelegatorTx）をDurangoアップグレードで無効化し、今後の新規登録は新形式に一本化することで、BLS鍵の登録を事実上の標準にすることを狙っています。
BLS鍵が広く登録されると、以下のようなBLS活用型の機能追加を、将来のACP（AvalancheConsensusProposal）でスムーズに進められるようになります。
BLS普及で可能になる具体的な応用
任意報酬カーブのElasticSubnet
現状、ElasticSubnetの報酬はTransformSubnetTxで定義された固定の報酬カーブ（どのように報酬が増減するかの曲線）に従います。
BLS鍵が十分に普及すれば、Subnet側が独自に決めた報酬カーブや報酬条件を使えるように拡張できます。
仕組みとしては、Subnetバリデータの合意を表すメッセージをBLSマルチシグネチャ（複数の署名を集約した1つの署名）でP-Chainに提出し、「誰にいくら報酬を与えるべきか」をP-Chainが受け取って反映する形を想定しています。
BLSにより署名は1つに集約されるため、検証が高速・軽量になります。
Subnetの状態アテステーション
ElasticSubnetの現在のステート（例：特定ブロックの情報）について、SubnetバリデータのBLSマルチシグネチャで「正当性の証明（アテステーション）」を発行できるようになります。 これにより、クライアントはSubnet全体を同期しなくても、APIノードから「この情報はSubnetバリデータの合意で正しいと証明されている」という形で取得・検証できます。
既存のStateSyncは「最新版付近のステートをピアからダウンロード」する仕組みですが、どのピアの回答が正しいかの突き合わせはクライアント側の責務でした。
アテステーションがあれば、署名の検証だけで正しさを確信しやすくなるため、クライアント実装が簡素化しやすくなります。
特に、Subnet-OnlyValidator（プライマリネットワーク全体を検証しない、Subnet専用のバリデータ）がC-Chainに関する情報を証明する場合などで、外部照会の負担を減らせる効果が期待されます。
なぜ「一本化」と「BLS鍵の必須化」が重要か
仕様の単純化
登録経路が2つあると、ウォレットやノード実装、監視運用で分岐が発生します。 1つにすることで実装・運用・ドキュメントがわかりやすくなります。
BLS前提の将来拡張の地ならし
BLSの利点は集約です。 多人数の同意を短い1つの署名にまとめられるため、帯域・検証計算の負荷を大きく減らせるのが本質的な価値です。 BLS鍵の登録が広がれば、報酬・アテステーション・クロスチェーン連携などの**BLS活用機能を、ACPで安全に段階導入しやすくなります。
インセンティブ設計の自由度
ValidationRewardsOwnerとDelegationRewardsOwnerの分離によって、バリデータ自身の報酬とデリゲータ経由の報酬の受け取り先や会計を整理しやすくなります。
組織的運用や報酬管理の柔軟性が上がります。
新形式の登録フロー
sequenceDiagram
participant Operator as ノード運用者
participant Node as ノード(NodeID)
participant PChain as P-Chain
Operator->>Node: BLS鍵ペアを生成・設定（公開鍵をNodeIDに紐づけ）
Operator->>PChain: AddPermissionlessValidatorTx提出（Subnet, Signer, RewardsOwner情報含む）
PChain-->>PChain: トランザクション検証（署名・期間・ステーク量など）
PChain->>Node: 登録完了（NodeIDにBLS公開鍵が紐づく）
Note right of PChain: 今後のBLS機能（報酬やアテステーション）を活用可能にSubnetアテステーションの利用イメージ
sequenceDiagram
participant SubnetVals as Subnetバリデータ集合
participant API as APIノード
participant Client as クライアント
SubnetVals->>SubnetVals: 状態に合意し、BLSマルチシグネチャを生成
SubnetVals->>API: 「この状態は正当」メッセージ＋BLS集約署名を公開
Client->>API: 状態と署名の取得
Client-->>Client: 登録済み公開鍵でBLS署名を検証
Client->>Client: Subnetをフル同期せずに状態を信頼仕様
ACP62は、ネットワークの有効化時点（activation）以後に限り、AddValidatorTxとAddDelegatorTxをメモリプール（mempool）に追加された時点で即座に「破棄（dropped）」扱いにし、さらにそれらを含むブロックを「無効（invalid）」と見なす、という2つを定めています。
activation（有効化）とは何か
ここでいうactivationは、ネットワーク全体で合意された有効化ポイント（例えば特定のアップグレード名・ブロック高・時刻）を指します。 このポイントを境に、旧形式の扱いが「許可→不許可」に切り替わることが仕様のコアです。 有効化前は既存のルールに従って取り扱われますが、有効化後は本仕様のルールが必ず適用されます。
有効化後のメモリプール処理
有効化後にノードがAddValidatorTxまたはAddDelegatorTxを受け取った場合、メモリプールに入れずにその場で破棄（dropped）します。
処理フロー
flowchart TD
A[トランザクション受信] --> B{activation後か?}
B -- いいえ --> C[従来ルールで判定/処理]
B -- はい --> D{Txが旧形式か? \n AddValidatorTx/ AddDelegatorTx}
D -- いいえ --> E[通常のmempool受理]
D -- はい --> F[破棄 dropped]有効化後のブロック検証
バリデータや提案者が作成したブロックに、上記2種類の旧形式トランザクションが1つでも含まれている場合、そのブロックはすぐに無効（invalid）と見なされます。 無効ブロックはチェーンに取り込まれません。
処理フロー
flowchart TD
A[ブロック受信/提案] --> B{activation後か?}
B -- いいえ --> C[従来ルールで検証]
B -- はい --> D{ブロック内Txに\n旧形式が含まれるか?}
D -- いいえ --> E[ブロック有効]
D -- はい --> F[ブロック無効 invalid]動作マトリクス
| 時点 | 対象トランザクション | メモリプール受理 | ブロックへの取り込み | ブロック有効性 |
|---|---|---|---|---|
| 有効化「前」 | AddValidatorTx / AddDelegatorTx |
従来ルールに従う | 従来ルールに従う | 従来ルールに従う |
| 有効化「後」 | AddValidatorTx / AddDelegatorTx |
受理不可（即時dropped） | 取り込み不可（含まれた場合は違反） | 旧形式を含むブロックはinvalid |
互換性
この変更はトランザクション種別の無効化がノードの実行挙動（ステート遷移と検証規則）を変えるため、アップグレード（mandatoryupgrade）が必要になります。 ここでいう有効化（activation）は、ネットワーク全体で合意された切替点（アップグレード名・ブロック高・時刻など）を指し、その時点までは既存の挙動を一切変えないことが実装者の必須要件です。
有効化後は、新たに発行されたAddValidatorTxとAddDelegatorTxは無効（invalid）と判定され、ネットワークで破棄（dropped）されます。
これらに依存していた利用者（consumers：生成・送信・受理・解析などで旧形式を前提にするソフトウェアや運用）は、AddPermissionlessValidatorTxとAddPermissionlessDelegatorTxへ移行する必要があります。
移行先の2形式はAvalancheLedgerAppでサポートされています。
なお、AddSubnetValidatorTxおよびRemoveSubnetValidatorTxはACP62の影響を受けません（変更なし）。
有効化前後の動作マトリクス
| 時点 | 対象トランザクション | メモリプール受理 | ブロックへの取り込み | ブロック有効性 |
|---|---|---|---|---|
| 有効化「前」 | AddValidatorTx / AddDelegatorTx |
従来ルールに従う | 従来ルールに従う | 従来ルールに従う |
| 有効化「後」 | AddValidatorTx / AddDelegatorTx |
受理不可（即時dropped） | 取り込み不可（含まれた場合は違反） | 旧形式を含むブロックはinvalid |
参考実装
AddValidatorTxとAddDelegatorTxを無効化する実装は、すでにこのPRで作成されています。
ただし有効化まではAvalancheGoは旧形式を受理し続けます。
つまり、コードは先に備わっていてもネットワークの有効化シグナルが来るまでは挙動が切り替わらない段階的導入です。
最後に
今回は「バリデータ登録時にBLS鍵（複数の署名を1つにまとめられる署名方式）を必須化する仕組みを提案しているACP62」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
