今朝方出来立てホヤホヤ。
ちな、朝から回してみての実績
……くそよえ！
難しかったとこ
solanaの仕様解読
取引所の仕様解読
Rust
きつかったのは仕様解読系ですね。solana、ドキュメントが整備されているとはいえないので、基本的にいわゆるリバース・エンジニアリング（コードから読み解くやつ）で仕様把握していく感じでした。
取引所にいたっては、実際のtxからなんとなくこういうデータ渡せばうまく動きそうだなみたいな勘も必要になってきていてやばかったです。というか今後も取引所対応を増やす中でそういうこと多発すると思うので気が重いです。
Rustも最近の言語としてはやたら難しいと言われているだけあってやっぱ難しかったです。補完等してくれるrust-analyzerがめちゃくちゃ優秀なので、ノリでなんとかやってますが、これがなかったら終わってたなぁとか思います。
あと並列プログラミングをまともにやったのRustが初で、これまた難しかったです。というか現状まだ把握しきれていない部分多くて、今後機能を発展させていく中でまた壁に当たるだろうなとか思います。
機能発展とか
現状だと弱すぎくんなので、色々機能充実必要そうだなとか思います。
大抵こういうアビトラ系はHFTというか、速度勝負みたいなイメージが強いかもですが、それはわりと機能が極まってきてからの話で、その前にやらなければいけないことが山積みという印象です。
とりあえず今入力量を固定値にしているので、これを最適化する必要があるなと思います。
あとは裁定パスを3つ以上のトークンに触れるようにするのも急を要するかも。
3トークン以上にするとToken A, B, Cとしたとき、TokenAがスタートだとしたら、TokenB,TokenCのペアを対象に含められるのがクソでかいです。
入力量に関しては材料にできるのはどう考えても流動性しかないだろと思うのですが、具体的な算出がむずすぎるのがなんとも。
裁定パスの算出も難しく、ちょっと現状だといいアイデアがない感じです。
一般的にベルマンフォード法を使うという話を聞きますが、そのためにはルートにおける値を算出する必要があって、その有効な値の算出が出来てないです。というかそれができてたら多分入力量で困らないだろうなという
もし流動性を活用するのであれば、オンチェーンですべてのパスのシュミレートをするのは現実的じゃないでしょうし、オフチェーン計算が発生することになってtx発行速度への不安が発生したり。
考えることは色々ありそうですがなんにせよ入力量最適化が大前提にありそうな気がするのでそこからですかね。
