はじめに

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

https://amzn.asia/d/gxvJ0Pw

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

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

ERC-7683: Cross Chain IntentsProgrammable solvers for intent protocols.Ethereum Improvement Proposals

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

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

概要

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、手数料、決済条件など）。

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

[EIP712] 型付き構造化データのハッシュ化と署名の仕組みを理解しよう！

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対応のスマートコントラクトウォレットと組み合わせるのが理想です。

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

[ERC4337] プロトコルの変更をせずにAAを実装する仕組みを理解しよう！

ERC4337この本では『ERC4337』について、非エンジニア・エンジニア向けにわかりやすく解説しています。 前半では、Account Abstractionと『ERC4337』の仕組みの全体像と各用語について説明しています。 後半では『ERC4337』の技術的な仕組みについて噛み砕いて説明Zenn

セキュリティ

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://chaldene.net/

かるでねさんのプロフィールスマートコントラクトやAIを楽しんでいます。主にSolidityやSmart Contract、AIを使用した記事を書いてます。Zenn

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

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