
FriendTechを例に、オンチェーンロボットの基本原理を簡単に分析する
TechFlow厳選深潮セレクト

FriendTechを例に、オンチェーンロボットの基本原理を簡単に分析する
チェーン上のロボットがフロントエンドをバイパスして購入・売却を行い、新規プロジェクトへの参加(打新)、売買、手数料の不正取得を行う仕組みについて
序論
Friend.Tech はスマートコントラクトに基づくソーシャルプラットフォームであり、ユーザーは登録時に自身のTwitterアカウントを連携する必要があり、「key」を発行できる。このkeyを保有するユーザーは、key所有者と交流可能なチャットルーム(room)に参加できる。これは依然として中央集権的なソーシャルプラットフォームであるが、keyの購入・売却ロジックのみをブロックチェーン上のスマートコントラクトで実現しており、主な機能はWeb上で動作するIMアプリケーションによって提供されている。また、keyの売買時には取引価値の10%が手数料として分割され、一部はFriend.Tech開発者へ、残りは該当roomのオーナーへ分配される。
このようなkeyがフロントエンドを経由せずとも購入・売却可能であるため、当然ながらチェーン上での新規プロジェクト狙い(打新)、売買操作、および手数料詐欺を行うボットが自然発生することになる。では、それらはどのようにして実現されているのか?
打新ボットについて
打新ボットは、Friend.Tech 運営初期において非常に高い収益を得ることができた。この時期、チェーン上のスナイパーボットはまだ十分に進化しておらず、簡単な情報判断に基づいて購入しても高い利益が期待できたからである。ここでは、最もシンプルなボット実装から始め、徐々に複雑なボットのロジックを構築していく。
その前に、まずEvent(イベント)について説明する。Eventとは、Solidity言語におけるEVMログイベントの抽象化概念であり、通常emit文とともに使用され、イベントを発火(トリガー)させる。ブロックチェーンエクスプローラ上では、トランザクションのlogsとして表示される。例えば、以下のkey購入トランザクションでは「Trade」イベントが発火されており、その中に一連の情報が含まれている。

EventはDAppにとって極めて重要な要素であり、これによりスマートコントラクトの状態変更を監視できる。たとえばFriend.Techもこのイベントを監視し、データベース内の各種データ(フロントエンドに表示される価格や保有数など)を更新している。
最もシンプルなアプローチ
もっとも単純な打新ボットのロジックは次の通り:Friend.Techのコントラクトイベントを監視し、以下の条件を満たすトランザクションイベントを検知した場合、直ちにコントラクトを呼び出して購入を実行する。
-
イベントが購入であること(
isBuyがtrue) -
取引者とオーナーが同一アドレスであること(
trader==subject) -
room作成のトランザクションであること(
supplyが1)
以下はその処理フローの概略図である。

コントラクト?アトミシティだ!
しかし、このようなボットにはいくつかの問題がある:
-
新規購入が必ず成功する保証がなく、正確なETH金額も事前に計算できない;
-
上限価格を設定できない。たとえば、key数や価格がある水準に達したら購入を中止するといった制御ができない;
-
スナiping攻撃を受けやすい。他者が新規アドレスで購入操作を行い、このようなボットを誘導することで手数料を搾取したり、利益を得て売却することが可能である;
まず問題1と2を解決するために、EVMの利点である「アトミック性」を利用する。つまり、一つのコントラクト内で他のコントラクトを呼び出し、条件付きで購入を実行できる。たとえばGitHubで公開されているfriendrektコントラクトでは、最大購入価格や数量を事前に設定できる。
問題3については、最も簡単な対策として公式APIを利用して対象アドレスのTwitter情報を取得し、フォロワー数などを確認してフィルタリングを行う方法がある。フィルタリング後、購入するかどうか、いくらまで買うかを判断する。こうして、ボットの処理フローは下図のようになる。

