Comment résoudre la vulnérabilité de premier plan dans les contrats intelligents

Même si les files d'attente au supermarché ou dans les points de vente où vous payez vos factures de services publics sont de l'histoire ancienne, certains d'entre nous savent ce que l'on ressent lorsque quelqu'un fait la queue.

Au début de la file d'attente, c'est-à-dire. Surtout si c'est pour la raison que leur facture a beaucoup plus de valeur que les autres qui font la queue. Évidemment, cela ne devrait pas être un critère lorsqu'il s'agit de la rapidité du service.

Maintenant, cette affaire d'être déplacé en tête de file se produit également dans les contrats intelligents Ethereum. Autrement connue sous le nom d'erreur de premier plan, dont le nom a été obtenu à partir d'un phénomène similaire du marché boursier, les transactions de contrats intelligents qui paient des frais d'essence plus élevés ont tendance à être davantage favorisées que celles qui ne le font pas.

Décomposer la vulnérabilité frontale

Dès le départ, cette vulnérabilité ne se produit pas en raison d'une programmation défectueuse, mais utilise la manière dont les transactions sont ordonnées et ajoutées à un bloc à partir du "mempool".

Outre les utilisateurs réguliers qui cherchent à gagner rapidement de l'argent, les mineurs ont tendance à tirer profit d'une telle transaction et c'est pourquoi ce sont eux qui sont les plus susceptibles de surveiller de telles transactions avant qu'elles ne soient ajoutées à un bloc. En fait, une fois qu'ils le font, ils envoient leur propre transaction pour une récompense financière injuste, qui finit par être ajoutée à un bloc plutôt qu'à celui qui a été envoyé en premier.

Ce qu'il faut garder à l'esprit ici, c'est que les transactions qui ont été engagées avec un prix du gaz plus élevé ont tendance à être traitées en premier par rapport aux autres. En gardant cette préférence à l'esprit, l'attaquant peut modifier le résultat d'événements tels que les enchères, les échanges ou les offres initiales de pièces en sa faveur simplement en payant des frais d'essence plus élevés.

Examinons cet exemple courant pour comprendre le fonctionnement de la vulnérabilité frontale :

Dans cet exemple, nous avons trois acteurs : Naman, Kaavya et Aishwarya. Naman déploie d'abord le défi Hashing en tant que contrat intelligent que les deux autres doivent résoudre. Celui qui résoudra ce puzzle de hachage obtiendra 10 éther en récompense.

Maintenant, Kaavya trouve d'abord la solution de hachage et l'envoie avec 10 Gwei comme frais d'essence, à partir de son propre contrat intelligent :

D'autre part, Aishwarya trouve la réponse un peu plus tard et passe la bonne réponse à son contrat intelligent avec 100 Gwei comme frais d'essence.

En raison du paiement de frais d'essence plus élevés, au lieu que Kaavya reçoive la récompense de 10 Ether, Aishwarya la reçoit, comme indiqué ci-dessous :

En termes simples, il s'agit de l'erreur de premier plan ou de commande de transaction, car elle traite les transactions en fonction de la valeur des frais de gaz.

En d'autres termes, même si Kaavya a soumis sa réponse avant Aishwarya, elle n'obtient rien pour ses efforts, comme indiqué ci-dessous :

Étant donné que ce «saut en ligne» d'Aishwarya ne plaira ni à Kaavya ni à personne d'autre, quelques mesures préventives doivent être envisagées pour notre code de contrat intelligent.

3 façons de gérer la vulnérabilité de premier plan

Maintenant, il existe des correctifs qui peuvent empêcher une telle perte. En d'autres termes, nous devrions être en mesure de verrouiller une transaction comme celle qui devrait recevoir les 10 Ether.

Méthode 1 : Compteur de transactions

L'utilisation d'un compteur de transactions est l'un des moyens les plus simples de dissuader quiconque d'obtenir la récompense par tout autre moyen.

Comme vous pouvez le constater à partir du code ajouté ci-dessous, un compteur de transactions a été ajouté qui verrouille la transaction engagée par la personne qui a terminé le défi de hachage en premier. Étant donné que seul le premier à le faire doit obtenir la récompense, nous informons tous les participants d'ajouter la valeur 0 à leur solution.

Puisque la valeur actuelle de txCounter sera zéro pour la première solution présentée, elle est verrouillée. En d'autres termes, et comme dans l'exemple ci-dessus, Kaavya entrera sa solution ainsi que la valeur de zéro pour recevoir sa récompense de 10 Ether .

