0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@cardene(かるでね)

[ERC7683] クロスチェーンインテントの標準化仕組みを理解しよう！

0
Posted at

はじめに

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

今回は、複数のブロックチェーン間で資産送付を行う時、異なるクロスチェーンシステム同士が共通仕様で相互運用できるようにするための標準APIとデータ構造を定義する提案しているERC7683についてまとめていきます！

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

他にも様々なEIPについてまとめています。

概要

ERC7683は、クロスチェーン（複数のブロックチェーン間）でのトークン送付を行うシステム向けに、標準化されたAPIを提供する仕組みです。
具体的には、共通して利用できる注文データ構造（Order Structs）や、決済用スマートコントラクトの標準インターフェースを定義します。
これにより、異なるクロスチェーンシステム同士でも共通の形式でやり取りが可能となり、開発者やサービス提供者が同じ仕組みを使えるようになります。

動機

現在のクロスチェーンのやり取りでは、「Intentベース」と呼ばれる仕組みが主流になりつつあります。
Intentベースとは、ユーザーが「最終的に達成したい結果（意図）」だけを提示し、その実現方法はシステム側に任せる手法です。
これにより、従来のブリッジのように複雑な手順や時間制約をユーザーが直接管理する必要がなくなります。

しかし、Intentベースのクロスチェーンシステムには課題があります。
最も大きいのは、十分な流動性（Liquidity）や、複数チェーン間で注文を埋める「Filler」と呼ばれる実行者ネットワークを確保することです。
特にチェーンの数が増えるほど、各チェーンごとにアクティブなFillerや資金が不足しやすくなります。
その結果、ユーザーは高い手数料、長い待機時間、そして不要な失敗率の高さといった不便を強いられます。

この問題を解決するために標準化が有効です。
標準化されたAPIやデータ形式を導入することで、異なるクロスチェーンIntentシステム同士が相互運用でき、注文の配信サービスやFillerネットワークを共有できます。
これにより、Filler間の競争が活性化し、コスト削減、処理速度の向上、成功率の向上といったユーザー体験の改善が期待されます。

仕様

この標準は、複数のブロックチェーン間でのトークン送付（クロスチェーンTransfer）を効率的かつ安全に行うための共通APIとデータ構造を定義しています。
これにより、異なるクロスチェーンシステム同士が相互運用でき、流動性やオーダー埋め（Fill）ネットワークを共有することが可能になります。

用語

  • Destination Chain
    ユーザーの意図（Intent）が実行され、資金を受け取るチェーン。
    1つのIntentで複数のDestination Chainが関わることもある。
  • Filler
    Destination ChainでユーザーのIntentを実行し、その報酬として支払いを受ける参加者。
  • Leg
    Intentの一部分で、他の部分とは独立して実行できるもの。
    Intentの全Legが実行されて初めて、そのIntentは完了とみなされる。
  • Origin Chain
    ユーザーが資金を送るチェーン。
  • Settlement System
    ユーザーの入金を管理してFillを検証し、Fillerへ支払いを行う仕組み。
  • Settler
    特定のチェーン上でSettlement Systemの一部を実装するコントラクト。
  • User
    オーダーを送信するエンドユーザー。

構造体（Struct）

GaslessCrossChainOrder 

struct GaslessCrossChainOrder {
	address originSettler;
	address user;
	uint256 nonce;
	uint256 originChainId;
	uint32 openDeadline;
	uint32 fillDeadline;
	bytes32 orderDataType;
	bytes orderData;
}

ガスレスで行うクロスチェーンオーダーの標準構造体。
ユーザーが署名し、FillerがOrigin ChainのSettlerコントラクトに送信するために使用される。

パラメータ

  • originSettler
    オーダーを処理するOrigin Chain上のコントラクトアドレス。
  • user
    オーダーを開始するユーザーのアドレス。
  • nonce
    リプレイ攻撃防止のためのユニークな番号。
  • originChainId
    Origin ChainのチェーンID。
  • openDeadline
    オーダーが開かれる期限（タイムスタンプ）。
  • fillDeadline
    Destination ChainでFillされる期限（タイムスタンプ）。
  • orderDataType
    EIP712の型ハッシュ。
  • orderData
    実装依存の任意データ（トークン、金額、Destination Chain、手数料、決済条件など）。

EIP712については以下の記事を参考にしてください。

OnchainCrossChainOrder 

struct OnchainCrossChainOrder {
	uint32 fillDeadline;
	bytes32 orderDataType;
	bytes orderData;
}

ユーザーが直接Origin Chainにオーダーを送信する形式の標準構造体。
ユーザー自身がオーダー作成トランザクションを実行する形式で、ガスレスではないです。orderData内に必要な取引情報を格納します。

パラメータ

  • fillDeadline
    Destination ChainでFillされる期限。
  • orderDataType
    EIP712の型ハッシュ。
  • orderData
    実装依存の任意データ。

ResolvedCrossChainOrder 

