# [ACP13] Subnet専用Validatorの仕組みを理解しよう！

> ACP13では「Subnet-Only Validators（SOVs）」という新しいタイプのバリデータを導入することが目的です。

- URL: https://cardene.dev/articles/fb5625058f8ff4bc9bc0
- 公開日: 2025-09-02
- 更新日: 2025-09-02
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、PrimaryNetworkを検証せずにSubnetだけを検証できる新しいValidator（Subnet-OnlyValidators）を導入し、初期コストとリソース負担を軽減しながらAvalancheWarpMessagingにも参加できるようにする仕組みを提案している**ACP13**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/13-subnet-only-validators/README.md

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

**ACP13**では「**Subnet-Only Validators（SOVs）**」という新しいタイプのバリデータを導入することが目的です。
SOVはAvalancheのPrimaryNetworkを同期したりバリデートしたりすることなく、特定のSubnetのみを検証し、AvalancheWarpMessaging（AWM）に参加できる仕組みです。
従来、SubnetValidatorになるためにはまずPrimaryNetworkValidatorとして2000AVAX以上をステーキングする必要がありました。
しかしSOVはその必要がなく、代わりに500AVAXの返還可能な登録料をP-Chainに支払うだけでSubnetValidatorとして活動できるようになります。

さらに、**ACP13**は将来的に「**Pay-As-You-Go型のSubnetValidation**」や「**AVAXによるセキュリティ強化（AVAX-Augmented Subnet Security）**」への移行を見据えています。
既存のPrimaryNetworkValidatorによるSubnetValidationの仕組みはそのまま維持されるため、これまでの動作仕様やルールが変更されることはありません。

## 動機

Avalancheの現在の仕組みでは、SubnetValidatorになる前にPrimaryNetworkValidatorとなる必要があります。
その条件として2000AVAX（執筆時点で約2万ドル）をステークする必要があり、8台以上のSubnetValidatorを立ち上げると少なくとも16000AVAX（約16万ドル）が必要になります。
さらに、各ValidatorはPrimaryNetwork全体（X-Chain、P-Chain、C-Chain）を同期・検証するために8vCPU、16GBRAM、1TBストレージといった大きなリソースをを確保する必要があります。
その上で各Subnet固有の負荷にも対応しなければなりません。

AWM（AvalancheWarpMessaging）はAvalancheに組み込まれたネイティブのクロスチェーン通信の仕組みであり、Subnets同士やC-Chainとのやり取りを仲介者なしで実現します。
この仕組みを機能させるためには、SubnetValidatorがBLS鍵を登録し、BLSマルチシグ署名に参加できることが重要です。
十分な署名参加がないとAWMが機能しなくなります。

また、金融規制の影響を受ける機関などは、C-Chainのようなパーミッションレスかつスマートコントラクトを扱うブロックチェーンを直接検証することが許可されていないため、現在のルールではSubnetを立ち上げることができません。
これは不動産や証券といった実世界資産（RWA）をAvalanche上で扱おうとする事業者にとって大きな障壁となっています。
もしSOVが導入されれば、これらの事業者はPrimaryNetworkをバリデートせずにSubnetを立ち上げ、AWMを通じてC-Chainや他のSubnetと接続できるようになります。

さらに、現状の仕組みでは、Subnetの利用量が急増しても、PrimaryNetworkに支払う手数料の額は固定されたままで増減しません。
しかしSubnetValidatorはPrimaryNetworkのValidatorでもあるため、リソース不足に陥るとOOMエラーやディスク性能低下などが発生し、結果としてPrimaryNetwork全体やSubnetが不安定になる恐れがあります。
SOVはSubnetに専念するため、こうしたリソース競合のリスクを減らすことができます。

最後に、ElasticSubnetsは各コミュニティが独自のトークンを使ってバリデーションを重み付けし、稼働率の高いValidatorを報酬できる仕組みを持っています。
しかし、現在の仕様ではAVAX保有者がこれらのSubnetのセキュリティを強化する手段は存在しません。
SOVは、将来的に「**AVAXによるセキュリティ強化**」を組み合わせるための可能性を広げる仕組みとしても位置づけられています。

## 仕様

SOVは、従来のPrimaryNetworkValidatorとは異なる新しいバリデータの形態であり、Subnetの検証とAvalancheWarpMessaging（AWM）への参加を可能にします。

### 必要な変更点

