[ACP25] リクエスト失敗を即時通知するAppErrorの仕組みを理解しよう！

はじめに

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

今回は、VM間通信でリクエストが失敗したときに、タイムアウトを待たずにAppErrorという専用メッセージで明示的にエラーを通知できる仕組みを提案しているACP25についてまとめていきます！

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

https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/25-vm-application-errors/README.md

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

Notion | Where teams and agents work togetherMade in Notion, the connected workspace where AI agents and teams organize docs, projects and knowledge together.Notion

概要

ACP25は、VirtualMachine（VM）がアプリケーション固有のエラー状態を別のVMへ通知できる仕組みを追加するものです。現状では、あるVMがAppRequest（アプリケーション固有のリクエストメッセージ）を送信しても、相手が処理できなかった場合に「失敗した」ということを直接知らせる手段がありません。そのため、リクエストを送信したVMは一定時間待ってから「応答がなかった＝失敗」とみなすしかありません。

この仕組みを改善するために、新たに「AppError」というエラーメッセージを導入し、失敗が発生した時に相手VMから明示的にエラーを返せるようにしようというのがACP25の目的です。

動機

AvalancheのVM同士は、AppRequest、AppResponse、AppGossipといったメッセージタイプを使って独自のP2Pアプリケーションプロトコルを構築できます。このうちAppRequestは、必ずAppResponseによって成功結果が返されることを前提としています。ところが、処理が失敗するケース（リソース不足や要求が不正など）が起きたとき、現状では「応答なし＝失敗」と解釈するしかなく、タイムアウトが唯一の手段となっています。

この状態にはいくつかの問題があります。

無駄な待ち時間が発生する エラーを明示的に返せないため、クライアントはタイムアウトが切れるまで待たなければならず、失敗を検知するまでに余計な遅延が生じます。
ピア評価ができない ネットワークレイヤーはVM内部の実装を知らないため、あるノードが「正しくエラーを返した」のか「応答がない」のかを区別できません。その結果、ピアの信頼性を適切にスコアリングすることができません。
失敗処理の統一性が欠けている すべてのクライアントがタイムアウト頼りになるため、どのVMも「応答がない場合にどう扱うか」を独自に決める必要があります。これにより、システム全体としての一貫性や効率が下がってしまいます。

そこで新たにAppErrorというネイティブなアプリケーションエラー型を導入すれば、失敗が起きた時にVMは即座に相手へエラーを返せるようになります。これにより以下の改善が期待できます。

タイムアウトに頼らずに素早く失敗を検知でき、リクエスト処理の待ち時間を大幅に短縮できる。
Avalancheノードがエラーレスポンスを認識できるため、相手ノードを適切に評価（スコアリング）できる。
成功時と失敗時の双方において「必ず応答がある」という前提を作れるため、アプリケーション間のやり取りがより明確で予測可能になる。

仕様

AppErrorメッセージ

ACP25では、以下のようなprotobuf定義が追加されています。

protobuf

message AppError {
  bytes chain_id = 1;
  uint32 request_id = 2;
  uint32 error_code = 3;
  string error_message = 4;
}

このメッセージは、AppRequestへの応答として返されるエラーレスポンスを表します。それぞれのフィールドの意味は以下です。

フィールド名	型	説明
`chain_id`	bytes	元の`AppRequest`で指定されたチェーンIDを必ず使用します。どのチェーンに関するリクエストなのかを明確に紐付けるためです。
`request_id`	uint32	元の`AppRequest`のリクエストIDを必ず使用します。これにより、どのリクエストに対するエラーなのかを識別できます。
`error_code`	uint32	アプリケーションが定義するエラーコードです。同じ条件では同じエラーコードを使うことが推奨され、クライアント側でエラーを機械的に判別できるようにします。負の値はプロトコルが定義するエラー用に予約されており、0以上はVMが自由に使えます。
`error_message`	string	人間が読める形式のエラーメッセージです。ただし、この内容はエラー判定に使うべきではなく、判定には必ず`error_code`を用います。

この設計により、リクエストとエラーレスポンスの対応関係を明確に維持しながら、標準化されたエラー通知が可能になります。

予約済みエラーコード

Avalancheプロトコルでは、いくつかのエラーコードがすでに予約されています。これにより、基本的なエラーケースについては全クライアントが共通理解を持てるようになります。

エラーコード	説明
0	未定義（undefined）
-1	ネットワークタイムアウト

この表からわかるように、負の値（ここでは-1）がプロトコル定義エラーに割り当てられています。一方で、0は特別に「未定義」として扱われます。それ以外の正の値はVMごとに自由に定義できます。

エラーハンドリングのルール

この仕様では、AppRequestに対して必ず以下のどちらかの応答を返す必要があります。

正常に処理できた場合はAppResponseを返す。
エラーが発生した場合はAppErrorを返す。

いずれの場合も、応答は元のAppRequestに指定されていたdeadline（期限）までに返す必要があります。これにより、リクエストを受けた側が無視することなく、必ず成功または失敗の結果を返すことが保証されます。

この仕組みは、従来のようにタイムアウト任せで失敗を検出する方法と比べて、はるかに効率的です。エラーが発生したら即座にAppErrorで通知できるため、クライアントは無駄に待つことなく処理を続けることができます。

互換性

新しく導入されるAppErrorメッセージは、既存のネットワーク動作に直接影響を与えるため、ネットワーク全体での有効化（アップグレード）が必要になります。従来の仕様では、AppRequestに対してAppResponseが返されない場合、送信者はタイムアウトを待つしかありませんでした。今回の変更によって、AppRequestには必ず次のいずれかの応答が求められるようになります。

成功時: AppResponse
失敗時: AppError

この変更が有効化されるまでは、従来通りタイムアウトで失敗を検出しますが、有効化後は応答が必須になるため、リクエスト処理がより明確で効率的になります。

参考実装

ACP25の実装は、すでにAvalancheGoのリポジトリでプルリクエストとして公開されています。これにより、開発者は具体的にどのように定義や処理が行われているかを確認できます。

メッセージ定義: ava-labs/avalanchego/pull/2111 このプルリクエストでは、AppErrorメッセージのprotobuf定義が導入されています。
メッセージ処理: ava-labs/avalanchego/pull/2248 このプルリクエストでは、受信したAppErrorをどのように扱うか、またAppRequestに応答する際のロジックが実装されています。

これらのリファレンスを通じて、開発者は実際のコードを確認し、提案内容がどのようにソフトウェアに組み込まれているのかを理解することができます。