[ERC7985] クロスチェーンメッセージのキャンセル・タイムアウト・リトライを制御するGateway Attributesの仕組みを理解しよう！

はじめに

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

https://amzn.asia/d/gxvJ0Pw

今回は、クロスチェーンメッセージングにおけるキャンセル、タイムアウト、リトライ、依存関係、配信制御のための標準属性を定義しているERC7985についてまとめていきます！

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

概要

ERC7985とは、ERC7786クロスチェーンメッセージングゲートウェイにおいて、メッセージのライフサイクル、順序、配信要件を予測可能に制御するための標準属性を定義した規格のことです。

[ERC7786] クロスチェーン通信を標準化する仕組みを理解しよう！

主要な特徴

動機

ERC7786は拡張可能な属性システムを導入しましたが、属性の標準化は後続の仕様に委ねられていました。 クロスチェーンアプリケーションが成熟するにつれて、メッセージ制御のための一貫したパターンが必要不可欠な要件として浮上しています。

標準化が必要な理由

標準化された属性がない場合、各ゲートウェイはこれらの機能を異なる方法で実装することになります。 その結果、エコシステムが断片化し、アプリケーション固有の統合ロジックが必要になってしまいます。

仕様

この仕様は、ERC7786クロスチェーンメッセージングゲートウェイの標準属性を定義しています。 「配信」（または「deliver」）という言葉は、ERC7786での使用法と同様に、宛先チェーンにメッセージを配信するプロセスを指します。

ゲートウェイは属性を独立して実装することができます。 ゲートウェイは実装する各属性のエンコーディングを検証し、エンコーディングが無効な場合はトランザクションをリバートする必要があります。

属性一覧

cancellable(bool)

メッセージが送信後にキャンセル可能かどうかを示す属性です。

エンコーディング

属性値はABIエンコードされたブール値です。 未指定の場合、デフォルトはfalseです。

動作

trueに設定された場合、ゲートウェイは条件や要件の変更によりアプリケーションがペンディングメッセージをキャンセルできるキャンセルメカニズムを提供する必要があります。

deliverBefore(uint256)

メッセージを配信できなくなる時刻を指定する属性です。

エンコーディング

値はABIエンコードされたUnixタイムスタンプです。 未指定の場合、デフォルトは0です。

動作

ゲートウェイは、0が指定されていない限り、有効期限のタイムスタンプ以降にメッセージを配信してはなりません。 0は「有効期限なし」として解釈されます。

deliverAfter(uint256)

メッセージを配信できる最早時刻を指定する属性です。

エンコーディング

値はABIエンコードされたUnixタイムスタンプです。 未指定の場合、デフォルトは0です。

動作

ゲートウェイは、0が指定されていない限り、配信タイムスタンプ以前にメッセージを配信してはなりません。 0は「遅延なし」として解釈されます。 deliverBefore(uint256)と組み合わせることで、配信時間ウィンドウを作成できます。

gantt
    title 配信時間ウィンドウの例
    dateFormat X
    axisFormat %H:%M

    section メッセージ
    配信不可 :done, 0, 100
    配信可能ウィンドウ :active, 100, 200
    配信不可（期限切れ） :crit, 200, 300

上記の図は、deliverAfterとdeliverBeforeを組み合わせた配信時間ウィンドウを示しています。 deliverAfterで指定した時刻以降、deliverBeforeで指定した時刻以前の間のみメッセージを配信できます。

retryPolicy(bytes)

配信失敗時のリトライ動作を定義する属性です。

エンコーディング

リトライパラメータはabi.encodePacked(uint16(maxRetries), uint32(retryDelay), uint32(backoffMultiplier))形式でエンコードされます。

デフォルト値

未指定の場合、デフォルトは0x（空バイト）です。 これは無限リトライ、遅延なし、バックオフなし（maxRetries = 0、retryDelay = 0、backoffMultiplier = 0）と同等です。

リトライ間隔の計算例

backoffMultiplierが20000（2倍）、retryDelayが10秒の場合のリトライ間隔は以下のようになります。

revertBehavior(uint8)

配信失敗時の処理方法を指定する属性です。

エンコーディング

値はABIエンコードされたuint8で、以下の値を取ります。

デフォルト値

未指定の場合、デフォルトは0（Revert on Failure）です。

各動作の詳細

以下のフロー図は、各リバート動作の処理フローを示しています。

flowchart TD
    A[メッセージ配信] --> B{配信成功?}
    B -->|成功| C[処理完了]
    B -->|失敗| D{revertBehavior}

    D -->|0: Revert| E[トランザクションリバート]
    E --> F[元のエラー理由を伝播]

    D -->|1: Emit-and-Continue| G[MessageFailedイベント発行]
    G --> H[後続処理を継続]

    D -->|2: Silent| I[何もしない]
    I --> H

Revert on Failure（値0）は最も厳格なモードで、失敗時にトランザクション全体をリバートします。 Emit-and-Continue（値1）は失敗を記録しつつ処理を継続するため、バッチ処理に適しています。 Silent Failure（値2）は失敗を完全に無視するため、重要でないメッセージに使用できます。

dependsOn(bytes32[])

このメッセージより前に配信される必要があるメッセージの依存関係を指定する属性です。

エンコーディング

値はメッセージ識別子のABIエンコードされた配列です。

動作

ゲートウェイは、dependsOn配列で指定されたすべてのメッセージが正常に配信されるまで、メッセージを配信してはなりません。 未指定または空の場合、メッセージには依存関係がありません。 これにより正しい順序が保証され、順序通りでない配信の問題が防止されます。

使用例

以下の図は、メッセージ依存関係の例を示しています。

graph LR
    A[メッセージA] --> C[メッセージC]
    B[メッセージB] --> C
    C --> D[メッセージD]

この例では、メッセージCはメッセージAとBの両方に依存しており、AとBの両方が配信されるまでCは配信されません。 同様に、メッセージDはメッセージCに依存しているため、Cが配信されるまでDは配信されません。

minGasLimit(uint256)

メッセージ配信に必要な最小ガス制限を指定する属性です。

エンコーディング

値は必要な最小ガス単位を表すABIエンコードされたuint256です。

動作

ゲートウェイはメッセージ配信を試みる前に、少なくともこの量のガスが利用可能であることを確認する必要があります。 未指定の場合、ゲートウェイはデフォルトのガス割り当て戦略を使用することができます。

補足

設計の根拠

これらの属性は、最も一般的なクロスチェーンメッセージ制御要件に対応しています。

リトライポリシーのバイトエンコーディング

リトライポリシーはバイトエンコードされた形式を採用しています。 これにより、追加の属性を必要とせずに拡張可能なパラメータを実現しています。 abi.encodePackedを使用することで、データサイズを最小限に抑えながら必要なすべてのパラメータを含めることができます。

依存関係メカニズムの設計

依存関係メカニズムにより、複雑なマルチメッセージワークフローが可能になります。 同時に、単一メッセージのシナリオでは簡潔さが維持されます。 空の配列や未指定の場合は依存関係なしとして扱われるため、シンプルなユースケースでは追加の設定が不要です。

後方互換性

この仕様はERC7786を既存の仕様に影響を与えることなく拡張しています。 これらの属性をサポートしていないゲートウェイは、基本仕様の「未知の属性を適切に処理する」という要件に従って通常通り動作します。

セキュリティ

引用

https://ethereum-magicians.org/t/new-erc-attributes-for-message-control-in-erc-7786-gateways/24734

最後に

今回は「ERC7985によるクロスチェーンメッセージングのメッセージ制御属性」についてまとめてきました！ いかがだったでしょうか？

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

Twitter @cardene777

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

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58