Friend.Techを例に挙げて、オンチェーンロボットの基本原理を浅く分析する。

著者：3PDAO

前言

Friend.Tech は、スマートコントラクトに基づくソーシャルプラットフォームで、ユーザーは自分の Twitter を接続して登録し、自分のキーを「発行」する必要があります。キーを持つユーザーは、キーのオーナーと交流するために、グループチャットのようなルームに入ることができます。これは依然として中央集権的なソーシャルプラットフォームであり、チェーン上のスマートコントラクトを利用してキーの購入や販売のロジックを実現していますが、主な機能はウェブベースの IM アプリケーションに基づいています。また、キーの販売や購入の過程で、価値の 10% が二つの部分に分けられ、一方は Friend.Tech の開発者に、もう一方は対応するルームのオーナーに渡されます。

このようなキーがフロントエンドを回避して購入や販売を行うことができる場合、自然にチェーン上のボットが新規購入、売買、手数料詐欺の操作を行うことになります。それでは、彼らはどのように実現しているのでしょうか？

新規購入ボットについて

新規購入ボットは、Friend.Tech の運営初期にかなりの利益を上げることができます。この時期、チェーン上のスナイパーボットはまだ一定の進化を遂げておらず、簡単な情報判断を行った後に購入を行い、高い利益期待が得られます。まずは、最もシンプルなボットの実装ロジックから始め、徐々に複雑なボットロジックを完成させていきます。

もちろん、その前に Event を紹介する必要があります。イベントは、Solidity プログラミング言語における EVM のログイベントの抽象です。通常、emit 文と組み合わせてイベントをトリガーします。ブロックチェーンブラウザでの取引のログに対応します。例えば、以下のキー購入の取引は、Trade イベントをトリガーし、イベントには一連の情報が含まれています。

Event は DApp の中で非常に重要な部分であり、これを通じてコントラクトの状態変化を監視できます。例えば、Friend.Tech もこのコントラクトを監視して、データベース内の一連のデータを調整します。例えば、フロントエンドの表示価格や保有数量などです。

最もシンプルな考え方

最もシンプルな新規購入ボットのロジックは次のようになります：Friend.Tech のコントラクトイベントを監視し、取引によってトリガーされたイベントが以下の条件を満たす場合に Friend.Tech のコントラクトを呼び出して購入します。

• イベントは購入（isBuy 値が真）

• 取引者とオーナーが同じアドレス（trader == subject）

• 取引はルームの作成取引（supply が 1）

下の図はこのプロセスのフローチャートです。

コントラクト？原子性！

このようなボットにはいくつかの問題があります：

1. 新規購入が必ずできるわけではなく、購入に必要な eth の正確な金額を示すことができません；

2. 上限価格を設定できず、例えば取引実行時にどれだけのキーや価格に達した場合は購入しないということができません；

3. スナイプされやすく、他の人が新しいアドレスを使って購入操作を実行し、このようなボットを引き寄せ、手数料を騙し取ったり、売却して利益を得たりすることができます；

まず、問題 1 と 2 を解決することを考えます。EVM の利点の一つは、原子性を持って一つのコントラクト内で他のコントラクトを呼び出すことができることです。したがって、購入を行うために一つのコントラクトをデプロイし、一連の条件を設定すれば良いのです。例えば、GitHub 上のオープンソースのコントラクトコード friendrekt では、最高購入価格や数量を設定できます。

問題 3 に関しては、最もシンプルな方法は 公式のインターフェース を利用して、対応するアドレスのユーザーの Twitter 情報を取得し、Twitter のフォロワー数などの情報を調べてフィルタリングし、フィルタリング後に購入するかどうか、購入する数量や最高価格を判断することです。これにより、ボットの操作フローは以下の図のようになります。

技術の爆発

このプロセスでは、情報リクエストとスマートコントラクトの呼び出しが追加されます。ボットはコントラクトイベントを監視した後、簡単なロジック判断を経て新しいアカウントがアクティブであると判断し、API を利用して関連情報を取得してフィルタリングし、最後にデプロイしたスマートコントラクトを利用して購入を完了します。しかし、このようなボットにも欠陥があります：