struct ResolvedCrossChainOrder {
	address user;
	uint256 originChainId;
	uint32 openDeadline;
	uint32 fillDeadline;
	bytes32 orderId;
	Output[] maxSpent;
	Output[] minReceived;
	FillInstruction[] fillInstructions;
}

Fillerが処理可能な形式に変換されたオーダー構造体。
orderDataを展開し、オーダーの入出力情報を明示します。
Fillerはこの情報を使い、Destination ChainでのFill手続きを行います。

パラメータ

  • user
    オーダーを開始したユーザーのアドレス。
  • originChainId
    Origin ChainのチェーンID。
  • openDeadline
    オーダーの開設期限。
  • fillDeadline
    Fillの実行期限。
  • orderId
    Settlement System内でのユニークなオーダー識別子。
  • maxSpent
    Fillerが送付する資産（トークン）の最大量。
  • minReceived
    Fillerが受け取る資産（トークン）の最小量。
  • fillInstructions
    Fillの各Legを実行するための指示。

Output 

struct Output {
	bytes32 token;
	uint256 amount;
	bytes32 recipient;
	uint256 chainId;
}

有効なオーダー成立に必要なトークン受領条件を定義。
出力資産の種類、数量、受取人、受取先チェーンを明示します。

パラメータ

  • token
    Destination Chain上のERC20トークンアドレス（ネイティブトークンはaddress(0)）。
  • amount
    トークン数量。
  • recipient
    受取アドレス。
  • chainId
    出力先チェーンID。

FillInstruction 

struct FillInstruction {
	uint256 destinationChainId;
	bytes32 destinationSettler;
	bytes originData;
}

Fillの各Legを実行するための指示構造体。

パラメータ

  • destinationChainId
    Fillを実行するチェーンID。
  • destinationSettler
    Fillを処理するDestination Settlerコントラクトのアドレス。
  • originData
    Origin Chainで生成されたFill実行に必要なデータ。

イベント

Open 

event Open(bytes32 indexed orderId, ResolvedCrossChainOrder resolvedOrder);

オーダーが開かれたことを通知するイベント。

パラメータ

  • orderId
    Settlement System内でのユニークなオーダー識別子。
  • resolvedOrder
    展開済みのオーダー情報。

インターフェース

openFor 

function openFor(GaslessCrossChainOrder calldata order, bytes calldata signature, bytes calldata originFillerData) external;

Fillerがユーザーの代わりにガスレスオーダーを開く関数。
ユーザー署名済みのGaslessCrossChainOrderをOrigin Settlerコントラクトに送信して、イベントOpenが発行されます。

引数

  • order
    ガスレスオーダー情報。
  • signature
    ユーザーの署名。
  • originFillerData
    Fillerが定義する任意のデータ。

open 

function open(OnchainCrossChainOrder calldata order) external;

ユーザーが直接オーダーを開く関数。
ユーザーが送信するトランザクションでオーダーを作成し、Openイベントを発行します。

引数

  • order
    オンチェーンオーダー情報。

resolveFor 

function resolveFor(GaslessCrossChainOrder calldata order, bytes calldata originFillerData) external view returns (ResolvedCrossChainOrder memory);

ガスレスオーダーをResolvedCrossChainOrder形式に変換する関数。
Fillerがオーダーの入出力情報を取得しやすくするための標準化手段です。

引数

  • order
    ガスレスオーダー情報。
  • originFillerData
    Fillerが定義する任意のデータ。

戻り値

  • ResolvedCrossChainOrder
    展開されたオーダー情報。

resolve 

function resolve(OnchainCrossChainOrder calldata order) external view returns (ResolvedCrossChainOrder memory);

オンチェーンオーダーをResolvedCrossChainOrderに変換する関数。
ガスレスオーダーと同様に、標準化された展開形式を取得します。

引数

  • order
    オンチェーンオーダー情報。

戻り値

  • ResolvedCrossChainOrder
    展開されたオーダー情報。

fill 

function fill(bytes32 orderId, bytes calldata originData, bytes calldata fillerData) external;

Destination Chainでオーダーの1つのLegを実行する関数。
Origin Chainから渡されたデータとFiller指定データを使用してFill処理を行う。

引数

  • orderId
    オーダーのユニーク識別子。
  • originData
    Origin Chainで生成されたFill用データ。
  • fillerData
    Fillerが定義する任意のデータ。

補足

Generic OrderData と2つのフロー

ERC7683は、多様なクロスチェーンIntent設計に対応できるように設計されています。
そのため、オーダー構造は柔軟に拡張可能なorderDataフィールドを中心に組み立てられています。

Intentの流れには、以下の2つのバリエーションがあります。

ガスレス（Gasless）フロー

Origin Chainでは、ユーザーがオフチェーンでオーダーを署名し、それをFillerに渡します。
Fillerはオーダーの要件を解読（resolve）し、Origin Chain上でオーダーを開きます。
Destination Chainでは、Fillerがオーダーの各Legを実行し、その後クロスチェーンの決済が行われます。

オンチェーン（Onchain）フロー

