# [ERC7683] クロスチェーンインテントの標準化仕組みを理解しよう！ > ERC7683は、クロスチェーン（複数のブロックチェーン間）でのトークン送付を行うシステム向けに、標準化されたAPIを提供する仕組みです。 - URL: https://cardene.dev/articles/744da8d0f26265045953 - 公開日: 2025-08-18 - 更新日: 2025-08-18 - トピック: Blockchain - タグ: ethereum, solidity, smartcontract, ブロックチェーン ## はじめに 『DApps開発入門』という本や色々記事を書いているかるでねです。 https://amzn.asia/d/gxvJ0Pw 今回は、複数のブロックチェーン間で資産送付を行う時、異なるクロスチェーンシステム同士が共通仕様で相互運用できるようにするための標準APIとデータ構造を定義する提案している**ERC7683**についてまとめていきます！ :::message 以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。 ::: https://eips.ethereum.org/EIPS/eip-7683 他にも様々なEIPについてまとめています。 https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4 ## 概要 **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` ```javascript 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、手数料、決済条件など）。 :::message **EIP712**については以下の記事を参考にしてください。 ::: [\[EIP712\] 型付き構造化データのハッシュ化と署名の仕組みを理解しよう！](/articles/f54bc85cb66de5a54257) #### `OnchainCrossChainOrder` ```javascript struct OnchainCrossChainOrder { uint32 fillDeadline; bytes32 orderDataType; bytes orderData; } ``` ユーザーが直接Origin Chainにオーダーを送信する形式の標準構造体。 ユーザー自身がオーダー作成トランザクションを実行する形式で、ガスレスではないです。`orderData`内に必要な取引情報を格納します。 **パラメータ** * `fillDeadline` Destination ChainでFillされる期限。 * `orderDataType` **EIP712**の型ハッシュ。 * `orderData` 実装依存の任意データ。 #### `ResolvedCrossChainOrder` ```javascript 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` ```javascript struct Output { bytes32 token; uint256 amount; bytes32 recipient; uint256 chainId; } ``` 有効なオーダー成立に必要なトークン受領条件を定義。 出力資産の種類、数量、受取人、受取先チェーンを明示します。 **パラメータ** * `token` Destination Chain上のERC20トークンアドレス（ネイティブトークンは`address(0)`）。 * `amount` トークン数量。 * `recipient` 受取アドレス。 * `chainId` 出力先チェーンID。 #### `FillInstruction` ```javascript struct FillInstruction { uint256 destinationChainId; bytes32 destinationSettler; bytes originData; } ``` Fillの各Legを実行するための指示構造体。 **パラメータ** * `destinationChainId` Fillを実行するチェーンID。 * `destinationSettler` Fillを処理するDestination Settlerコントラクトのアドレス。 * `originData` Origin Chainで生成されたFill実行に必要なデータ。 ### イベント #### `Open` ```javascript event Open(bytes32 indexed orderId, ResolvedCrossChainOrder resolvedOrder); ``` オーダーが開かれたことを通知するイベント。 **パラメータ** * `orderId` Settlement System内でのユニークなオーダー識別子。 * `resolvedOrder` 展開済みのオーダー情報。 ### インターフェース #### `openFor` ```javascript function openFor(GaslessCrossChainOrder calldata order, bytes calldata signature, bytes calldata originFillerData) external; ``` Fillerがユーザーの代わりにガスレスオーダーを開く関数。 ユーザー署名済みの`GaslessCrossChainOrder`をOrigin Settlerコントラクトに送信して、イベント`Open`が発行されます。 **引数** * `order` ガスレスオーダー情報。 * `signature` ユーザーの署名。 * `originFillerData` Fillerが定義する任意のデータ。 #### `open` ```javascript function open(OnchainCrossChainOrder calldata order) external; ``` ユーザーが直接オーダーを開く関数。 ユーザーが送信するトランザクションでオーダーを作成し、`Open`イベントを発行します。 **引数** * `order` オンチェーンオーダー情報。 #### `resolveFor` ```javascript function resolveFor(GaslessCrossChainOrder calldata order, bytes calldata originFillerData) external view returns (ResolvedCrossChainOrder memory); ``` ガスレスオーダーを`ResolvedCrossChainOrder`形式に変換する関数。 Fillerがオーダーの入出力情報を取得しやすくするための標準化手段です。 **引数** * `order` ガスレスオーダー情報。 * `originFillerData` Fillerが定義する任意のデータ。 **戻り値** * `ResolvedCrossChainOrder` 展開されたオーダー情報。 #### `resolve` ```javascript function resolve(OnchainCrossChainOrder calldata order) external view returns (ResolvedCrossChainOrder memory); ``` オンチェーンオーダーを`ResolvedCrossChainOrder`に変換する関数。 ガスレスオーダーと同様に、標準化された展開形式を取得します。 **引数** * `order` オンチェーンオーダー情報。 **戻り値** * `ResolvedCrossChainOrder` 展開されたオーダー情報。 #### `fill` ```javascript 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**対応のスマートコントラクトウォレットと組み合わせるのが理想です。 :::message **ERC4337**については以下の記事を参考にしてください。 ::: [\[ERC4337\] プロトコルの変更をせずにAAを実装する仕組みを理解しよう！](/articles/8c97ca7c93c4557ebfc2) https://zenn.dev/heku/books/88e65212339061 ## セキュリティ **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](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