Analyse des principes fondamentaux des robots sur la blockchain à travers l'exemple de FriendTech
TechFlow SélectionTechFlow Sélection
Analyse des principes fondamentaux des robots sur la blockchain à travers l'exemple de FriendTech
Comment les robots sur la chaîne effectuent-ils des opérations de souscription, d'achat et de vente, ainsi que des fraudes sur les frais de transaction, en contournant l'interface frontend ?
Dédié à des analyses Web3 approfondiesIntroduction
Friend.Tech est une plateforme sociale basée sur des contrats intelligents, où les utilisateurs doivent connecter leur compte Twitter pour s'inscrire et « émettre » leurs propres clés (keys). Les détenteurs d'une clé peuvent accéder à une salle de discussion similaire à un groupe de discussion afin d'échanger avec le propriétaire de la clé. Il s'agit toujours d'une plateforme sociale centralisée, qui repose simplement sur des contrats intelligents blockchain pour gérer l'achat et la vente des clés, tandis que ses principales fonctionnalités sont réalisées via une application de messagerie instantanée (IM) web. Lors de chaque transaction d'achat ou de vente d'une clé, 10 % de la valeur est divisée en deux parties : une partie va aux développeurs de Friend.Tech, l'autre au propriétaire de la salle correspondante.
Dans ce contexte, puisque l'achat et la vente des clés peuvent être effectués directement sur la chaîne sans passer par l'interface frontale, il devient naturel qu'apparaissent des robots blockchain capables de réaliser des opérations telles que le sniping (prise anticipée), le trading automatique ou encore des fraudes sur les frais de transaction. Mais comment ces robots fonctionnent-ils exactement ?
À propos des robots de sniping
Au début du déploiement de Friend.Tech, les robots de sniping pouvaient générer des profits très intéressants, car les robots concurrents n’étaient pas encore suffisamment sophistiqués. À cette époque, après une simple analyse d’information, il était possible d’acheter rapidement avec un haut niveau d’espérance de profit. Maintenant, commençons par la logique la plus simple pour progressivement construire un bot plus complexe.
Avant cela, il convient d’introduire le concept d’événement (Event), qui représente en langage Solidity une abstraction des journaux (logs) dans la machine virtuelle Ethereum (EVM). Un événement est généralement déclenché par une instruction emit. Sur un explorateur blockchain, cela apparaît sous forme de logs associés à une transaction. Par exemple, lors d’un achat de clé, un événement Trade est déclenché, contenant diverses informations :
Les événements jouent un rôle crucial dans les DApps, car ils permettent d’écouter les changements d’état du contrat. Par exemple, Friend.Tech surveille ces événements pour mettre à jour sa base de données, ajuster le prix affiché en temps réel ou le nombre de clés détenues (holding).
Approche la plus simple
La logique la plus élémentaire d’un robot de sniping consiste à écouter les événements du contrat Friend.Tech, puis à acheter immédiatement une clé si les conditions suivantes sont remplies :
-
L’événement indique un achat (
isBuyest vrai) -
L’acheteur et le propriétaire sont la même adresse (
trader==subject) -
La transaction crée une nouvelle room (
supply= 1)
Le schéma ci-dessous illustre ce processus :
Contrat ? Atomicité !
Ce type de robot présente plusieurs limitations :
-
Il ne garantit pas l’achat réussi de la clé ni le montant exact d’ETH nécessaire ;
-
Impossible de fixer un prix maximum : aucune condition ne peut arrêter l’achat si le prix ou la quantité dépasse un seuil donné ;
-
Vulnérable au piégeage : un utilisateur malveillant peut créer une nouvelle adresse, effectuer un achat simulé pour attirer le robot, puis revendre rapidement pour empocher les frais de transaction.
Pour résoudre les problèmes 1 et 2, on peut tirer parti d’une caractéristique clé de l’EVM : l’atomicité. En effet, un contrat peut appeler d’autres contrats de manière atomique. Il suffit donc de déployer un contrat dédié à l’achat, intégrant des conditions personnalisées comme un prix maximum ou une quantité cible. Par exemple, le code open source friendrekt disponible sur GitHub implémente précisément ces fonctionnalités.
Concernant le problème 3, la solution la plus simple consiste à utiliser l’API officielle pour récupérer les informations Twitter liées à une adresse, notamment le nombre de followers. Ces données permettent de filtrer les comptes avant d’effectuer un achat, et ainsi décider combien acheter et à quel prix maximal. Le flux de travail du robot devient alors le suivant :
Explosion technologique
On observe ici un ajout d’appels API et d’interactions avec des contrats intelligents. Après avoir détecté un événement, le robot vérifie s’il s’agit d’un nouveau compte activé, interroge l’API pour obtenir des informations complémentaires, filtre selon certains critères, puis exécute l’achat via un contrat déployé. Cependant, ce modèle reste imparfait :
-
Impossible de distinguer les comptes Twitter frauduleux : certains ont beaucoup de followers, mais ceux-ci sont souvent des comptes inactifs (bots), rendant l’investissement risqué ;
-
Le nombre de followers n’est pas un bon indicateur de valeur : certains influenceurs (KOL) ont peu de followers mais une forte capacité d’engagement, et risquent donc d’être ignorés ;
-
Les API présentent un certain délai : l’interface officielle ne renvoie les données qu’environ 60 secondes après l’activation, ce qui fait rater de nombreuses opportunités.
Chacun de ces points peut être corrigé. Commençons par le point 3. Grâce à l’inspiration tirée de 0xleo et de son tweet Comment j’ai perdu 10 000 dollars sur friend.tech :
Un autre endpoint permet d’obtenir les informations d’adresse immédiatement après l’inscription via cette URL. On peut donc surveiller continuellement cet endpoint en incrémentant l’ID, récupérer les infos des nouveaux inscrits, et stocker dans un cache (voire une base de données pour persistance) les adresses jugées pertinentes. Dès qu’un événement sur la blockchain correspond à une adresse en cache, l’achat est déclenché.
Ensuite, pour les points 1 et 2 — comment évaluer la valeur d’un utilisateur ? — on peut recourir à des sites tiers notant les influenceurs Twitter. L’auteur a utilisé Twiiterscan dans son exploration. Puisqu’on dispose des infos dès l’inscription, l’analyse préalable sur Twiiterscan n’ajoute pas de latence critique. De plus, on peut configurer manuellement des listes blanches (whitelist) et définir des seuils d’achat.
Finalement, le flux complet du bot se structure comme suit : un « robot » auxiliaire scrute l’API en continu, filtre les nouveaux inscrits, puis stocke les résultats dans une base ou un cache. Le robot principal, lui, écoute les événements blockchain, consulte le cache, et achète si une correspondance est trouvée. Ce cache peut aussi contenir des entrées whitelist, permettant d’acheter des clés de KOL sélectionnés à des prix et quantités prédéfinis.
L’auteur ayant implémenté ce bot relativement tard, les gains n’ont pas été très significatifs. Après avoir commencé à développer et optimiser fin septembre, le pic de profit atteint vers le 3 octobre était d’environ 1,2 ETH. N’ayant pas vendu à temps, la valeur a ensuite baissé, et après déduction des frais de transaction, le bilan final était neutre. Une telle architecture permet d’acheter dès le premier bloc suivant l’activation. Comme Base ne permet pas de scanner le mempool, la plupart des bots qui achètent dans le même bloc adoptent une stratégie agressive : dès qu’un achat est détecté, ils lancent des transactions en boucle jusqu’à réussite. Par exemple, ce bot observé :
https://basescan.org/address/0x88e6aeb90795f586542b4062cb9f853a5582966c
Sa stratégie est simple : contrairement à notre architecture, il ne stocke rien en base, mais lance immédiatement l’achat en continu jusqu’à succès. À ce stade, la compétition devient une course aux ressources : celui qui peut brûler le plus de gas l’emporte, et si la stratégie est bonne, les profits peuvent être importants.
Conclusion
Dans l’introduction, nous avons mentionné brièvement les robots de suivi d’ordres et les fraudes sur les frais. Voici un rapide aperçu :
-
Les robots de suivi (« follow-the-leader ») observent les adresses rentables et reproduisent leurs actions. Le principe est simple : filtrer les événements par adresse cible, puis copier les opérations ;
-
Les fraudes sur les frais se déclinent en deux formes (observées durant le développement). La première utilise un compte Twitter populaire : achat suivi d’une revente rapide pour « récolter » les bots naïfs. La seconde consiste à créer continuellement de nouvelles adresses, transférer des fonds, acheter puis revendre aussitôt. Cette dernière vise spécifiquement les bots basés sur la logique minimale, et pouvait être très rentable au début.
Nous avons ainsi présenté les principes fondamentaux des robots blockchain. L’implémentation concrète, qui inclut du code, n’est pas abordée ici. Pour ceux qui souhaitent approfondir, le projet friendrekt constitue une excellente référence.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@3PDAO