Origin Chainでは、ユーザーが直接open関数を呼び出してオーダーを作成します。
Fillerは発行されたイベントからオーダーの要件を取得し、Destination Chainで各Legを実行します。
最後にクロスチェーン決済が行われます。

カスタマイズ可能な設計

この標準では、実装者が以下の要素を自由に設計できるようになっています。

  • 価格決定方法（例：ダッチオークション、オラクルベース価格）
  • 実行条件（Fulfillment constraints）
  • 決済手順
  • OriginとDestination間の実行順序（場合によってはFillが先に行われる）

orderDataフィールドは任意仕様を格納できるため、これらのカスタマイズを行っても基本的なオーダー情報は共通の形式で解析可能です。
また、この仕組みはresolve関数とResolvedCrossChainOrder型の設計動機にもなっています。これにより、Fillerは詳細を知らなくてもオーダーを評価できます。

FillInstruction の役割と設計

FillInstruction配列は、Fillerが正しいFillを行うための指示を含んでいます。
これには以下の条件を満たす情報が含まれます。

  • 正しいDestination Chainでの実行
  • 正しいDestination Settlerコントラクトでの実行
  • Origin Chainからの必要情報の一部を含む
  • 実行タイミングに依存する場合（例：オークションの開始時間）

FillInstruction内のoriginDataは完全に不透明（opaque）なデータです。
これは、実装者が独自の形式で必要な情報を埋め込めるようにするためで、Fillerはこの中身を解釈する必要がありません。
この設計により、事前シミュレーションや異なる実装間での再利用が容易になります。

クロスチェーン互換性（Cross-compatibility）

ERC7683は、EVMチェーンだけでなく、将来的に非EVMチェーンとも相互運用できるように設計されています。
非EVM環境まで含めると仕様が複雑化するため、EVM用の標準は最小限の共通仕様を定義し、他の環境では「兄弟標準（Sibling Standards）」を作成して対応します。
そのため、アドレス表現にはbytes32型を使用し、異なるアドレス形式に対応しています。

Permit2の活用

Permit2は必須ではありませんが、この標準と組み合わせると効率的に動作します。
Permit2のwitness機能を使うことで、ユーザーは1回の署名でトークンの承認とオーダーの承認を同時に行えます。
これにより、2回の署名（トークン承認とオーダー承認）が必要な従来方式よりも安全かつ効率的になります。

Permit2と統合する際の注意点としては、以下があります。

  • nonceはPermit2のnonceを使用する。
  • openDeadlineはPermit2のdeadlineとする。
  • orderDataを含む完全なオーダー構造体をPermit2のwitness型として使用する。

使用例（Message サブタイプ）

例として、ERC7683互換のクロスチェーンTransferオーダーに「Message」というサブタイプを追加し、Fillerに対してDestination Chain上で任意のコントラクト呼び出しを実行させる仕組みがあります。

Message構造体には、複数のCallsが含まれ、それぞれ以下を指定します。

  • 実行先コントラクトアドレス
  • 呼び出すcallData
  • 送付するETH（value）

Fillerはfill()実行時にこれらのCallを順に実行します。
これにより、受取人がDestination Chainで資産を受け取った直後に、その資産を使った任意の処理を自動実行できます。
ただし、この方式ではmsg.senderがDestinationSettlerになるため、対象コントラクトがmsg.senderベースの認証を行う場合は制約があります。
この制限を解消するには、ERC4337やEIP7702対応のスマートコントラクトウォレットと組み合わせるのが理想です。

ERC4337については以下の記事を参考にしてください。

セキュリティ

ERC7683では、7683オーダーの成立やFillerへの返金をどのように検証するかという仕組みについて、特定の方法を定めていません。
つまり、Settlement System（決済システム）の安全性評価は、この標準の範囲外とし、実際の実装や運用においてはFiller自身やユーザーのオーダーを作成するアプリケーションが判断・評価する必要があります。

この方針は、現時点で複数の有力なクロスチェーンメッセージングシステムが存在しており、それぞれが異なるセキュリティモデルやトレードオフを提供している状況を踏まえたものです。
標準側で1つの方式に固定してしまうと、利用者や開発者が望むセキュリティレベルや柔軟性を損なう可能性があります。

最終的には、この標準の上位仕様として、より安全で信頼不要（Trustless）なクロスチェーン検証システムを標準化する専用のERCが策定されることが望まれています。
それによって、Settlement Contractの安全性を統一的に担保し、Fillerやユーザーが安心して取引できる環境を整えることが可能になります。

引用

Mark Toda (@marktoda), Matt Rice (@mrice32), Nick Pai (@nicholaspai), "ERC-7683: Cross Chain Intents [DRAFT]," Ethereum Improvement Proposals, no. 7683, April 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7683.

最後に

今回は「複数のブロックチェーン間で資産送付を行う時、異なるクロスチェーンシステム同士が共通仕様で相互運用できるようにするための標準APIとデータ構造を定義する提案しているERC7683」についてまとめてきました！
いかがだったでしょうか？

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

Twitter @cardene777

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?