Un bot anti-attaque sandwich vise à réduire le risque qu’un échange du trader soit exploité par l’ordonnancement des transactions qui l’entourent. Son nom décrit un objectif défensif, et non un mécanisme universel unique. Une conception utile combine des conditions de trading compréhensibles, une exposition des informations contrôlée et des preuves que les changements finaux du compte correspondaient à l’autorisation de l’utilisateur.
La première erreur à éviter est de considérer une étiquette de protection comme une autorisation d’ignorer l’opération sous-jacente. Un actif peu liquide reste difficile à échanger, et un mauvais achat peut perdre de la valeur même si son exécution est ordonnée. La défense concerne la réalisation de l’opération ; elle n’établit pas qu’il faut la réaliser.
Cet article explique les couches de protection et la manière d’évaluer leurs limites. Ses scénarios fictifs portent sur les propres cotations, autorisations et résultats du trader. Ils ne décrivent pas comment exploiter un autre participant ou interférer avec une transaction en attente.
Définir le préjudice visé par la défense
Le risque de sandwich implique qu’un autre participant organise une activité environnante qui modifie les conditions d’exécution rencontrées par l’opération de l’utilisateur. L’effet important pour celui-ci est un échange potentiellement moins favorable. Expliquer le risque ne nécessite pas de reproduire la méthode opérationnelle d’un attaquant.
La présentation officielle de la MEV sur Ethereum situe l’ordonnancement des transactions dans le concept plus large de valeur maximale extractible. Les attaques sandwich ne sont qu’un risque possible dans cet ensemble. Un contrôle visant un schéma particulier ne doit pas être présenté comme éliminant tous les coûts liés à l’ordonnancement.
Partez d’un mouvement d’actifs concret : le compte accepte d’échanger une quantité bornée d’un jeton vérifié contre une quantité acceptable d’un autre. La défense doit préserver cette instruction même si la transaction proposée devient attrayante pour d’autres participants du marché.
Le guide de protection contre la MEV approfondit cette question du périmètre. Il aide à distinguer une affirmation de réduction d’une exposition précise d’une promesse selon laquelle le marché fournira un résultat favorable ou rentable.
Construire les couches de protection d’un bot anti-attaque sandwich
Les couches de protection d’un bot anti-attaque sandwich doivent avoir des rôles différents. La sélection des opérations rejette les propositions économiquement inadaptées. La validation des cotations vérifie les preuves utilisées pour construire l’échange. Les contraintes de transaction expriment les conditions acceptables. Les choix d’acheminement affectent l’exposition des informations et le traitement. Le rapprochement établit ce qui s’est passé.
Une défaillance d’une couche n’est pas nécessairement réparée par la solidité d’une autre. Un acheminement privé ne peut pas faire fonctionner normalement un jeton non pris en charge. Une cotation récente ne peut pas expliquer une autorisation de dépense inhabituelle. Une quantité minimale reçue correcte ne peut pas garantir que l’actif conservera ensuite sa valeur.
Écrivez ce que chaque couche peut et ne peut pas établir. Cela empêche l’opérateur d’interpréter plusieurs indicateurs verts comme des confirmations répétées d’une même affirmation générale de sécurité. Ils peuvent au contraire concerner des faits distincts et beaucoup plus limités.
Pour un achat fictif, le système pourrait établir une identité correcte, une cotation actuelle et une quantité reçue bornée tout en laissant une fonction de transfert personnalisée non résolue. La décision appropriée découle de cette dépendance non résolue, plutôt que d’une moyenne des contrôles favorables en un score global de confiance.
Commencer par une opération compréhensible
L’échange proposé par le compte doit être précis avant d’envisager les réglages de protection. Identifiez le réseau, le jeton d’entrée, le jeton de sortie, le montant, le destinataire et le chemin prévu. Un symbole ou le nom populaire d’un pool ne suffit pas à définir l’action autorisée.
Une cotation pour le mauvais jeton peut être cohérente en interne tout en étant inutile. De même, une transaction peut respecter sa quantité minimale reçue tout en envoyant cette quantité à un destinataire que l’utilisateur ne souhaitait pas. Les contrôles anti-sandwich ne remplacent pas l’examen élémentaire des autorisations.
Évaluez l’opération à sa taille réelle. Une petite cotation d’essai peut masquer l’impact de prix d’un ordre plus important. Si la proposition plus grande est déjà inintéressante avant toute activité environnante, un chemin d’acheminement protégé ne la transforme pas en un échange raisonnable.
Le guide d’achat des memecoins explique cet enchaînement entre actif et chemin. L’exécution défensive commence par une instruction économique pertinente, plutôt que par la volonté de faire entrer dans le compte chaque jeton découvert.
Traduire les limites de cotation du bot anti-attaque sandwich
Les limites de cotation d’un bot anti-attaque sandwich doivent être exprimées dans les quantités que le mécanisme de règlement impose réellement. Pour une opération à entrée exacte, l’utilisateur s’intéresse généralement à la quantité minimale acceptable reçue. D’autres types d’opérations peuvent au contraire fixer la quantité reçue et borner l’entrée.
Supposons qu’une cotation fictive prévoie 12 000 jetons en sortie. Selon une convention simplifiée de tolérance d’un pour cent sur la quantité reçue, le minimum serait de 11 880. Un résultat réalisé de 11 910 resterait dans cette limite, même s’il est inférieur à la cotation originale.
La limite définit donc une dégradation autorisée, et non une promesse de recevoir les 12 000 cotés. Un évaluateur doit distinguer l’application de la limite de la question séparée de la cause du changement du résultat final.
Vérifiez si le montant est brut ou net de tout effet propre au jeton. Un minimum appliqué à une étape de transfert peut avoir une signification différente de la quantité dépensable finalement créditée. La sémantique réelle du chemin détermine si la limite économique voulue est correctement représentée.
Comprendre le coût d’une limite plus stricte
Une limite plus stricte réduit l’éventail des résultats acceptables. Elle peut aussi laisser davantage de propositions inexécutées lorsque l’activité normale du marché modifie les prix. Cette conséquence n’est pas automatiquement un défaut ; elle fait partie du choix de la discipline de prix plutôt que de la certitude de réalisation.
Revenons à la cotation fictive de 12 000 jetons. Une limite de 11 988 n’autorise qu’un dixième de pour cent de dégradation selon la convention indiquée. Un marché ayant évolué indépendamment vers 11 970 ne la satisferait plus, même sans preuve d’attaque.
La réponse correcte est un nouvel examen économique, et non une règle automatique d’assouplissement du seuil après chaque rejet. L’utilisateur peut juger le nouveau prix acceptable, mais cette décision doit être visible et encadrée par la politique générale de dépenses.
Comparez l’ensemble des résultats pour évaluer des réglages plus stricts. Comptez séparément les propositions rejetées, les dépenses d’échec applicables et les décisions ultérieures. Une configuration annonçant d’excellentes exécutions moyennes en excluant la plupart des tentatives doit divulguer cette sélection avant qu’on puisse interpréter son résultat.
Distinguer l’âge de la cotation du délai d’inclusion
L’âge des données d’entrée et le temps nécessaire au traitement d’une transaction sont des intervalles différents. Une soumission très rapide construite à partir de réserves périmées peut tout de même être mal valorisée. Une cotation récente peut devenir obsolète pendant l’attente de la transaction.
Consignez quand l’état source a été observé, quand l’application l’a reçu, quand la transaction a été autorisée et quand un résultat a été établi. Ces horodatages révèlent où l’incertitude s’est accumulée sans prétendre qu’un seul chiffre de temps de réponse explique tout le processus.
Pour une chronologie fictive, l’observation source intervient à 09:00:00, l’autorisation à 09:00:03 et l’exécution à 09:00:05. La référence économique de l’opération a cinq secondes à l’exécution, même si la transmission finale n’a pris qu’une petite fraction de cette période.
Une règle de fraîcheur peut rejeter une ancienne proposition avant qu’elle n’engendre d’autres engagements. L’âge pertinent doit suivre les exigences réelles de preuves de la stratégie. Réutiliser une ancienne cotation parce que son enveloppe de transaction reste techniquement valide confond deux formes de validité distinctes.
Examiner qui reçoit la transaction
Une divulgation réduite avant exécution peut constituer une couche de protection, mais privé ne signifie pas que personne ne voit le contenu. Le chemin choisi peut s’appuyer sur des opérateurs ou d’autres infrastructures qui reçoivent des informations avant le règlement. Ces destinataires et leur comportement déclaré comptent.
Examinez quelles parties de la transaction sont partagées, avec qui et selon quelle configuration. Une option qui élargit les destinataires pour améliorer la disponibilité peut modifier les hypothèses de confiance. L’explication la plus utile relie ce changement à son objectif plutôt que d’utiliser une seule étiquette protégé pour chaque réglage.
Évitez de déduire une garantie à l’échelle du réseau d’une règle propre à un service. Un fournisseur peut imposer des conditions au sein de son propre chemin sans contrôler les autres systèmes ou tous les environnements de traitement ultérieurs. Ses limites documentées font partie de la description de la protection.
Le guide d’exécution anti-MEV examine cette distinction entre divulgation et prix. Aucune dimension ne doit masquer l’autre : une divulgation limitée ne remplace pas une limite de quantité reçue, et une telle limite n’établit pas la confidentialité.
Intégrer le comportement de repli à la politique initiale
Un chemin privilégié peut devenir indisponible ou ne pas fournir de preuves à temps. La politique de repli détermine si le bot attend, s’arrête ou utilise une solution explicitement acceptable. Ce comportement peut compter davantage que le chemin choisi lors d’une démonstration sans incident.
Un repli qui modifie les destinataires, les frais ou l’âge de la cotation doit laisser une trace. Le système doit aussi réexaminer si l’autorisation initiale reste valide. Un nouveau chemin utilisant des conditions sensiblement différentes n’est pas simplement une nouvelle tentative technique.
Supposons qu’une politique hypothétique n’autorise un chemin alternatif que tant que la cotation est plus récente qu’une limite définie et que la même quantité minimale reçue est imposée. Si l’une des conditions échoue, l’action suivante est une nouvelle décision ou l’absence d’opération, et non une escalade sans contraintes.
Évaluez la politique avec un cas de test de panne, au moyen de données enregistrées ou synthétiques. Le résultat important est de savoir si le système préserve les limites économiques de l’utilisateur lorsque son chemin privilégié est absent. Un réglage qui ne fonctionne que dans des conditions idéales ne constitue pas la politique opérationnelle complète.
Recommandez et gagnez des USDC
Recommandez et gagnez des USDCNotre programme d’affiliation paie en temps réel.
La protection du prix diffère de la sécurité du compte
Un système peut protéger le prix d’un échange tout en demandant une autorisation de dépense que l’utilisateur ne comprend pas. La portée des approbations, l’accès aux signataires et la vérification des destinataires méritent leur propre évaluation. Un bon reçu d’exécution ne justifie pas rétroactivement des pouvoirs excessifs.
Pour les actifs ERC-20, le modèle standard d’autorisation de dépense distingue le solde d’un propriétaire du montant qu’un tiers autorisé à dépenser ses jetons est habilité à utiliser. Un bot doit expliquer l’autorisation nécessaire à l’opération prévue et ce qui en subsiste après.
Les contrôles correspondants diffèrent selon les chaînes et les types de comptes. N’appliquez pas sans modification le modèle mental d’autorisation Ethereum à chaque instruction de jeton Solana ou dispositif de compte délégué. Le pouvoir doit être évalué selon le mécanisme réel.
Une comparaison de protection doit donc conserver des constats distincts pour la qualité d’exécution et le contrôle des actifs. Une interface peut offrir un routage compréhensible tout en présentant une garde peu claire, ou une garde claire avec un repli mal documenté. Fusionner les deux en un score unique de sécurité masquerait des distinctions utiles.
Dérouler une comparaison fictive tous frais compris
Considérez deux exécutions fictives pour une même valeur d’entrée prévue dans des conditions globalement comparables. Le chemin A livre 9 900 jetons et occasionne quatre unités de cotation de dépenses distinctes sur un échange de 200 unités. Sa dépense complète est de 204.
Le chemin B livre 10 000 jetons tout en occasionnant neuf unités de dépenses distinctes. Sa dépense complète est de 209. Le chemin A coûte environ 0,020606 unité de cotation par jeton acquis, tandis que le chemin B coûte 0,0209. Dans cet exemple, le chemin livrant davantage de jetons présente le coût unitaire total le plus élevé.
Ces nombres ne mesurent aucun produit. Ils montrent pourquoi la seule quantité reçue ne permet pas d’évaluer un service défensif qui modifie les frais. La comparaison pertinente inclut le débit réel du compte et la quantité réellement reçue selon des conventions de valorisation cohérentes.
Une hausse ultérieure du prix du jeton ne changerait pas l’acquisition la moins chère dans cet exemple. La qualité d’exécution se mesure au moment de l’échange ; la performance d’investissement ajoute les mouvements ultérieurs du marché et la sortie finale. Garder ces mesures distinctes empêche qu’une hausse de prix chanceuse certifie le mécanisme de protection.
Distinguer les remboursements estimés des économies confirmées
Si un service annonce des remboursements possibles ou des bénéfices d’exécution partagés, examinez les critères et le moment où le montant devient définitif. Un crédit estimé peut améliorer un aperçu sans encore réduire la dépense réelle du compte. L’utilisateur doit pouvoir évaluer l’opération avant de compter un revenu conditionnel.
Pour un autre achat fictif, supposons que l’échange dépense deux cents unités et que les frais associés totalisent six. La dépense actuelle est de 206. Un remboursement possible affiché de deux ne ramène pas la dépense confirmée à 204 tant que le droit et le montant reçu ne sont pas établis selon les conditions pertinentes.
La comptabilité doit conserver les deux dates lorsqu’elles diffèrent : la date de l’opération et la date de réception ultérieure. Cela permet à un rapport d’attribuer le paiement à l’opération qui l’a généré sans prétendre que les fonds étaient disponibles plus tôt.
Un remboursement ne prouve pas non plus que tous les risques d’ordonnancement ont été empêchés. Il s’agit d’un transfert économique régi par ses propres conditions. Évaluez séparément l’échange initial, le mécanisme de protection et le crédit reçu, puis calculez leur effet combiné. Cela empêche qu’un bonus favorable masque une exécution défavorable ou un problème plus large d’autorisation.
Comptabiliser les non-exécutions sans inventer d’exécution hypothétique
Une opération rejetée ne révèle pas ce qui se serait passé si la protection avait été retirée. Elle peut avoir évité un mauvais échange, manqué un mouvement ultérieur favorable ou simplement reflété une proposition périmée. Le scénario contrefactuel nécessite des hypothèses qui doivent être identifiées.
Dans un ensemble fictif de cinquante propositions, supposons que trente aboutissent dans les limites, dix soient rejetées localement, cinq soient exécutées sans succès et cinq restent non résolues à la date de clôture du rapport. L’étude contient trente résultats achevés, et non cinquante exécutions protégées confirmées.
Le groupe non résolu doit rester visible jusqu’à ce que les preuves permettent sa classification. Les cinq échecs après exécution peuvent occasionner des dépenses différentes des dix rejets locaux. Traiter toutes les non-réalisations comme un même événement élimine des informations nécessaires pour améliorer le processus.
Pour évaluer le coût d’opportunité, utilisez la stratégie déclarée et des prix ultérieurs réalistes. N’attribuez pas à chaque proposition rejetée le meilleur prix ultérieur du graphique. Cela pénaliserait des contraintes raisonnables à l’aide d’informations indisponibles lors de la décision initiale.
Réunir les preuves d’évaluation du bot anti-attaque sandwich
Les preuves d’évaluation d’un bot anti-attaque sandwich doivent relier la cotation originale, les limites autorisées, le chemin choisi, l’identité de la transaction et les changements finaux du compte. L’activité environnante pertinente peut aider à expliquer l’écart, mais le registre du compte constitue le point de départ.
Classez soigneusement les observations. Un résultat moins bon que la cotation est directement mesurable. Une activité voisine affectant le même pool peut aussi être observable. Affirmer qu’une autre adresse a délibérément ciblé l’opération ajoute une inférence sur l’intention et le contrôle qui nécessite des preuves distinctes.
Conservez les explications alternatives, notamment les mouvements de prix indépendants, les erreurs de cotation, les conventions de taille et les effets de transfert. Une enquête devient plus utile lorsqu’elle identifie les explications encore plausibles et les preuves qui permettraient de les départager.
Le rapport ne doit pas exiger l’étiquette définitive d’un attaquant avant de reconnaître un véritable problème d’exécution. Un utilisateur peut resserrer une politique ou rejeter un chemin mal compris en raison de lacunes observées tout en laissant l’attribution non résolue. Il s’agit d’une conclusion plus limitée soutenue par les faits disponibles.
Éviter de considérer le fractionnement des opérations comme une défense universelle
Diviser un échange important prévu en opérations plus petites modifie à la fois l’interaction avec le marché et le coût opérationnel. Cela ne supprime pas automatiquement les risques de divulgation ou d’ordonnancement, et la séquence complète peut rester visible à travers son activité réelle.
Une exécution fictive en quatre parties avec une dépense fixe de deux unités par partie paie huit unités avant les autres coûts, tandis qu’une seule opération selon le même modèle de frais simplifié en paie deux. Toute amélioration des conditions moyennes d’échange doit être évaluée au regard de cet écart de six unités et de la modification de l’exposition aux prix au fil du temps.
Des opérations distinctes nécessitent aussi une politique d’engagement. Réaliser la première partie ne garantit pas que les suivantes resteront attrayantes ou même exécutables. Le compte peut se retrouver avec une allocation partielle différente du plan initial.
Évaluez l’intégralité de l’échange prévu, y compris les parties inachevées, sans traiter la fragmentation comme une technique de dissimulation. La question légitime est de savoir si un calendrier clairement autorisé améliore l’économie de l’utilisateur dans les conditions actuelles de liquidité et de coûts, et non s’il crée une image trompeuse de demande indépendante.
Tester les limites susceptibles de défaillir indépendamment
Une évaluation défensive utile inclut des cas où une couche échoue tandis que les autres restent fonctionnelles. Un chemin correct avec une cotation expirée, une cotation récente avec un destinataire inhabituel et une transaction valide avec une soumission non résolue testent chacun des dépendances différentes.
Utilisez des cas de test clairement identifiés pour vérifier la décision attendue. Le système doit expliquer pourquoi une proposition est rejetée ou mise en pause et conserver assez de preuves pour qu’un examinateur puisse en reconstituer la raison. Un message d’erreur générique n’établit pas que le contrôle prévu a été exercé.
Testez aussi les changements de configuration et la reprise. Si un redémarrage supprime la limite sélectionnée ou restaure un chemin par défaut plus large, la défense effective a changé. Les réglages et l’état du compte doivent être restaurés ensemble avant l’autorisation de nouveaux engagements.
Ces tests ne prouvent pas une immunité future. Ils établissent que le bot suit sa politique déclarée dans des conditions précises. Cette distinction est utile, car la fiabilité de l’implémentation et l’efficacité économique d’une politique nécessitent des preuves différentes.
Déterminer si la couche supplémentaire mérite son coût
Une fonction de protection doit être évaluée selon le contexte réel de trading de l’utilisateur, et non selon un désir abstrait de l’étiquette la plus impressionnante. Les différences pertinentes incluent la taille des opérations, la liquidité, la disponibilité des chemins, le mouvement de prix attendu et le coût de l’acceptation d’une absence d’exécution.
Une exécution modestement améliorée peut être économiquement utile si son bénéfice dépasse les dépenses supplémentaires dans une comparaison équitable. Une couche coûteuse peut aussi être justifiée par un objectif de risque plus restreint, mais cette finalité doit être explicite plutôt que déguisée en économies garanties.
Conservez les observations défavorables et décrivez les limites de l’échantillon. Quelques réussites sélectionnées ne peuvent pas établir une performance sur tous les actifs ou toutes les conditions de marché. Les améliorations doivent être rattachées au périmètre réellement étudié.
Un bot anti-attaque sandwich est utile lorsqu’il préserve des conditions de trading compréhensibles et rend ses propres limites visibles. L’affirmation la plus solide qu’il puisse soutenir repose sur des preuves complètes : une menace définie, des contrôles précis, des coûts honnêtement présentés et un résultat de compte explicable sans prétendre que chaque changement défavorable de prix a été éliminé.