1. フィッシングの Twitter アカウントを判断できず、一部のアカウントはフォロワー数が多いですが、全てがゾンビフォロワーであり、価値がないため、購入には大きなリスクがあります；

2. フォロワー数は Twitter ユーザーの価値を判断するのに便利ではなく、一部の KOL はフォロワー数が少ないですが、運営が上手であるため、これらの人々をフィルタリングしてしまう可能性があります；

3. API には一定の遅延があり、このインターフェースはユーザーがアクティブになった後の一定の時間（60 秒）内にしかクエリできず、多くのアドレスを見逃す可能性が高く、遅延も大きいです；

同様に、これらの問題を一つ一つ解決します。まず問題 3 に関して、0xleo のインスピレーションを得て 私はどのように friend.tech で 1 万ドルを失ったのか - 0xleo

別のインターフェースを発見しました。ユーザーが登録した後に クエリ できるアドレス情報を取得できるため、このインターフェースを継続的に監視して最新の ID を探し、登録者の情報を取得します。価値のある登録者と判断された場合、そのアドレスをキャッシュに保存します（再起動の持続性を保証するために、データベースも必要です）。チェーン上のイベントを監視し、キャッシュにヒットした場合に購入を行います。

次に問題 1 と 2 に関して、ユーザーが価値があるかどうかを判断するには、いくつかの第三者の Twitter KOL 評価サイトの助けが必要です。筆者は探索の過程で Twiiterscan を使用してクエリを行いました。登録情報を事前に取得できるため、アクティブになる前に Twiiterscan をクエリするのにかかる時間はあまり影響がありません。それに加えて、手動でホワイトリストや購入価格を設定して購入構成を完成させることもできます。

最後に、私たちが実現したボットの基本的なフローは以下の通りです。追加の「ボット」が API の最新情報を取得し、判断後にデータベースやキャッシュに保存し、購入を担当するボットはイベントを受け取った後にキャッシュ情報をクエリし、キャッシュにヒットした場合に購入を行います。このキャッシュにはホワイトリスト情報も保存でき、価値のある KOL を選択した後、価格や数量を設定して購入します。

筆者がこのボットを実装したのは比較的遅かったため、利益もあまり客観的ではありません。9 月末から実装と最適化を始め、10 月 3 日頃に最高 1.2E の利益を達成しましたが、その後数日間でタイミングを逃し、利益が減少しました。手数料の一連の支出を加えると、利益も損失もない状態になりました。このような構造のボットは、登録者が購入した後の最初のブロックで購入を実現できます。ベース上にはメモリプールスキャンのような操作がないため、同じブロックで購入するほとんどは狂ったプレイスタイルです：購入を監視してから、購入が完了するまで購入を続けます。例えば、このプロセスで見た別のボット：

https://basescan.org/address/0x88e6aeb90795f586542b4062cb9f853a5582966c

その戦略は非常にシンプルで、上記で紹介した構造の基礎の上に、データベースを保存せずに直接購入を開始し、購入が完了するまで続けます。この程度まで最適化すると、資金量のゲームになります。ガスを支払えるなら、このようなプレイが可能で、戦略が正しい場合は利益も特に大きくなります。

結語

前言部分で、売買や手数料詐欺の操作についても触れましたが、ここで少し紹介します：

1. 売買はフォローボットの一種で、利益の良いアドレスを追跡し、その操作に従うことができます。原理も非常にシンプルで、監視しているアドレスをフィルタリングし、ターゲットアドレスであれば操作に従います；

2. 手数料詐欺には二種類があります（筆者が開発過程で観察したもの）。一つはフォロワー数が多い Twitter アカウントを利用して行われ、直接購入し、すぐに売却して収穫を行います。もう一つは、新しいアドレスを次々と作成し、送金してから購入操作を実行し、すぐに売却します。第二の方法は、最もシンプルなロジックのボットを対象としており、初期には良い利益を得られるはずです。

これで、チェーン上のボットの原理についての紹介が完了しました。具体的な実装についてはコードに関する説明は省略しますが、興味のある方は friendrekt の実装を参考にしてください。