SOVを導入するために想定されている主な変更点は以下です。
これを整理すると、従来の仕組みに加えて新しいオプションが追加される形になります。

| 項目 | 説明 |
| ----| ---- |
| Subnet-OnlyValidatorsの導入 | PrimaryNetworkを同期・検証せずにSubnetを検証し、AWMに参加できる新しいバリデータタイプを追加する。 |
| 登録時のロック（返還可能） | SOVとして活動するには、500AVAXを「ロック」としてP-Chainに預ける必要がある。この金額は返還される。 |
| 登録手数料（返還不可） | 登録時に0.1AVAXの手数料を支払う。これは返還されない。 |
| 新しいトランザクションタイプ | P-Chain上に`AddSubnetOnlyValidatorTx`という新しいトランザクションを追加し、SOVの登録を可能にする。 |
| 部分同期モードの導入 | AvalancheNodeClient（ANC）に、PrimaryNetworkの完全検証を無効化し、P-Chainのみ同期する「最小モード」を追加する。 |
| IP追跡機能 | ANCがSOVのIPを管理し、SubnetValidator同士がPrimaryNetworkValidatorでなくてもピアを見つけられるようにする。  |
| レート制限 | PrimaryNetworkValidatorと同様に、SOVにもレート制限の許容量を保証する。 |

SOVはPrimaryNetworkをバリデートしないため、500AVAXのロックに対して報酬（ステーキング報酬）は得られません。
その代わり、必要なAVAXの初期負担が小さくなり、インフラコストも削減できます。
また、同期対象がP-Chainだけで済むため、X-ChainやC-Chainにリソースを割く必要がなく、より柔軟なハードウェア構成でSubnetを運用できます。
必要に応じて、従来通りPrimaryNetwork全体を同期することも可能です。

### 将来の拡張案

今回の仕様はあくまで最小限の追加変更ですが、この仕組みを土台に将来さらに発展させることが想定されています。
提案されている拡張案は以下の2つです。

#### Pay-As-You-Go型の登録料金

従来のように一度に多額のAVAXをロックする代わりに、時間に応じて少額の料金を継続的に支払う方式に移行するというアイデアです。

* SubnetValidatorは、各Subnetごとに秒単位でAVAXを支払う。
    支払いは「**SubnetValidatorのアカウント**」から引き落とされる。
* 料金は需要と供給のバランスに応じて決まる。
    一定の期間中は料金が固定され、突然のコスト上昇を避けられる。
* 想定される最低料金は約512〜4096nAVAX/秒（1.3〜10.6AVAX/月）。
* 支払った手数料はBurnすることもできるし、一部をPrimaryNetworkValidatorに報酬として分配することもできる。

この方式により、初期コストを抑えてSubnetValidatorを始めやすくし、利用量に応じたコスト構造を作り出すことが可能になります。

#### AVAXによるセキュリティ強化（AVAX-Augmented Security）

ElasticSubnetでは独自トークンをステークしてValidatorを守る仕組みがありますが、これをAVAXでも補強できるようにする提案です。

* 保有しているAVAXをSubnetValidatorにロックし、Validatorが不正行為をした場合はスラッシュ（没収）される。
* 不正がなければ、ElasticSubnetの報酬トークンを受け取れる。
* ロックはすべてP-Chain上で行われ、証拠の処理もPrimaryNetworkで実施される。
    これにより、Subnet内での不正隠蔽が防げる。
* 外部例としては、EigenLayerでETHを使ってデータ可用性を強化する仕組みや、BabylonでBTCを使ってCosmosZoneを守る仕組みに似ている。

このアプローチにより、ElasticSubnetのセキュリティをAVAX全体の経済規模と結びつけることができ、より堅牢な仕組みが期待できます。

## 互換性

**ACP13**を導入しても、既存のSubnetValidationの仕組みはそのまま維持されます。
すでにPrimaryNetworkValidatorとしてSubnetを検証している参加者は、そのまま今まで通りの運用を続けられます。
SOVはあくまで新しい選択肢であり、報酬を得る代わりに初期コストやインフラ負担を軽くしたい人向けの仕組みです。

ただし、新しいトランザクションタイプ`AddSubnetOnlyValidatorTx`をP-Chainに追加する必要があるため、AvalancheNetwork全体のアップグレードが必須となります。

## リファレンス実装

**ACP13**が「**実装可能（Implementable）**」と判断された段階で、完全な実装が提供される予定です。現時点ではいくつかの初期案が示されています。

