# [ACP151] ICM検証を高速化するBlockHeight参照変更の仕組みを理解しよう！

> ACP151は、ProposerVM（ブロックを組み立てるときに内側のVMへ補助情報を渡すコンポーネント）が、内側のVM（EVMなど）へ渡すP-Chainの**BlockHeight（ブロック番号）を、「親ブロックのBlockHeight」

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

## はじめに

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

https://amzn.asia/d/gxvJ0Pw

今回は、ProposerVMが内側のVMに渡すP-ChainのBlockHeightを「**親ブロックのBlockHeight**」ではなく「**現在構築中のブロックのBlockHeight**」に切り替え、ICM集約署名の検証で最新のバリデータ集合を使って待機時間を減らす仕組みを提案している**ACP151**についてまとめていきます！

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

https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/151-use-current-block-pchain-height-as-context/README.md

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

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

## 概要

**ACP151**は、ProposerVM（ブロックを組み立てるときに内側のVMへ補助情報を渡すコンポーネント）が、内側のVM（EVMなど）へ渡すP-Chainの**BlockHeight（ブロック番号）**を、「**親ブロックのBlockHeight**」ではなく「**いま構築中のブロックに対応するBlockHeight**」に切り替えるものです。
内側のVMは、このP-ChainのBlockHeightを基準にAvalancheInterchainMessages(ICM)の**集約署名（複数の署名をひとつにまとめたもの）**を検証します。
基準を「**構築中の現在のBlockHeight**」に合わせることで、どのバリデータが署名に参加すべきかをより確実に判定でき、不要な待機期間を取り除けます。

:::message
#### 内側のVMとは？

「**内側のVM**」とは、ProposerVMの下で実際にトランザクション処理やメッセージ検証を担う仮想マシンを指します。
Avalancheでは、ブロックを組み立てる役割を持つProposerVMが上位にあり、その内部でEVMなどのアプリケーションVM（＝内側のVM）が動作しています。

* **ProposerVM**
    ブロックの生成や外部との調整を担当し、補助情報（BlockHeightなど）を内側のVMに渡す。
* **内側のVM（EVMなど）**
    実際のトランザクション実行やICMメッセージの署名検証を行う。
:::

以下の表は、何をどの時点の情報で検証するかの違いを要点だけ並べたものです。

| 観点 | 現状 | 提案後 |
| ---- | --- | ----- |
| 内側のVMに渡すP-ChainのBlockHeight | 親ブロックのBlockHeight    | 構築中ブロックのBlockHeight  |
| ICMの集約署名検証に使う基準 | ひとつ前の時点 | いま構築している時点 |
| 期待される効果  | 参加バリデータの判定が遅れがち／待機発生 | 参加バリデータをより確実に判定／待機削減 |

:::message
* P-Chain
    Avalancheのプラットフォームチェーン。
    バリデータ集合やステーキングを管理します。
* ProposerVM
    ブロック組み立て時に内側のVMに必要情報を渡す上位の仕組みです。
* 内側のVM
    EVMなど、実際のトランザクション実行やメッセージ検証を担うVMです。
* ICM（AvalancheInterchainMessages）
    チェーン間でやり取りされるメッセージの仕組みです。
* 集約署名
    複数の署名をひとつにまとめた署名です（ここでは方式の詳細には立ち入りません）。
:::

#### 現状：親ブロックのBlockHeightを使用

```mermaid
sequenceDiagram
    autonumber
    participant ProposerVM
    participant InnerVM
    participant P-Chain
    ProposerVM->>InnerVM: 親ブロックのBlockHeightを渡す
    InnerVM->>P-Chain: ICM集約署名の検証（親BlockHeight基準）
    note over InnerVM: 参加すべきバリデータ集合の反映に待機が発生
```

#### 提案後：構築中ブロックのBlockHeightを使用

```mermaid
sequenceDiagram
    autonumber
    participant ProposerVM
    participant InnerVM
    participant P-Chain
    ProposerVM->>InnerVM: 構築中ブロックのBlockHeightを渡す
    InnerVM->>P-Chain: ICM集約署名の検証（現在のBlockHeight基準）
    note over InnerVM: 参加判定の鮮度が上がり、不要な待機を削減
```

## 動機

いまはProposerVMが親ブロックのBlockHeightを内側のVMに渡し、内側のVMはその値を基準に「**いま作っているブロック内**」に含まれるICMメッセージを検証しています。
親ブロックのBlockHeightを使うこと自体は、該当ブロックの提案者の正当性確認や現在ブロックの合意形成には必要です。
しかし、ブロック内でのICMメッセージの検証まで同じ基準に縛られる必要はありません。

ここを構築中ブロックのBlockHeightに切り替えると、ICMメッセージでバリデータ集合を変更する操作（例えば**ACP77**で述べられる種類のもの）を、より早く、より確実に検証できます。

