こんにちは、よだかです。
ここしばらく開発していたAcross Relayer Botを、実際に資金を入れて動かす直前で捨てることにしました。
正確には、botそのものはかなりできています。
本番注文を一度だけ送るための状態管理、クラッシュ後の復旧、二重送信の防止、24時間の監視など、本番運用前の安全機構まで実装しました。
あとは、
ウォレットを接続する
↓
資金を入れる
↓
24時間のCanary運用を始める
というところまで来ていました。
それでも止めました。
理由は単純です。
取引機会はあった。技術的にもかなり取れそうだった。
しかし、必要な資本に対して利益が小さすぎた。
今回は、Across Relayerのエッジ探索からbot開発まで進めた結果、最後にどこでエッジが消えたのかを整理します。
以前の記事では、Across Relayerの仕組みを調べ、過去データから候補を見つけ、24時間のシャドー運用へ進むところまで書きました。
関連記事：🛠️開発記録#578「Across Relayerのエッジ探索｜仮説から24Hシャドーまで」
今回はその続きです。
取引機会そのものは本当に存在した
Acrossは、異なるブロックチェーン間で資産を移動するためのプロトコルです。
ユーザーが元のチェーンで注文を出すと、Relayer（リレイヤー、中継実行者）が移動先のチェーンで自分の資産を先に渡します。
その後、Acrossの精算処理を通じてRelayerへ資金が返されます。
Across公式の説明でも、
注文発生
→ Relayerによる処理（fill）
→ 後から精算・返済
という流れになっています。
Across公式：Intent Lifecycle in Across
Relayerは自分の資金を先に出すため、ガス代だけでなく、資金拘束や在庫管理も考えて注文を処理する必要があります。
Across公式：Actors in the System — Relayer
今回注目したのは、注文の一部に設定されている独占期間です。
一定時間までは指定されたRelayerだけが処理できても、その期限を過ぎると第三者も処理できるようになります。
そこで、
独占期間が終了した後も未処理の注文が残るなら、第三者が途中から入って処理できるのではないか
という仮説を立てました。
この仮説自体はかなり強く確認できました。
実際に第三者による処理は反復して存在しました。
状態変化も公開情報から確認できました。
過去block上では、第三者として注文を処理する取引も再現できました。
さらに、ガス代を差し引いてもプラスになる候補も見つかりました。
最終監査でも、
仕組みが存在する
→ 機会が発生する
→ 第三者から観測できる
→ 取引を構築できる
→ fork上で実行できる
→ ガス代差し引き後にプラスになる
ところまでは、かなり強く確認できたと判定しています。
つまり、最初の仮説が全部間違っていたわけではありません。
ここまでは本当にエッジがありました。
ガス代を引いてプラスでも取引エッジにならないこともある
問題はここからでした。
探索の途中では「gas-positive」という指標をかなり使っていました。
これは簡単に言えば、
注文処理で得られる総収益
− 注文処理時のガス代
＞ 0
という意味です。
24時間の観測でも、この条件を満たす候補は複数発生しました。
この時点では、
機会はある
実行もできそう
費用を引いてもプラスになる
ところまで来ています。
普通に考えると、かなりbot実装へ近づいたように見えます。
しかし、この「プラス」にはまだ含まれていないものがありました。
たとえば、
- 処理後の在庫を元の状態へ戻す費用
- チェーン間の資金配置
- スリッページ
- 資金拘束
- 他の取引機会に資金を使えない時間
- 実際の競争で負けた場合のコスト
などです。
監査してみると、初期のgas-positiveは本当に「総収益からfill時のガス代を引いたもの」で、それ以外の後段コストや必要資本は含んでいませんでした。
つまり、
ガス代を引いて利益がある
と、
一連の取引を最後まで閉じても利益がある
は別でした。
さらに、
最後まで利益がある
と、
その利益を取るために資金を置く価値がある
も別でした。
関連記事：🛠️開発記録#575「見えた、取れそう、それでも取らない｜GHO裁定を実装しなかった理由」
約3万8600ドルを使って残る利益は1.46ドルだった
そこで、24時間の観測で残った候補について、注文処理から資金回収、在庫回復までを一本の会計として再構成しました。
最もきれいに最後まで再構成できたプラスの事例は、次のような結果でした。
必要資本：約38,599ドル
総収益：約4.56ドル
全コスト：約3.09ドル
最終利益：約1.46ドル
資本に対する利益：約0.379bps
1bpsは0.01％です。
つまり、約3万8600ドルを使って、最終的に残ったのは約1.46ドルでした。
もう一つプラスになった候補もありました。
こちらは約5万ドルの必要資本に対して、最終利益は約0.43ドル、約0.085bpsでした。
一方、必要資本が最も少なかった候補でも約5,000ドル必要で、こちらは最終的にマイナスでした。
9候補をまとめると、
最終利益がプラス：2件
1ドル以上の利益：1件
1bps以上：0件
でした。
ここで、今回のエッジがどこで消えたのかがかなり明確になりました。
利益そのものは完全には消えていません。
消えたのは、
必要資本に対して、その利益を取りにいく価値
でした。
エッジは資本効率の段階で消えた
以前、
🛠️開発記録#580「エッジはどこで消えるのか｜DeFi探索の見方を少し変えた話」
という記事を書きました。
今回のAcross Relayerは、そのかなり具体的な実例になりました。
今回確認したものを順番に並べると、
仕組みがある
↓
機会が発生する
↓
外部から観測できる
↓
取引を組める
↓
実行できる
↓
ガス代差し引き後でプラスになる
↓
全コストを入れても一部はプラスになる
↓
必要資本で割ると弱すぎる
という流れです。
最終監査では、仕組み、観測可能性、fork上での実行可能性、ガス代差し引き後の利益までは確認済みとしました。
一方で、
必要資本に対する十分な収益
資本を効率よく回せる頻度
個人botterによる反復取得
本番運用へ進む合理性
は確認できませんでした。
Across公式も、Relayerは自分の資金を先に出し、精算まで資本が拘束されることをRelayerのコスト・リスクとして挙げています。
今回の9候補でも、fillから返済までの中央値は約4,333秒でした。
これを一通り回すのにかかった時間は、およそ72分です。
つまり、
数千〜数万ドルを出す
↓
約1時間資金が戻らない
↓
最終的に数十セント〜1ドル程度残る
という構造でした。
これなら、少なくとも現在の自分が専用資本を割り当てる理由はありません。
本当はもっと早く止められた
今回、一番反省すべきなのはここです。
最終結果が悪かったこと自体ではありません。
研究なので、最後まで調べてダメだと分かることは普通にあります。
問題は、
もっと早い段階で、かなり安く同じ方向の結論を出せた
ことです。
最初の警告は9月27日の時点ですでに出ていました。
少数の事例で資金回収まで調べたところ、
即座に在庫を元へ戻す経路は3件中0件がプラス
利益は在庫をそのまま持つことを前提にしている
必要な運転資金もかなり大きい
という状態でした。
この時点では研究全体を捨てるにはまだ早かったと思います。
別の在庫回復方法があるかもしれませんし、他の候補では経済性が違う可能性もありました。
ただし、
本番運用方向へ進む
のではなく、
必要資本に対する最終利回りを確認する
ところへ戻るべきでした。
さらに9月29日、24時間観測が完了した時点では、保存済みデータだけでかなり強い判定が可能でした。
9件の候補について、
必要資本
総収益
fill時のガス代
がすでに分かっていました。
ここで、在庫回復費用すら入れない楽観的な上限を計算すると、9件すべて1bps未満でした。
つまり、
まだ引いていないコストが残っているのに、すでに最低ラインへ届いていない
状態でした。
この集計は新しいbotを作らなくてもできます。
監査では、この時点で行えた検証を「非常に低コストで決定的」と評価しています。
最終的にこの確認を行ったのは約6日後でした。
本番運用向けの実装まで進めたのは一段早かった
その間に、bot側の開発をかなり進めました。
24時間動かすための監視基盤を作り、
候補を検出し、
その時点の状態を再確認し、
シミュレーションし、
最終的な送信直前チェックを行い、
一度だけ本番transactionを送信し、
その後は二重送信を防ぎながら監視を継続する、
というところまで実装しました。
クラッシュや再起動があっても、同じRunから2件目を送らないことも確認しました。
技術的には有用な実装です。
しかし、今回の監査では、
R1の本番Canary用state machineを作る前に、経済性を閉じるべきだった
と判定しました。
実装前の時点ですでに、
過去候補の最小必要資本：約5,000ドル
R1で予定していた最大資本：1,000ドル
bot側の初期上限：100 USDC
保存済み候補：9件すべて1bps未満
という情報が存在していました。
つまり、作ろうとしていたR1設定では、そもそも過去の候補が1件も通りません。
この確認にはlive実装は必要ありませんでした。
今回、資金を入れる前に止まれたこと自体は良かったです。
秘密鍵も設定していません。
資金移動もしていません。
本番transactionも1件も送っていません。
ただし、
技術的に作れる
ことと、
資本を入れて動かす価値がある
ことは、もっと明確に分離する必要がありました。
次からは楽観的な上限で先に落とす
今回の監査で、一番そのまま次へ使えそうなのが、
楽観的な上限で先に落とす
という考え方です。
最終損益を正確に出そうとすると、かなり多くのものを調べる必要があります。
在庫回復経路。
スリッページ。
資金回収までの時間。
ブリッジ費用。
競争。
実際の約定。
これらを全部精密に再構成するのは重い作業です。
でも、常にそこまでやる必要はありません。
たとえば、
総収益
− fillガス代
という非常に楽観的な上限の時点ですでに0.5bpsしかないなら、
その先にまだコストが残っている以上、
最終的に1bps以上残るか？
を精密に調べる情報価値はかなり低くなります。
今回のようなケースなら、
楽観的上限
↓
必要資本で割る
↓
最低ラインを超えない
↓
DROP
でよかったわけです。
監査では、今後の改善として、
全コスト・必要資本・資本拘束時間・最終利益率を、本番bot実装前の必須gateにする
ことに加えて、
楽観的上限ですでに最低利回りを下回るなら、後段を精密に作らず止める
ことを提案しています。
これは今後かなり使うと思います。
Across Relayerを永久に捨てたわけではない
今回の判断は、
Across Relayerには利益機会が存在しない
というものではありません。
むしろ反対です。
取引機会そのものはかなり明確に存在しました。
第三者が処理できることも確認できました。
一部には、すべてのコストを含めても名目的にプラスになる候補もありました。
ただし、
現在確認できる市場環境と、自分が専用資本を置く前提では、割に合わない
と判断しました。
将来的に状況が変わる可能性はあります。
たとえば、
- Relayerへの報酬そのものが大きくなる
- ガス代が大きく下がる
- より安い在庫回復経路が見つかる
- 複数チェーン間の在庫を内部で相殺できる
- Across以外の戦略と同じ資本を共有できる
といった条件です。
ただし、このあたりは現時点ではアイデアです。
特に複数チェーンの在庫を本格的に管理し始めると、単純な「期限切れ注文を拾うbot」ではなく、Relayer全体の資本配置を最適化する仕組みに近づいていきます。
Acrossの公式Relayerにも、チェーンごとの目標在庫や返済先を管理する仕組みがあります。
Across公式：Running a Relayer — Inventory Management
そこまで作れば今回の経済性が改善する可能性はあります。
しかし、それは今回作ろうとしていたbotとはかなり別物です。
今すぐそこへ進む根拠はありません。
市場側にもっと太い機会が出てきたとき。
あるいは、自分が複数のbotを動かすようになり、クロスチェーン在庫や資本を共通管理する必要が別の理由から生まれたとき。
そのときに、改めてAcross Relayerを一つの実行先として見直す方が自然だと考えています。
取れることと、取る価値があることは別でした
今回のAcross Relayer探索では、
仕組みはありました。
機会もありました。
見えました。
transactionも作れました。
実行もできました。
ガス代を引いても利益が残りました。
全コストを入れても、一部はわずかにプラスでした。
それでもbotを捨てました。
数万ドルを必要とし、約1時間資金を拘束して、残る利益が数十セントから1ドル程度だったためです。
今回の失敗は、
エッジを見つけられなかった
ことではありません。
むしろ、
本物の小さなエッジを見つけた後、それが自分にとって資本を置く価値のあるエッジかどうかを確認するのが遅かった
ことです。
最終監査では、この違いを、
gas-positive
≠ all-cost positive
≠ capital-efficient
≠ personally captureable
と整理しました。
今後は「エッジがある」という言葉も、もう少し細かく扱うことになりそうです。
どこまで確認されたエッジなのか。
ガス代までなのか。
全コストまでなのか。
必要資本まで含めているのか。
繰り返し取れるところまで確認したのか。
今回のAcross Relayer Botは、本番運用には進みません。
実装した安全機構や研究成果は残します。
市場構造が大きく変われば再評価します。
ただ、今ここへ資金を入れる理由はない。
今回はそこで終了です。
それでは、また。