[ERC-7683] クロスチェーンインテントを読み解いてみる
こんにちは!
ブロックチェーンエンジニアの Dr. Doru です!
今回は、「ERC-7683:クロスチェーン取引の標準化を可能にする規格」についての解説をさせていただけたらと思います。
ERC-7683 はまだ有名な規格ではないため、私自身が調べていく中で理解に苦しんだ部分を中心にまとめていこうと思います。
ERC-7683 とは
ERC-7683 は、クロスチェーン取引におけるインターオペラビリティを向上させ、異なるブロックチェーン間での資産交換を効率的かつ安全に行えるようにすることを目的とした規格のことです。これにより、フィラーや他の参加者が異なるシステム間で統一された方法で取引を実行できるようになります。
クロスチェーンブリッジとは
ERC-7683を解説する前にまずクロスチェーンブリッジとは、異なるブロックチェーンネットワーク間で資産やデータを移動させるための仕組みのことを指します。
クロスチェーンブリッジの問題点
これまでクロスチェーンブリッジには以下のような問題があるとされてきました。
問題点
- 複雑な操作: ブリッジの利用、資産のロック、チェーン間のメッセージ伝達など
- 時間制約: 全体として完了するまでに時間がかかる
- セキュリティ: ハッカーによるブリッジ攻撃など
クロスチェーンインテントシステムとは
このようなクロスチェーンブリッジの問題点をある程度解決できる仕組みが、クロスチェーンインテントシステムになります。クロスチェーンインテントシステムとは、クロスチェーン取引を特定のアクションや取引意図を規格として定め、取引を自動化し、効率化するシステムのことになります。こちらを使用する利点としては以下のようなものが挙げられます。
利点
- ユーザーが簡単な操作で取引を行うことができる
- 取引の自動化により取引スピードが向上する
- 資産のロックや確実な署名検証によるセキュリティの向上
- フィラーがよりアクティブに取引を行うことで流動性の向上につながる
filler(フィラー)とは
私自身フィラーという言葉に馴染みがなかったのでフィラーについての説明をさせていただきます。
まずフィラーの役割として大きく2つのものがあります。
役割
- 取引の実行
- 流動性の提供
フィラーはユーザーが発行したオーダー(トークンのスワップなど)を実行します。またフィラーは売り手と買い手の資産売買を市場で買い注文、売り注文を提示することで取引を迅速に成立させ、資産の流動を高めています。
フィラーを挟んだクロスチェーンブリッジの流れ
「ユーザーAがユーザーBに対してチェーンAからチェーンBにあるトークンを移動したい」というケースについて考えてみましょう。この取引は以下のような図になるかと思います。
フィラーを挟んだクロスチェーンブリッジ図
クロスチェーンブリッジのステップ
- ユーザーAがチェーンA上で「トークンをチェーンAからチェーンBに移動する」というオーダーを作成し、署名を行う
- ユーザーAがオーダーをフィラーに送信する
- フィラーが受けとったオーダーの署名検証を行う
- フィラーがチェーンA上のコントラクトAにオーダーを送信する
- コントラクトAがトークンをロックする
- フィラーがコントラクトAの情報を用いてチェーンB上のコントラクトBにオーダーを送信する
- コントラクトBはトークンをチェーンB上でユーザーBに送信する
この仕組みでは、二重支払いのリスクを防ぐため、チェーンA上のコントラクトAでトークンがロックが確認されない限り、チェーンB上での支払いができないような仕組みとなっています。
ERC-7683の構造について
これらの知識を踏まえ、ここからは実際の「ERC-7683」規格についてみていきます。
CrossChainOrder構造
先ほどの例であったフィラーが作成するオーダーの構造がこちらの「CrossChainOrder」になります。
そしてこちらの構造体がセトルメントコントラクトに送られ、処理されるという流れになっています。
struct CrossChainOrder {
address settlementContract; // 取引を完了するためのセトルメントコントラクトのアドレス
address swapper; // 取引を開始するユーザーのアドレス
uint256 nonce; // リプレイ保護のためのナンス
uint32 originChainId; // オリジナルチェーンのチェーンID
uint32 initiateDeadline; // オーダーが開始されるべき期限のタイムスタンプ
uint32 fillDeadline; // オーダーがデスティネーションチェーンで完了されるべき期限のタイムスタンプ
bytes orderData; // トークン、金額、デスティネーションチェーン、手数料、セトルメントパラメータなど、実装固有のデータを含むバイト列
}
ResolvedCrossChainOrder構造体
こちらの「ResolvedCrossChainOrder」は、「CrossChainOrder」のorderDataのバイト列をデコードし、具体的なトークンや金額などの情報を展開した構造になります。
struct ResolvedCrossChainOrder {
address settlementContract; // 取引を完了するためのセトルメントコントラクトのアドレス
address swapper; // 取引を開始するユーザーのアドレス
uint256 nonce; // リプレイ保護のためのナンス
uint32 originChainId; // オリジナルチェーンのチェーンID
uint32 initiateDeadline; // オーダーが開始されるべき期限のタイムスタンプ
uint32 fillDeadline; // オーダーがデスティネーションチェーンで完了されるべき期限のタイムスタンプ
Input[] swapperInputs; // ユーザーからの入力トークン
Output[] swapperOutputs; // ユーザーへの出力トークン
Output[] fillerOutputs; // フィラーへの出力トークン
}
struct Input {
address token; // 入力トークンのアドレス(ERC20)
uint256 amount; // 入力トークンの量
}
struct Output {
address token; // 出力トークンのアドレス(ERC20)
uint256 amount; // 出力トークンの量
address recipient; // 出力トークンを受け取るアドレス
uint32 chainId; // 出力トークンが送信されるチェーンID
}
ISettlementContractインターフェース
ISettlementContract は、セトルメントコントラクト上で実装されるインターフェースになります。
initialize 関数はフィラーによって呼び出され、クロスチェーン取引を開始するために使用され、 resolve 関数は、具体的なオーダーデータを解析し ResolvedCrossChainOrder 構造体に変換します。
interface ISettlementContract {
// クロスチェーン取引を開始する初期処理
function initiate(CrossChainOrder order, bytes signature, bytes fillerData) external;
// CrossChainOrderを解析し、ResolvedCrossChainOrderを返す関数
function resolve(CrossChainOrder order, bytes fillerData) external view returns (ResolvedCrossChainOrder);
}
ERC-7683を用いる利点
これまでフィラーは、異なるシステムごとに異なるコントラクトABIが存在していたため、それぞれのコントラクトごとに対応する関数を実装する必要がありました。ですが、この ERC-7683 を用いてそれぞれのコントラクトにインターフェースを実装することでフィラーが複雑なコードを書く必要がなく、より容易に取引に参入できるようになるということが可能になります。
この規格を調べていく中で流動性を高めるためにもフィラーの役割は大きいので、ERC-7683 のインタフェースを実装することは今後必要になっていくのかなという印象を受けました。
まとめ
クロスチェーン取引を扱うサービスでは、フィラーが円滑に取引を実行し流動性提供をすることで全体的なユーザーエクスペリエンスの向上に繋がるためエコシステムには欠かせない存在です。なのでこのERC-7683を理解し実装しておくということは価値が今後出てくるのではないだろうかと感じました。
理解が間違っている点などございましたらコメントいただけたらと思います。
ここまで読んでいただきありがとうございます!
この記事がERC-7683の理解に繋がってくれると幸いです。
本日はここまで!
またの機会に、アディオス!
Discussion