技術爆発
上記のプロセスでは、外部情報のリクエストとスマートコントラクトの呼び出しが追加され、ボットはコントラクトイベントを監視→新規アカウントアクティベーションを判定→APIで関連情報を取得してフィルタリング→デプロイ済みスマートコントラクトで購入を実行、という流れになる。しかし、この方式にも依然として欠点がある:
-
釣りアカウントを判別できない。フォロワー数が多くてもゾンビフォロワーばかりで、実質的価値がないアカウントもあり、購入リスクが高い;
-
フォロワー数だけでは価値を正確に判断できない。少ないフォロワーでも運営能力が高いKOLがいるが、そういった人物を誤って除外してしまう可能性がある;
-
APIに遅延がある。このインターフェースはユーザーがアクティベートされてから約60秒後にしか情報が取得できず、多くのチャンスを逃しやすく、レイテンシも高い;
これらに対しても、一つずつ対策を講じていく。まず問題3については、0xleo氏のツイート「私はどうやってfriend.techで1万ドルを失ったか」からの着想を得て、

別のAPIがユーザー登録直後にアドレス情報を取得可能であることが分かった。これにより、IDを順次インクリメントしながら最新の登録者情報を継続的に監視できる。価値があると判断された登録者のアドレスはキャッシュ(再起動時も保持できるようデータベースも併用)に保存し、チェーン上のイベントが発火してキャッシュと一致した場合に購入を実行する。
次に問題1と2について、ユーザーの価値をどう判断するか?ここでは第三者のTwitter KOL評価サイトの活用が必要になる。筆者は探索中にTwiiterscanを利用した。登録情報は事前に取得可能であるため、アクティベート前の評価に要する時間は無視できる程度である。さらに、ホワイトリストの手動設定や購入価格の指定も可能にする。
最終的に実現したボットの基本的な処理フローは以下の通り。別途「監視用ボット」がAPIから最新情報を取得し、評価後にデータベースとキャッシュに保存。購入専用のボットはイベントを受信後、キャッシュを照合し、マッチすれば購入を実行。このキャッシュにはホワイトリスト情報も保存でき、特定の高価値KOLに対して価格や数量を設定して購入できる。

筆者がこのボットを実装したのは時期的に遅かったため、収益も芳しくなかった。9月下旬に開発・最適化を開始し、10月3日頃に最高で1.2ETHの利益を記録したが、その後すぐに売却しなかったため利益が縮小。手数料などを考慮すると、ほぼ損益ゼロとなった。このようなアーキテクチャのボットは、登録者の購入後最初のブロックで即座に購入可能になる。Baseネットワークにはmempoolスキャンのような高度な手法が存在しないため、同じブロック内で購入を繰り返すボットの多くは、一種の過激な戦略を採用している:購入イベントを検知すると、購入が成功するまで連続してトランザクションを送信する。たとえば、以下のようなボットが観測された:
https://basescan.org/address/0x88e6aeb90795f586542b4062cb9f853a5582966c
その戦略はシンプルで、前述のアーキテクチャをベースに、データベースを介さず即座に購入を開始し、成功するまで繰り返す。このような最適化レベルに達すると、資金量勝負のゲームとなる。ガス代を気にせず大量に投入できる者が有利であり、戦略が正しければ非常に大きな利益を得ることも可能である。
まとめ
序論で触れた売買ボットや手数料詐欺についても簡単に紹介しておく:
-
売買ボットはいわゆる「コピートレード型」であり、収益の良いアドレスを追跡し、その操作に追随する。原理は単純で、監視対象アドレスをフィルタリングし、目標アドレスの操作があれば同様の取引を行う;
-
手数料詐欺には二種類ある(筆者の開発中に観察されたもの)。一つはフォロワー数の多いTwitterアカウントを使い、即座に購入・売却を行い利益を得るもの。もう一つは新規アドレスを繰り返し生成し、転送→購入→即売却を繰り返すもの。後者は特に最もシンプルなロジックのボットを標的にしており、初期段階では高い収益を得られただろう。
以上により、チェーン上ボットの原理についての解説を終える。具体的なコード実装については割愛するが、詳細を知りたい方はfriendrektの実装を参照されたい。
TechFlow公式コミュニティへようこそ
Telegram購読グループ:https://t.me/TechFlowDaily
Twitter公式アカウント:https://x.com/TechFlowPost
Twitter英語アカウント:https://x.com/BlockFlow_News














