Atomic Arb1年生の手記
本記事は仮想通貨botter Advent Calendar 2024 シリーズ2 18日目の記事です。
はじめに
はじめまして、樒(@shikimi_crypto)と申します。
本稿は、2024年の抱負としてAtomic Arbの世界に飛び込むことを掲げた筆者が1年間記録してきた日記を記事として編集したものになります。
今年のアドカレでも既にAtomic Arbをテーマにした記事が複数出ており、ネタ被り感は否めませんが開発のアプローチや思考の過程など、何かしら付加価値を提供できればと思います。
Atomic Arbの基本的な概念については、かんたさんやShunさんの記事によくまとまっております。
Disclaimer: 本記事は情報提供のみを目的としたものであり、投資や売買の勧誘・推奨を目的としたものではありません。
きっかけ
2023年はそれまで収益の柱となっていたエッジが消滅し、新たな食い扶持を求めて色々試すも上手くいかない停滞の1年でした。行き当たりばったりでとりあえず動くものを作ってきたこともあり、そもそもの技術力が足りていないことを実感させられました。
そこで、2024年は知識の土台を固め、一つの領域を深堀りする1年にしようと決意しました。
集中する対象を選ぶためにBotterの方々の記事を読み漁っている中で特に心を打たれたのがRosさん(@Ros_1224)のnoteでした。
記事に登場する要素技術については理解できない部分が多かったのですが、各々が誇りをかけ、持てる技術の全てを尽くして戦う、まさに決闘者と呼ぶべき姿に強烈な憧れを抱きました。
この記事を読んでから、自分の中でAtomic ArbはBotterの一つの到達点として位置づけられ、これこそ自分がこの1年を費やして挑むに値する世界だと思うようになりました。
この時点での自分の技術レベルと、Atomic Arbという世界で戦うのに必要な技術レベルに大きな隔たりがあることは明白でしたが、何も挑戦せずにただ憧れているよりは挑戦して歯が立たなかった方が納得して次に進めると考えました。
戦場の選定
Atomic Arbは1つの鞘を巡って人と人が技術で殴り合うPvPコンテンツです。
したがって、自分のような初心者が戦うには上級者達があまり来ない場所を選ばければなりません。
そこで、戦場を選ぶにあたっては以下の3点を考慮することにしました
参入障壁があること
端的に言うとEVM系は他のチェーンで動いているBotを水平展開しやすいので避けたいと思いました。一定の学習コストがかかる非EVM系をターゲットにすることにしましたエコシステムがある程度発達していること
Atomic Arbにおける収益の源泉はプール間の価格差なので、1つのDEXに大半の流動性が集中しているチェーンよりは複数のDEXに流動性が分散しているチェーンが良いという仮説を立てましたこれから盛り上がるネタがあること
競合が少なくても収益機会を提供してくれるお客様がいなければ意味がないので、TGEなど市場の注目が集まるイベントを控えていることを条件に加えました
これらを加味した結果、私は戦場としてStarknetを選びました。
1についてはEthereumのL2でありながらCairoという独自言語を採用しておりEVM勢にとってもSolana勢にとっても参入障壁になりそう、2については調査当時で6つほどのDEXに一定の流動性があり、3についてもSTRKトークンのコントラクトは既にデプロイされておりエアドロの発表が近いのではと噂されてましたので条件を満たしていると考えました。
元々情報を追いかけていたというのも大きいです。Starknetローンチ前からStarkEx採用Dappsを触ったり、ローンチ後も虚無NFTタスクをしたりと自分の中で期待値高めのチェーンでした。
活動原資として1ETHをStarknetに送り、開発に乗り出しました。
開発記録
基礎勉強
日記によると1月4日にStarknetについての学習を開始したようです。
Atomic Arbを実行するまでの発展段階として以下のようなイメージを持って学習に着手しました。
DEXのコントラクトから交換レートを取得できる(Read関数の実行)
DEXのコントラクトから普通のスワップができる(Write関数の実行)
複数DEXを跨いで閉路を探索し、裁定パスを発見できる
複数DEXを跨いでスワップできるようにコントラクトを実装し、裁定パスに従いAtomic Arbを実行できる
ひとまず1, 2を目指してStarknet.jsやCairoのドキュメントを熟読し、チュートリアルに従って手を動かしました。
CairoについてはRustライクな文法ではあるものの、中身は結構異なっており、またSolidityほどリッチな機能はなく大変そうだというのが第一印象でした。（Cairoのバージョンアップによりだんだん扱いやすくなってきています）
はじめてのAtomic Arb (intra-DEX)
一通りチュートリアルを終えてStarknet上のDEXを調べている時に、単一DEX内であれば公式ルーターの関数だけでAtomic Arbができることに気が付きました。複数DEXを跨ぐのは難易度が高く当分先になりそうだと判断し、ひとまずDEX内Arbを目指すことにしました。
ちょうどそのころ、StarkDeFiというDEXではポイントプログラムを実施しており、LPを組んだりスワップしたりすることでポイントを獲得できました。
いわゆるお削り的なスワップで鞘が出るのではないかと思ったこと、鞘取りをしながらポイントを稼げたら美味しいのではないかと思ったことからStarkDeFiをターゲットに鞘の検知およびスワップを実行するプログラムを書き上げました。閉路を組める組み合わせが少なかったので実装は割と簡単でした。
プログラムを実行し、ドキドキしながら待っているとトランザクション成功の通知が飛んできました。
0.1029ETHを投入して、0.1039ETHを得られています！
実際にはガス代があるため利益はこれより少ないですが、ともあれ初のAtomic Arbが成功しました。1月5日夜のことでした。
はじめてのコントラクト実装
この頃は無料のRPCプロバイダを使っていたためAPIリクエスト回数に制限がありました。
なんとかリクエスト回数を節約しつつ高頻度に裁定機会の有無を確認できないかと考えた結果、1回のコールで複数のパスをチェックするコントラクトを作成することを思いつきました。
引数として渡したパスのリストから1つずつパスを読み込んで公式Routerのget_amounts_outを実行するだけの簡単なコントラクトです。
この実装ではパスの数に対して線形に実行時間が延びてしまうのですが、この時点では気にしていませんでしたし、気にしなくても鞘が取れていました。
これが私にとって最初の実用Cairoコントラクトの実装となりました。1月8日のことでした。
はじめてのAtomic Arb (inter-DEX)
StarkDeFi内という限定的な範囲ではなかなか鞘が発生しないので、そろそろ複数DEXを跨いだ本格的なAtomic Arbに進むことにしました。
StarknetにはAVNUというAggregatorがあり、コードが公開されていたのでコントラクトのアーキテクチャはこれを大いに参考にしました。SolanaでいうところのJupiterですね。
AVNUをそのまま使うという手もありましたが手数料が取られるのと、細かいカスタマイズができないので自作することにしました。
既に仕事が始まっており、帰省していた妻と娘も戻ってきたため、開発に使える時間は基本的に寝かしつけが終わった21-22時以降に制限されました。睡眠時間と開発速度のトレードオフです。
1週間近くかかって1月14日に最初のバージョンが完成しました。集中流動性についての理解が足りておらず実装が難航したためこの時点ではV2型のDEXのみを対象としました。
同日中にトランザクションが走り、DEX間Atomic Arbに成功しました。
集中流動性の攻略
当時StarknetにはEkuboとMySwapCLという2つの集中流動性DEXがありました。特にEkuboはStarknet最大のDEXであり、これが裁定パスに入っていないのは明らかに機会損失になっていました。
Ekubo
創設者のMoody Salem氏はUniswapの元リードエンジニアであり、EkuboはSingleton, Flash Accounting, HookといったUniswapV4の特徴を備えています。要するにStarknet上にUniswapV4を作って先に公開したよ、というそんなことしてええんか？なすごいDEXです。
それ故にただでさえ集中流動性のことがわからないのに、UniswapV3のことを理解してもまだ足りないのが自分にとっては高いハードルでした。
Docsがそれなりに整備されているのが唯一の救い。
MySwapCL
V2型のMySwapが先にあり、集中流動性に対応したCLが後からローンチされました。開発チームの素性がよくわからず、Docsもまともに整備されていませんがそれなりにTVLがあり無視もできないといったところ。
攻略にあたっては手始めに「集中流動性とは何か、そしてそれがスマートコントラクト上でどのように実装されるのか」という基礎を理解するためにUniswapV3の公式Docsや解説記事を読み、その後上記2つのDEXがそれをCairoでどのように実装しているのか調査するという流れで進めました。
数学弱者であることが足を引っ張り、整数型しかないのに小数、平方根、累乗、対数が絡む計算ができることを理解するのにかなり苦労しました。
1月21日にEkuboの対応がなんとか完了しました。MySwapCLはほぼUniswapV3そのままのはずなのにどうしても計算が合わず、Docsもないことからなかなか手がかりが掴めない状態で、最終的に2月16日までかかりました。
パフォーマンスチューニング
Ekuboの対応が終わった段階で一通りの武器が揃い、余裕が出てきたので競合のTx分析を始めました。その結果、自分が拾っている鞘の多くは強いbotのおこぼれであることに気が付きました。通ってるTxも実はより大きい鞘を競合が取った際の食べカスを拾っているにすぎなかったのです。
突貫工事でひとまず動くものを作っただけでチェーンを支配できるわけがなく、ここからが本当の勝負なんだと気を引き締めました。
速度を改善するために色々と試しました
SDKのコントラクト呼び出しにオーバーヘッドがあることに気づきコードを改変
RPCプロバイダの見直し、有料プランの契約
競合分析からやっていることを推測してbotのアーキテクチャを見直し
これらの施策によりたまにではありますが競合に勝てるようになり、割と安定してお金を拾ってくるようになりました。
寄り道
最初に触ったStarkDeFiに話は戻ります。
ポイントを稼ぐとエアドロに繋がりそうな謎の箱がもらえたりランキングがあったりでコミュニティが割と盛り上がっていたため、なんとかお削りスワップや流動性供給をすることなくポイントを稼ぎたいと思いました。
ところが自作コントラクトを介してスワップしてもポイントはつかないため、Atomic Arbでスマートに稼ぎながらポイントもゲットとはいきません。
そこで、裁定パス上にStarkDeFiがある場合にはTxを分割してStarkDeFiだけは公式ルーターを直接叩くというAtomic Arbという観点では大変非効率な方法を採用してポイントを稼ぎました（というか分割しているのでもはやAtomicではない）。
途中の出力量が想定とずれると失敗するし、Atomicではないので利益が出なければRevertということもできませんでしたが、それに見合った報酬があると期待してランキングを駆け上がり、箱も全て集めることができました。
ちなみに、StarkDeFiは執筆時点でトークンを発行していません。
このプログラムが終了したあとIntermissionなる引き延ばしイベントを追加で始め、さらに市況が悪いからということでスケジュール未定になりました。
巷ではハイリキの影響でNo VCが持て囃されている節がありますが、あれは例外中の例外で資金力・運営力がないとこういうことになります。仮にいまからエアドロされたとしても小銭にしかならないでしょう。
TGE戦
ついに待ちわびた$STRKのエアドロが発表されました。
ArgentXのNFTを集める虚無タスクを全てこなし、Starknet IDも取りました。Ekuboでの流動性供給も少額ですがしておりましたしなによりStarkEx時代からDappsを利用してきたOGです。何枚もらえるんだろうなと期待が高まります。
Not Eligible
は？何かの間違いだろうとウォレットのアドレスを確認しましたがちゃんとメインのウォレットです。基準をよく読むとスナップショット時点でのETH残高が含まれていました。おそらく年末円転に向けて資金を移動していた時期にスナップショットを撮られてしまったのでしょう。いやいやこういうのはせめて期間の平均残高とかを見るだろうとブチギレました。Discordも似たような人々の怨嗟の声で荒れていました。
MetamaskをつなぐとStarkExユーザー分のアロケは取れていましたが使用量によらず一律の枚数でしかもかなり少なかったので絶望しました。
丸2日くらい落ち込んでいましたがいまや私は決闘者です。Atomic Arbで取り返してやろうとコードを全て見直し、準備万端で2月20日のTGE戦に臨みました。
Claimが始まるとネットワークが詰まり始めました。投げたTxの結果がなかなか返ってこない中、競合を見ているとどんどん鞘を取っています。何かコードに問題があるのかと大焦りしながらBotを止めて点検しなおしましたが、単に自分のbotがTxを投げるたびに結果が返ってくるのを待つようになっていたために身動きが取れなくなっているだけでした。
出鼻をくじかれる形になりましたが、一定時間待って返ってこなければ無視して次のループに進むようにしたり複数並列で走らせるようにしたり急遽修正リリースをしました。MempoolがいっぱいでTxが投げられないなど通常見ないエラーの対処などもあり一晩中画面に張り付きながら戦いました。
$STRKの流動性供給が本格的に始まるまでに時間差があり、その間に主要な修正が完了したのが幸いでした。$STRKの取引が活発になると大きな鞘をどんどん取ってくるようになり、最初の24時間で6万ドルくらいは拾ってきたと思います。年初から積み上げてきたものが報われた瞬間でした。
はじめてのLiquidation
1週間ほどたつとStarknet上のアクティビティは落ち着いてきました。
トークンローンチで競合も入ってきたのか鞘をかすめ取られることも増えてきました。
この頃の仮想通貨市況はBTC、ETHなど主要銘柄が上昇しプチバブルの入り口といった様相であり、アービトラージの価値が相対的に低下しているように感じられるのも若干つらいところでした。
そろそろ手札を増やす必要があると思い、着手することにしたのがLiquidation Botです。レンディングプロトコルの清算を担い、プロトコルの健全性を保つ見返りに担保の一部を貰い受けるお仕事です。
清算に着目した根拠は以下の通りです
マーケット全体が上昇続きでどこかで崩れそう=清算機会の発生
StarknetではDeFi Springというイベントを実施しており、仕組みもよくわからずにレンディングプロトコルにお金を入れている養分が多そう
Blastメインネットローンチによってロックされていた大量のETHが解放されるなどリスクイベントが控えていた
レンディングプロトコルはいくつかありましたが、Starknet最大手のNostraを対象に清算の仕様を精査しました。
アーキテクチャを練るのに1日、実際にコードを書いて試行錯誤するのに2日ほどかかりました。
2月29日深夜に完成し、動かしてみるといきなり3件ほど清算してお金が入ってきたのでびっくりしました。ちょうどこのときBTCが$63,000を超えたのち急落したタイミングだったせいかと思います。
オンチェーンの処理は問題なかったものの、清算を判定するロジックの詰めが甘く、ほとんどを競合に取られていました。完成がもう一日早く、チューニングする猶予があればこの下落でもっと稼げたかもと悔しい思いをしました。いつ「その時」が来るかはわからないので、開発は早いに越したことはないです。
Liquidation Botの動き出しはパッとしなかったのですが、競合が清算した余波と思われる鞘を弊Atomic Arb Botが回収しており、なんと一撃3万ドル弱の利益になりました。
スピードを求めて
Liquidation botの稼働によりRPCプロバイダの有料プランでもAPIリクエスト回数の上限を超える見通しとなってしまったことや、日に日に強くなる競合に対抗するためにノードとの通信のオーバーヘッドを削減したいという事情からフルノードを立てることにしました。
自分でノードを立ててみると、様々なオプション項目があることに気が付きました。パフォーマンスに直結しそうな項目もあり、しかもデフォルト値はやや保守的な値が設定されていました。RPCプロバイダではこういった項目のカスタマイズはできないし、そもそもどのような値がセットされているかもわからないので、もっと早くフルノードを立てるべきでした。
フルノードを立てただけではまだ競合に負けることが多く、さらなるスピードを求めて1msでも早くなりそうなことは片っ端から試しました
フルノードのソースコードを熟読し一部改造
鞘や清算の検知ロジック全体を見直し効率化
オンチェーン処理とオフチェーン処理のバランス調整
ここにRust化も追加したかったのですが重い腰が上がらず執筆時点でもRust化できていません…
Liquidation botはversion13くらいまで改良を重ね、それなりの勝率になりました。DEX arbの方はどうしても勝てない競合がおり軟調が続きました。
大清算
4月12日夜間から大きめの暴落がありました。
この日は子供の寝かしつけから一緒に熟睡してしまい、目覚めたのは4月13日朝5時頃でした。明らかに市場に大きな動きがあったのにbotの通知が全くきておらず嫌な予感がしてPCに向かうと、Windows Updateで強制再起動していました。
大変お恥ずかしい話なのですがフルノードやbotをnohupなりscreenなりでバックグラウンド実行するべきところ、調べるのを面倒くさがって普通にサーバーにSSH接続してコマンド実行していたため再起動でbotも全て止まってしまっていました。
慌てて復旧するとたちまち大量の清算が始まりました。シークエンサー側のrate limitにかかって一時txが送れなくなるほどでした。おそらく競合も詰まっていて残っていたのだと思われます。Public RPCから送ると通る場面などもあり色々試しながらtxを通していきました。
増えていくお金を見ながら、自分が不在の間どれほどの鞘があったのだろうと思うと悔しすぎて早朝から叫びながら床をのたうちまわってしまい、起きてきた妻に怒られました。
面倒くさくてもbotが止まらない仕組みづくりをきちんと行うべきであるという教訓になりました。
その後も同日夜間まで断続的に大量清算が発生し、競合と半々で分け合うくらいの勝率で利益を取れました。大きい清算を優先するソーティングの仕組みをいれたおかげで金額的にはこちらの方が儲かっていたように思います。復旧してから24時間の利益はS級に達していました。
ボーナスタイムの終わり
大清算の日以降はいまいちパッとしない日々が続きました。
Liquidation botの勝率も下がり始め、どこに手を入れればパフォーマンスが改善するのかもわからず自分の技術力の限界を感じ始めました。
さらに自分を取り巻く環境も開発ペースの低下に拍車をかけました
本業におけるポジションが変わりこれまでより忙しくなった。在宅勤務中にサボって開発する余裕もなく、疲れから夜間に起きていられなくなった
小中学生の頃ドはまりしていたMMORPGのバナー広告が出てきて懐かしさからうっかり始めてしまったら思いの外ハマってしまった（致命傷）
公に書けませんがプライベートでも色々ありバタバタしていた
この状況に追い打ちをかけるように6月8日にNostraの清算の仕様変更が発表されました。
それは清算による利益をプロトコルに還元するというもので、なんと清算ボーナスのうち8割をプロトコルリザーブに入れるというのです。我々からすれば単純に利益率が従来の2割になるということで大改悪でした。それだけにとどまらず、reward_capというパラメータが設定され、それを超えた分は取り上げられるという仕様も追加されました。このreward_capがだいたい各通貨$100前後に設定されており、完全に商売あがったりという感じでした。もはや仕様変更対応をする気も起きないくらい萎えてしまい、撤退することにしました。
Starknetには他にzkLendというレンディングプロトコルもあるのですが、こちらはこちらで清算の仕様が異なっており全く違うゲームになっているため私はあまりやる気がでませんでした。
こうして弊BotのStarknet上での競争力はほとんどなくなってしまいボーナスタイムは終了しました。以降は執筆時点に至るまで微修正を繰り返しながらお小遣い程度の鞘を拾うBotとして細々稼働しています。
まぁ、今でも競争力を持っていたらこの記事は書けなかったと思います。
zkSync上場戦（敗走）
Starknetでの競争力を失い、開発にも身が入らない中、zkSyncのエアドロが発表されました。
戦場選びで避けてきたEVM系ではありましたが、大きめのエアドロになりそうなこと、食い扶持を失っている状態でなりふり構っていられなかったことから挑戦することにしました。ちなみにエアドロは1枚ももらえてません。
1週間前からの着手で時間もほとんどありませんでしたがフルノードを立て、開発環境を整えて各DEXのアダプターの作成を急ぎました。
結局完成したのが当日で稼働確認も十分できないまま上場戦に挑むことになりました。Claim開始の16時からBotを稼働させてみるとなんとなく動いているように見えたもののやたらとRevertされており、バグが埋め込まれているのは明白でした。結局SyncSwapのwithdrawalModeの設定ミスだったのですが発覚に時間がかかりかなりの機会損失になってしまいました。結局一晩動かしての利益は1ETHあるかないかといった程度でその後は鞘の検知すらできなくなったので撤収しました。
EVMであることによる戦場としての厳しさもあったと思いますが書き慣れないSolidityでの開発をするには明らかに準備時間が不足しており、突貫工事になってしまったことを深く反省しました。
QASHさんがClaim開始時間が実は公式の公表時刻より15分早かったことを書いておられて、馬鹿正直に16時から稼働させたことを恥じるとともに経験値の違いを感じました。
zksyncで公式クレームの1600ばかり頭にあってちゃんと調べずに1545からクレームできたことに気が付かなかった人は反省した方がいいやつです。
— QASH_NFT (@qash_NFT) June 18, 2024
FuelでGOX事件
タイトル落ちという感じですが結論から言うとFuelで16.7ezETHを失うという事件がありました。
新たな戦場を探す中で期待値高めだと思っていたのがFuelというチェーンです。Swayという独自言語かつ、BTCのようなUTXOモデルを採用しているということでStarknetと同じような理屈で勝てるのではないか思ったからです。ポイントプログラムでpre-depositされている金額も大きく、私自身もエアドロ期待でダブついていたお金を投入していました。
zkSyncの反省からメインネットがローンチする前に十分に準備しようと思いテストネットでSway言語の習得に励みました。
ある程度学習が進み、10月17日にメインネットローンチがやってきました。
満を持してフルノードを起動し、唯一のDEXであるMira AMMで鞘取りをするBotを稼働開始しました。
小銭ではありましたが鞘が取れているのも確認でき、これからコードをどんどん改良しようとやる気に満ち溢れていました。
事件が起きたのは10月21日でした。
異常なアクティビティを検知したとのことでローンチ早々Miraが止まるということがありました。
このチェーン大丈夫か？と思う一方で、DEXのコントラクトにpauseする機能がないように見えたため、実はフロントエンドが動いていないだけでスワップできるのでは？と仮説を立て実験をすることにしました。
この時何を思ったのかこれまでETHをInputとしてbotを動かしていたにも関わらず、pre-depositから移してきたezETHをUSDCにスワップすることにしました。
スワップ用のスクリプトのInput Coinに0.1ezETHを加え（ETHはガス代に使うのでそのまま）、実行しました。失敗したらRevertされるだけだし、最悪0.1ezETHなら何かあっても大丈夫と油断していました。
Input Contractが足りていないというエラーメッセージとともにトランザクションは失敗しました。なるほど、pauseするためのProxyコントラクトが追加されたのかもな、と思いながらふとウォレット残高を見ると、あったはずの16.7ezETHの姿がありません。
焦りながらエクスプローラーを確認すると、InputのUTXOとして16.7ezETHが丸ごと使われた後、それが手元に戻ってきていないようでした。
事象を詳しく説明しようとするとFuelの仕様を細かく書くことになってしまうのですが、まず第一にFuelでは並列実行を可能とするためにトランザクションのパラメータとしてそのトランザクションに関わる全てのコイン及びコントラクトのInput/Outputを列挙する必要があります。
ここで、FuelはUTXOモデルなのでInput Coinはトークンに一定の数量が付いたものになります。下記画像でいうと4.5USDCを送金したいとして、5USDCのUTXOしか持っていなければそれがInputとして使われ、最後におつりとして0.5USDCが返ってくるイメージです。
このおつりの役割を担うのがOutput Changeというパラメータになります。こいつがトランザクションで使われなかった分のコインを吸収し、指定した持ち主のUTXOとして返却されます。
ここで問題のトランザクションに戻ると私は0.1ezETHをスワップするためにInput CoinにezETHを追加したのですが、この際Output Change側にezETHを追加するのを忘れてしまいました。つまり余ったezETHは受取人不在で消滅することになってしまいます。最悪なことにezETHはpre-depositからブリッジしたままだったので16.7ezETHが一つのUTXOになっておりその全てがInputとして使われ、そして消滅しました。
しかし、そもそもこのトランザクションは失敗しRevertされています。Revertされているのにガス代以外の状態が変化するというのはトランザクションにAtomicityが無いということではないか、そもそもパラメータ指定を1つミスったら資産が消滅するのは安全性が低すぎるのではないかと違和感だらけでした。
チェーンの仕様と言われればそれまでで、私の過失ではあるのですがThe squeaky wheel gets the greaseの精神でワンチャン取り戻せればと思い騒ぐことにしました。
まずは開発者向けフォーラムで問い合わせてみましたが、こちらはテンプレのような質問に回答してから反応がなくなり1週間くらい放置されてしまいました。
次はDiscordで騒ぐことにします。ちょうどそのころ唯一のレンディングプロトコルであるSwayLendが資金引き出しを停止しておりコミュニティに不安が広がっていました（本当に大丈夫かこのチェーン？）。ここで「トランザクションを投げたらお金が無くなった！」と大げさに騒げば流石に無視できないだろうということで噓にならない程度に誇張して投稿しました。
作戦通りコミュニティマネージャが飛んできてすぐに調査するとリプライを飛ばしてきました。あとは必要な情報を渡して天に祈るだけです。
皆さんお察しとは思いますが結論としてはこれはチェーンの仕様だし変なカスタムトランザクションを投げたお前が悪い、ということでお金は戻ってきませんでした。
この事件で得た教訓は以下の通りです。
実験をするときは何が起きるかわからないので資金が入っていないウォレットでやろう
チェーンの仕様を端から端まで読んできちんと理解しよう
手癖で適当にコードを書き換えるのはやめよう
16.7ezETHは冷静に考えると大金なのですが、この頃はパーソナルジムに通い始めて大して重量が上がるわけでもないのに謎にポジティブ思考になっていたのでなんとか耐えることができました。筋トレは正義。
Fuelは間もなくエアドロされそうな気配なので、失った資金の補填としてある程度の額になることを祈るばかりです。
おわりに
編集して縮めたつもりでしたが、元が日記ということもありダラダラと長い記事になってしまいました。最後まで読んでくださった方はありがとうございます。
Atomic Arbの世界に飛び込んでみて、実際に利益が得られたことはもちろん嬉しいですが、それ以上に色々なことを学ぶことができました。
以下雑感です。
とりあえずやってみる
当初Atomic Arbの世界は異常者達がしのぎを削る魔境というイメージでしたが、自分で手を動かしたり悩んだりすることで見えてくるものがかなりありました。素人でも戦える場所はあるし、完全な勝者総取りでもないという認識です。きっかけとなったRosさんのnoteを見返してみると、年初よりも解像度高く理解できるようになっていました。それでもまだ何言ってるかわからないところがあるのがこの世界の闇奥深いところですね場所とタイミングが重要
「戦場の選定」の項でも述べましたが、Atomic ArbがPvPコンテンツである以上、自分より強い人間が少ない場所で戦うことが重要です（トップ層で殴り合える猛者は除く）。また、それと同じくらいタイミングも収益性に大きく関わるファクターです。私の場合、利益の大部分が2月末～5月上旬に出ているわけですが、この競合が少なく収益機会が多いボーナスタイムに万全の状態でbotが稼働していることが肝要なわけです。何か起きて傍目から見ても盛り上がっているような状態になってから動き始めても遅いのです。zkSync上場戦ではギリギリになってから動き出した結果、準備不足の状態で挑むことになりたいした結果を残せませんでした不労所得ではない
botが動き出したらあとは寝起金増、などということは全くなく、botの生存確認、競合の分析、パフォーマンスチューニング、チェーンやDappsの仕様変更対応など心休まる時間はほとんどありません。普通に過労所得です。特に新興チェーンではトランザクションの仕様が変わっただの、Dappsのバージョンアップでコントラクトアドレスが変更になり、関数も変わっただのといったことは頻繁に起こります。botのお世話係として働き続けることになります。逆にいうとそこに最速で対応することが収益機会になりえます。体力勝負です、筋トレしましょう。リスクフリーではない
Atomic Arbそれ自体はガス代だけがコストでありほぼリスクフリーと言えるかもしれませんが、その運用においては様々なリスクが伴います。私がFuelでやらかしたようにコーディングの誤りで資金を失うリスク、チェーンそのものに付随するリスク、ハニーポットトークンなどBot殺しを意図した悪意ある攻撃を受けるリスクなどなど。事前に十分なテストをする、ウォレットに多額の資金を置かないなど自衛する必要があります。
最後にAtomic Arb botのP/Lを貼っておきます。Starknetのみ集計し、ステーブル以外で獲得した利益については時価変動の影響を除くため直近価格で換算しているのでリアルタイムと比べると若干盛られていることに留意してください。最終的な金額は大体あってます。
マイルストーン
1月4日：取り組み開始
1月5日：初のAtomic Arbに成功（via 公式ルーター）
1月8日：初めてCairoコントラクトを実装
1月14日：DEX-DEX Arbに成功（via 自作コントラクト）
1月19日：累計利益$1,000
2月14日：累計利益$10,000
2月22日：累計利益$100,000
2月29日：Liquidation bot稼働開始
3月7日：累計利益$200,000
5月1日：累計利益$500,000
帳簿をつけながら、税金高すぎるなとか、来年は何に力を入れようかとか、仕事をこのまま続けていくのか専業化・法人化を目指すべきなのかとか色々と考える事の多い年末を過ごしています。
質問やご意見につきましてはXまでお願いします。
コメント