#### `AddSubnetOnlyValidatorTx`

SOVを登録するための新しいトランザクションです。
基本的には既存の`AddPermissionlessValidatorTx`と似ていますが、ステークアウト（StakeOuts）がロックアウト（LockOuts）に置き換わっています。

```text
type AddSubnetOnlyValidatorTx struct {
	// Metadata, inputs and outputs
	BaseTx `serialize:"true"`
	// Describes the validator
	// The NodeID included in [Validator] must be the Ed25519 public key.
	Validator `serialize:"true" json:"validator"`
	// ID of the subnet this validator is validating
	Subnet ids.ID `serialize:"true" json:"subnetID"`
	// [Signer] is the BLS key for this validator.
	Signer signer.Signer `serialize:"true" json:"signer"`
	// Where to send locked tokens when done validating
	LockOuts []*avax.TransferableOutput `serialize:"true" json:"lock"`
	// Where to send validation rewards when done validating
	ValidatorRewardsOwner fx.Owner `serialize:"true" json:"validationRewardsOwner"`
	// Where to send delegation rewards when done validating
	DelegatorRewardsOwner fx.Owner `serialize:"true" json:"delegationRewardsOwner"`
	// Fee this validator charges delegators as a percentage, times 10,000
	DelegationShares uint32 `serialize:"true" json:"shares"`
}
```

#### `GetSubnetPeers`

SOVのIPアドレスを追跡するために、新しいP2Pメッセージが追加されます。
これによりSubnetValidator同士が互いにピアを見つけやすくなります。

```text
message GetSubnetPeers {
    bytes subnet_id = 1;
}
```

このリクエストに対しては`PeerList`メッセージで応答します。
将来的にはブルームフィルタを活用して、相手がまだ知らないピアのみを送るといった最適化も考えられています。

## セキュリティ

#### 部分同期モードにおける制約

SOVは「**部分同期モード（PartialSyncMode）**」で動作することができます。
このモードでは、P-Chainの全履歴を検証せずに、Validatorセットの変化など必要最低限の情報だけを同期します。
ただし、この方法を選択したSubnetValidatorは「**AtomicImport**」を直接検証できなくなります。
AtomicImportとは、複数のチェーン間で資産を移動するときに使われる仕組みです。
部分同期モードでは、この検証を自ら行わず、PrimaryNetworkの合意結果を全面的に信頼して「**正しいブロックだけがP-Chainで受け入れられている**」と仮定することになります。
つまり、柔軟さを得る代わりに、セキュリティの一部をPrimaryNetworkに委ねる形となります。

#### 高スループットSubnetとPrimaryNetworkの隔離

利用量が急増する高スループットSubnetは、従来の仕組みではPrimaryNetworkValidatorに大きな負荷を与えるリスクがありました。
しかしSOVを導入すると、Subnet側の処理がPrimaryNetworkValidatorから分離されるため、Subnet内でのトラフィック急増が直接PrimaryNetworkを不安定化させることを防げます。
結果として、ネットワーク全体の堅牢性や安定性を高めることにつながります。

#### ANCによるリソース確保

AvalancheNetworkClients（ANCs）は、SOVがPrimaryNetworkValidatorでなくても、Subnet内のピア発見や通信を円滑に行えるようにSOVのIPアドレスを管理します。
さらに、ANCはSOVに対して帯域（通信容量）を適切に割り当てる必要があります。
これにより、SOVがSubnetに参加しても通信性能や安定性が損なわれないよう保証する仕組みが求められます。

## 未解決の課題

**ACP13**はSubnetとPrimaryNetworkの関係性を大きく見直す流れの一部であり、長期的に続く議論になることが想定されています。
そのため、開発者やコミュニティが同じ方向を向いて議論できるように、この取り組み全体にわかりやすいプロジェクト名を付けるべきかどうかが問題提起されています。

一部では、これを「**AstraUpgradeTrack**」と呼んでいますが、この名称が適切かどうかは議論の余地があります。
名前を付けることで議論の枠組みが整理される一方で、逆に混乱を招く可能性もあるため、コミュニティ全体での合意形成が必要とされています。

## 最後に

今回は「PrimaryNetworkを検証せずにSubnetだけを検証できる新しいValidator（Subnet-OnlyValidators）を導入し、初期コストとリソース負担を軽減しながらAvalancheWarpMessagingにも参加できるようにする仕組みを提案している**ACP13**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://chaldene.net/

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4