Si quelqu'un d'autre le fait, la solution ne sera pas acceptée car le compteur de transactions a été incrémenté à une valeur supérieure à un. À ce moment-là, la totalité de la récompense de 10 Ether, qui devrait aller à Kaavya, lui sera transférée à juste titre.

Méthode 2 : Définition des limites de gaz

Maintenant, avec cette méthode, l'accent est mis sur la définition d'une limite de gaz pour toutes les transactions. Les deux, une limite inférieure et une limite supérieure, si nécessaire.

Comme vous vous en souvenez peut-être, les transactions sont ordonnées en fonction du montant des frais de gaz payés pour ladite transaction. Bien que cela n'élimine pas complètement cette commande, cela la réduit certainement dans une large mesure.

Si vous regardez le code ci-dessous, toutes les transactions qui paient du gaz d'un montant égal ou inférieur à 1 seront acceptées, mais celles qui essaient de sauter la ligne en payant plus de gaz ne le seront pas, grâce au modificateur gasThrottle. Dans ce cas, 1 Wei ou Gwei pourrait être le coût standard de traitement d'une telle transaction et c'est tout ce qui sera autorisé.

Ainsi, si toutes les transactions ne varient pas tant que ça en gaz grâce à cette manette, la question de privilégier certaines transactions ne se posera pas. Bien qu'il y ait des avantages à une telle approche, les frais de gaz payés sont appelés à changer à l'avenir.

Ce qui est élevé aujourd'hui sera bas dans quelques années, donc Naman doit être vigilant à tout moment. Ou bien, Aish pourrait être en mesure de tirer parti de ces valeurs changeantes en attendant simplement un moment.

Méthode 3 : L'approche par envoi sous-marin

Maintenant, bien que les deux approches précédentes puissent fonctionner pour des situations plus simples, elles ne traitent jamais vraiment la cause première de la vulnérabilité principale : la divulgation complète des informations de transaction aux mineurs et aux autres utilisateurs malveillants.

Il devrait être évident que tant que ces deux parties ont accès aux informations de chaque transaction, le risque de jouer avec le système persiste. De toute évidence, une méthode par laquelle ces informations sensibles au temps doivent être masquées est nécessaire et qui nous amène à l'approche d'envoi sous-marin, implémentée dans le cadre de la bibliothèque de contrats intelligents LibSubmarine .

Lorsque l'on utilise cette approche, ils cachent les informations de transaction de telle manière que les mineurs ou les utilisateurs réguliers ne peuvent pas vraiment en profiter. Le cryptage joue un rôle important dans la protection de ces informations qui, à la discrétion du propriétaire, peuvent être révélées une fois ajoutées à un bloc.

Cela dit, même si cette approche n'est pas parfaite, le niveau de protection qu'elle offre est bien meilleur par rapport aux autres méthodes, en raison de sa volonté de s'attaquer à la véritable raison pour laquelle le front-running a lieu - à la fois dans le monde réel et sur la blockchain.

Autres stratégies pour contourner la vulnérabilité frontale

Bien sûr, les stratégies discutées dans la section précédente ne sont pas les seules à protéger les contrats intelligents de la vulnérabilité « de premier plan ».

Avec les chaînes latérales, la commande a lieu hors chaîne tandis que le règlement s'effectue dessus. Ces deux étapes se déroulant sur différentes plates-formes, cela a non seulement des avantages pour un débit accru, mais dissuadera les mineurs ou les utilisateurs réguliers d'obtenir les informations nécessaires pour exploiter la vulnérabilité de premier plan.

Une autre stratégie, même si elle est de nature théorique, consiste à randomiser l'ordre des transactions pour un tour particulier qui a été engagé dans un schéma d'engagement-révélation. Ceci est appliqué à l'aide d'une logique de contrat intelligente. Les pionniers n'iront pas en tête de file avec cette approche car la commande est déterminée par le contrat intelligent susmentionné.

Enfin, une autre approche implique la mise en œuvre du protocole injectif où les utilisateurs résolvent des fonctions de retard vérifiables pour cette valeur t très importante qui détermine qui reçoit la commande. Par conséquent, en étant capable de s'éloigner du système de commande aléatoire utilisé par la plupart des chaînes de blocs, la possibilité d'attaques en amont est également réduite.