:::message
**ACP77**については以下の記事を参考にしてください。
:::

[\[ACP77\] バリデータ管理をL1に移す仕組みを理解しよう！](/articles/3c28cdfe275253b75da5)

現在の方法では、該当する状態変更が起きてから少なくとも2つの新しいP-Chainブロックが生成されないと、その変更がICMの集約署名検証に反映されません。
結果として、署名に参加すべきバリデータの集合を評価するまでに待機が生じ、検証の鮮度や信頼性にも影響します。

提案どおり構築中ブロックのBlockHeightを参照すれば、この反映遅延を短縮でき、不要な待機期間を取り除けます。
つまり、合意形成に必要な前提（親ブロックのBlockHeight）と、ICMメッセージの検証に必要な前提（構築中のBlockHeight）を分けて扱うことで、ICM経由でのバリデータ集合変更のような操作をより早期かつ安定的に取り込める、というのがこの提案の狙いです。

## 仕様

#### BlockContextとPChainHeightの役割

AvalancheGoには`block_context`という仕組みがあり、その中には`PChainHeight`というフィールドが含まれています。
この`PChainHeight`はProposerVMから内側のVM（EVMなど）に渡され、内側のVMがブロックを構築する時に利用されます。
具体的には、内側のVMがICM（Avalanche Interchain Message）の集約署名を検証するために、正しいバリデータ集合を取得する基準として参照されます。

Avalancheの設計では、どのバリデータが署名すべきかを判断するために、P-Chainのある時点（BlockHeight）で確定した「**正規のバリデータ集合（canonical validator set）**」を使用します。
`PChainHeight`は、その集合を引き出すための基準となる数値です。

#### 現状の動作

現在の実装では、ProposerVMが内側のVMへ渡す`PChainHeight`は「**親ブロックのBlockHeight**」となっています。
つまり、いま構築しているブロックそのものの高さではなく、そのひとつ前のBlockHeightを基準としてバリデータ集合を参照しています。

この挙動は、ブロックの提案者を検証したり、合意形成に必要な情報を確認したりする点では正しい動きです。
しかし、ICMメッセージを検証するためにまで「**親ブロックのBlockHeight**」を用いるのは、必ずしも必要ではありません。

#### 提案されている変更点

今回の提案は、ProposerVMが内側のVMに渡す`PChainHeight`を「**構築中のブロックのBlockHeight**」に切り替えるというものです。

* 変更前
    `PChainHeight` = 親ブロックのBlockHeight
* 変更後
    `PChainHeight` = 現在構築中ブロックのBlockHeight

これにより、内側のVMは最新の状態に基づいた正規のバリデータ集合を参照できるようになり、ICMの集約署名検証をより早くより信頼性高く実行できます。

## 互換性

この変更を導入するにはアップグレードが必要です。
理由は、すべてのバリデータがICMメッセージの有効性を検証する時に、同じP-ChainのBlockHeightを参照して同じバリデータ集合を用いる必要があるからです。
もし一部のノードだけが新しい方式（構築中ブロックのBlockHeightを利用）を採用し、他のノードが従来の方式（親ブロックのBlockHeightを利用）を続けた場合、検証対象のバリデータ集合に食い違いが生じ、整合性が崩れる可能性があります。
そのため、アップグレードが有効化されるまでは、ノードは引き続き「**親ブロックのBlockHeight**」を使い続ける必要があります。

## 参考実装

**ACP151**に対応するAvalancheGoでの実装は、以下のPull Requestにまとめられています。
[https://github.com/ava-labs/avalanchego/pull/3459](https://github.com/ava-labs/avalanchego/pull/3459)

ここで具体的に、ProposerVMが`block_context`に設定する`PChainHeight`の扱いを修正し、内側のVMに「**構築中ブロックのBlockHeight**」を渡すように変更しています。
これにより、ICMメッセージの検証時に最新のバリデータ集合を取得できるようになります。

## セキュリティ

ProposerVMは、**親ブロックのBlockHeight**を使ってブロック提案者の正当性を検証する必要があります。
これはセキュリティ上の必須条件であり、変更してはいけません。
提案者の検証においては、親ブロック時点の情報を基準にすることで、不正な提案を排除して合意の安全性を守ることができます。

一方で、**ICMメッセージの有効性の検証**に関しては、こうした制約は存在しません。
むしろ「**構築中のブロックのBlockHeight**」を基準にした方が、より正確で即時的に正しいバリデータ集合を反映できます。
そのため、この変更はセキュリティを損なうことなく、検証の効率性と正確性を高められる安全な変更と位置づけられています。













## 最後に

今回は「ProposerVMが内側のVMに渡すP-ChainのBlockHeightを「**親ブロックのBlockHeight**」ではなく「**現在構築中のブロックのBlockHeight**」に切り替え、ICM集約署名の検証で最新のバリデータ集合を使って待機時間を減らす仕組みを提案している**ACP151**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下の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