こんにちは、よだかです。
今日は、Across Relayerを題材にエッジ探索を進めました。
開始時点では、Acrossの仕組みもRelayerの役割も十分に理解できていなかったため、まずはプロトコルの構造を確認するところから始めています。
そこから、注文処理のライフサイクル上にある状態変化に着目して仮説を立て、過去の取引データによる確認、経済性の検証、執行可能性の確認まで進めました。
最終的には、単純な裁定取引としては成立しない一方、一定の在庫条件を満たす場合には実行候補として残ることが分かりました。
現在は、本番注文を送信しない24時間のシャドー運用を回しています。
今回は、その流れを整理します。
Across Relayerとは何か
Acrossは、異なるブロックチェーン間で資産を移動するための仕組みの一つです。
通常のブリッジでは、元のチェーンから移動先のチェーンまで資産の移動処理が完了するのを待つ必要があります。
Acrossでは、その待ち時間を短縮するためにRelayerと呼ばれる参加者が存在します。
Relayerは、ユーザーからクロスチェーンの注文が出ると、移動先のチェーン上に自分が持っている資産を先にユーザーへ渡します。
その後、Across側の精算処理を通じて、Relayerは資金を回収します。
かなり単純化すると、
ユーザーがクロスチェーンの注文を出す
→ Relayerが移動先で資金を先出しする
→ 後からAcrossを通じて精算される
という構造です。
Relayerは、複数チェーン上に資金を配置しながら、注文ごとの手数料やガス代、資金配置などを見て、処理するかどうかを判断します。
つまり、単純な送金代行というよりは、クロスチェーン上で在庫を持ちながら注文を処理するマーケットメーカーに近い役割があります。
注文のライフサイクルから仮説を作る
今回注目したのは、価格そのものではありません。
Acrossの注文処理を確認していくと、注文が発生してから精算されるまでの間に、実行可能な主体や条件が変化する箇所があります。
そこで、
状態が切り替わった直後に、まだ処理されていない注文が残っている場合、そこに実行可能な余地が残るのではないか
という仮説を立てました。
具体的な条件や監視箇所については、現在も検証中のためここでは省略します。
重要なのは、最初から「この取引なら利益が出る」と考えたわけではないことです。
まず見たのは、
そもそも想定した状態変化が実市場で発生しているのか
という一点でした。
これは、以前の記事で整理した「候補を広げた後、安い検証で削る」という探索方法の延長です。
-
-
🛠️開発記録#577(2026/9/25)AIでエッジ探索を高速化する｜候補を広げて、安い検証で削る方法
続きを見る
まず「本当に起きているか」を確認する
最初の検証では、利益計算はほとんど行いませんでした。
Across上の注文と実際の処理結果を対応付け、
仮説として置いた状態変化の後に、別の実行者が注文を処理するケースが反復して存在するか
を確認しました。
結果として、単発の特殊事例ではなく、一定数の事例が実際の取引履歴から確認できました。
この段階で初めて、
仕様上はあり得る
から、
実市場でも発生している
へ一段進みました。
逆に、ここで該当例がほとんど見つからなければ、経済性や実装まで掘る必要はありませんでした。
今回の場合は、次の検証へ進めるだけの材料が残りました。
「見える」と「取れる」を分けて確認する
現象が実在することと、自分がアルゴリズムで利益を取れることは別問題です。
今回は、検証をおおむね次のように分けました。
反復して存在するか
↓
事前に観測できるか
↓
費用を引いても経済性が残るか
↓
競争上の時間が残っているか
↓
自分の実装でも執行できるか
この分解は、以前の清算エッジ探索でも使っていた考え方です。
「見える」「予測できる」「取れる」「儲かる」を一つの問いとして扱わず、それぞれ別々に確認します。
-
-
🛠️開発記録#572(2026/9/17)清算エッジ探索をどうフェーズシフトするか？
続きを見る
今回も、状態変化が見えたからといって、そのままエッジと判断することはしませんでした。
後知恵を使わずに経済性を確認する
次に確認したのは経済性です。
ここで注意したのは、実際に注文を取ったRelayerの取引結果を見て、
この取引なら利益が出ていた
と後から計算するだけでは不十分だという点です。
アルゴリズムとして必要なのは、
その瞬間までに得られた情報だけで、実行する判断を出せたか
です。
そのため、
- 状態変化前までに公開されていた注文情報
- その時点までのガス代情報
- その時点で取得可能だった価格
- 事前に算出できる精算条件
だけを使って再計算しました。
実際に後から勝ったRelayerの情報は、判定には使わず、確認用に限定しています。
その結果、過去データ上では、事前情報だけでも費用後に正となるケースが確認できました。
ただし、具体的な金額や条件についてはここでは公開しません。
競争に間に合うのか
経済性があっても、その機会が発生した瞬間に他のRelayerへ全て取られるのであれば、個人botterが狙う意味は薄くなります。
そこで次に、
状態が切り替わった後、どの程度の時間的余裕が残っていたか
を確認しました。
ここでも、大規模な競争分析を行ったわけではありません。
代表的なケースだけを使い、
- 最初に執行可能になった時点ですぐ処理されたか
- その後まで未処理状態が残ったか
- 実行者が極端に高い手数料を支払っていたか
といった点を確認しました。
結果として、全てが瞬間的な競争で処理されているわけではなく、一定の時間的余地を持つケースも確認できました。
もちろん、これだけで「競争が弱い」と一般化することはできません。
ただし、
全てが最初のブロックで消えるので個人では不可能
という形でこの仮説を落とす材料にもなりませんでした。
過去データ上の利益から、実際の執行確認へ
ここまで進んでも、まだ「他人が取れた」というだけです。
次は、
自分の実装でも同じ注文を処理できるのか
を確認しました。
過去のブロック状態を再現したローカル環境を作り、実際の勝者とは別のテスト用アドレスから注文処理を再現しました。
このとき、実際の勝者が使った取引データをそのままコピーするのではなく、元の注文情報から必要な呼び出しデータを自分で構築しています。
結果として、確認したケースでは全て正常に実行できました。
また、
- 特別な実行権限が必要ないこと
- 想定していたガス使用量から大きく外れないこと
- 注文処理後の状態変化が想定どおりであること
も確認できました。
ここで、
過去データ上では利益が見える
から、
自分の執行経路でも再現できる
まで進んだことになります。
精算まで追う
Relayerは自分の資金を先に出すため、注文処理時点で利益が見えていても、その資金を長時間回収できないのであれば資本効率が悪化します。
そこで、注文処理後の精算まで追跡しました。
確認した範囲では、
- 想定した資産
- 想定した金額
- 想定した精算先
で資金が戻ることを確認できました。
また、資金回収までには一定の時間がかかるものの、今回確認したケースでは、その資本拘束だけで利益が消えるほどではありませんでした。
ここまでは比較的素直でした。
問題が出たのは、その次です。
単純な裁定取引ではなかった
最初は、
費用後に利益が残る注文を拾えばよい
くらいに考えていました。
しかし実際の資金移動まで含めると、そう単純ではありませんでした。
Relayerが注文を処理すると、あるチェーンの在庫が減り、別のチェーン側で資金を回収することになります。
つまり、この取引は利益を得るだけではなく、
自分の保有資産をチェーン間で移動させる取引
でもあります。
この資産配置を直後に元へ戻そうとすると、今回確認したケースでは経済性が失われました。
したがって、この戦略は単純な一往復の裁定取引ではありません。
ここで戦略の定義を更新しました。
利益が正なら実行する
ではなく、
利益が正で、かつ取引後の資産配置を自分が許容できる場合にだけ実行する
という形です。
経済モデルをどこまで作るか
ここから先を厳密に考え始めると、
- 各チェーン上の保有資産
- 今後来る逆方向の注文
- 資産を戻すための費用
- 資本の機会費用
- 他の戦略との共用資金
など、考慮すべきものが急激に増えます。
最終的には、Relayer事業全体の資金管理モデルに近づいていきます。
しかし、今回の目的はAcross Relayer事業を完全に最適化することではありません。
必要なのは、
自分の資産配置が一定条件を満たしている場合に、この注文を処理する価値があるか
を判断できることです。
そこで、経済モデルを無制限に広げるのではなく、一定の在庫条件を執行条件として追加するところで一旦切りました。
ここでは「実装しない」ではなく、シャドーへ進む
以前、GHOを使った裁定候補を調査した際には、
見える
取れそう
実際に他のbotも取っている
ところまで進んだものの、最終的な利益と頻度を考えて実装しませんでした。
-
-
🛠️開発記録#575(2026/9/20)見えた、取れそう、それでも取らない｜GHO裁定を実装しなかった理由
続きを見る
今回はそこが少し違います。
過去データによる確認では、
- 状態変化の反復
- 事前観測
- 費用後の経済性
- 時間的な執行余地
- 自分の実装による再現
- 精算
- 資本拘束
まで確認できました。
最後に残ったのは、自分の資産配置に依存する条件です。
そのため今回は、ここで落とすのではなく、実際の市場を監視するシャドー運用へ進めることにしました。
24時間のシャドー運用へ
現在は、本番の取引を一切送信しない状態で、24時間のシャドー運用を回しています。
やっていることは、本番botの判断部分だけを実市場上で動かすことです。
概念的には、
実際の注文を監視する
↓
条件に合う候補を抽出する
↓
その時点の状態で仮想的に執行する
↓
必要資産、ガス代、想定利益を計算する
↓
仮想的にGO / NO-GOを記録する
↓
実際には誰がいつ処理したかを後から比較する
という流れです。
実際の資金は使いません。
本番環境への送信経路も無効にしています。
今回の24時間で確認したいのは、過去に見つかった事例をさらに増やすことではありません。
過去データ上で確認した状態が、現在の市場でもどの程度の頻度で発生するのか
です。
過去には成立していても、現在の競争環境や注文構成ではほとんど発生しない可能性もあります。
逆に、現在も一定頻度で同じ条件が出るのであれば、小規模な実執行へ進む材料になります。
過去データを増やすより、次の問いへ進む
今回の探索では、途中から「さらに事例を増やすこと」の情報価値がかなり下がりました。
ある段階までは、
本当に存在するのか
を確認するために過去データが必要です。
しかし、
- 反復している
- 事前に観測できる
- 費用後にも残る
- 自分の実装でも再現できる
ところまで来ると、さらに過去事例を増やしても次の判断はあまり変わりません。
そこで、
過去にあったか
から、
今もあるか
へ問いを切り替えました。
今回の24時間シャドーは、そのための検証です。
まとめ
今日は、Across Relayerという仕組みを理解するところから始めて、エッジ候補の仮説立案、過去データの確認、経済性、競争、執行再現、精算まで一通り進めました。
最初は比較的単純な裁定候補に見えていましたが、検証を進める中で、
利益だけではなく、自分の資産配置まで条件に含める必要がある
ことが分かりました。
この点を含めても過去データ上では実行候補として残ったため、現在は24時間のシャドー運用を行っています。
今回も、エッジの存在を証明し切ることより、
次の判断を変えるために、いま何を確認する必要があるか
を一つずつ潰す形で進めました。
24時間の結果を見て、
- 小規模な実執行へ進む
- 在庫条件付きで保留する
- 現在の市場では優先度が低いとして落とす
のどこに進むかを判断します。
結果については、また別の記事で整理する予定です。
それでは、また。