仕組みはシンプルで、ステーブルコインであるUSDCを軸に、特定通貨への最適ルートを検出。その後変更先通貨からUSDCの最適ルートを検出して、利益が出るかを見積もる。見積もりで利益が出そうならトランザクションを発行するという感じ。
現時点で利益が出ることは多分ないと思っているけど、叩き台は出来たかなという感じ。
とりあえず一日稼働させてみてどうなるかは見てみるけど、とりあえず現時点で見つかった課題をまとめておく
同期的処理ではやはりだめ
実行状況を見ていると、たまに鞘が見つかってもすぐになくなっているように見えた。
数百種類の対象トークンを同期的にループさせて一つ一つ見ていくような形にしているため、例えば1~900トークンあったとして、最初にトークン1を見てから次にトークン1を見るまでの時間は数十分ごとかになってしまう。
無駄が多すぎるため、実装を直すべき
とはいえ非同期処理での対応では限界があると思っているため、並列処理に強い言語で作り直す必要がある。
その場合はやはりRustが選択肢に入りそう。
sdkを利用して実装しているが、そのsdkはjsのみ対応しているため、Rust等並列処理に強い言語で実装するのであればリバースエンジニアリングが必須
Rustの再学習も考慮するとかなりの労力がかかると思われる。
対象トークンの見積もり
現在は特定のAPIを利用してトークンのリストを取得している。
正直無駄が多い。
しかし定数としてトークンのリストを作成する方向だと、常に新規トークン情報を追う必要があり厳しい。
solanaネットワーク上すべてのトークンを対象とする方法は、可能性としては一応ありかもしれないが、詐欺トークンを扱わないようにできるか不穏なためあまりやりたくない（トークンは誰でも実装できるため、出金の関数をトークン作成者のみ実行できるように出来てしまう。入金したが最後取り出せなくなるのが詐欺トークン）
どうやるのがベストかは検討がつかない
利益検出ロジックの改善
現在はガス代未考慮のため、小さな利幅を取ろうとするとガス負けする。
ガスを考慮できるように修正すべき。
またスリッページの存在もあることを注意しておきたい。
websocketの活用
現在はとにかくルートの検出を同期的に行っているだけなので無駄が多い。
本来はwebsocketを活用し、変化があったときに素早く利益が見込めるか見積もりを行うという実装になるはず
ただ具体的にはどうやるべきか検討はついていない
トランザクションの失敗
利益が見込めるスワップを見つけても、スリッページの問題でトランザクションの失敗が発生しているケースが多い
ここを何とかする必要がある。
見積もり段階でスリッページが高いと見込めたら発行しないとか？
Amount決定ロジック
基本的に一度に交換する通貨量が増えるほど、利益が見込みにくくなるっぽい。のでこの通貨量決定ロジックはなにか考え方がありそうに思えた。
そもそも裁定取引自体、どうやって一度に取引する通貨量決めてるのかわからない。裁定取引の勉強でもしたほうがいいのかもしれない
トランザクションを一つにまとめたい
現状
A -> B
B -> A
で２つに分かれている。
一つのトランザクションに複数のトランザクションを含めることができるので、一つにまとめたい。
その場合はEVMでいうコントラクトのデプロイが必要。solanaにおけるProgramなんだけどどうやってデプロイするのか問題。この辺は公式チュートリアルを順番にちゃんとやればわかるかも？
---
取り急ぎ。一日動かしてみてほか気づいたことあったら追記する
検討付かない部分も多いため、ロジックがより深く理解できるという意味でもsdkをRustに落とし込む作業をやるかも
そうなったらまずはRust再学習が先説ある
