Simulation de transaction : ce qu'une transaction fera avant que vous la signiez

L'adresse est bonne. Le montant est bon. Vous avez vérifié les deux. Et la transaction n'est toujours pas ce que vous croyez.

Ce n'est pas une hypothèse. C'est la forme ordinaire de la plupart des pertes en crypto qui impliquent quelqu'un de soigneux. Personne ne l'a convaincu d'envoyer de l'argent à un inconnu. Il a approuvé quelque chose dont toutes les parties visibles étaient correctes et dont les conséquences se trouvaient entièrement ailleurs — dans une autorisation de dépense de jetons, dans un appel de contrat, dans un caractère d'une adresse vue cent fois.

La simulation est la tentative de combler cet écart : vous montrer les effets d'une transaction plutôt que son contenu, avant que votre signature ne la rende réelle.

L'écart entre ce que vous vouliez et ce que vous signez

Une transaction n'est pas une phrase. Ce sont des octets.

Quand ces octets forment un simple transfert, l'écart entre ce qu'ils disent et ce qu'ils font est mince : une adresse, un montant, des frais. Quand ils forment un appel de contrat, l'écart peut être énorme. approve ressemble à une permission. C'est un droit permanent, accordé à une autre adresse, de déplacer vos jetons, et selon le standard ERC-20 rien dans l'appel n'oblige à borner le montant ni la durée. Une seule autorisation, signée une fois, peut être vidée des mois plus tard.

L'interface que vous regardez au moment de signer doit traduire ces octets en une phrase. Cette traduction est la surface d'attaque. Si elle est produite par celui qui veut votre signature, elle peut dire n'importe quoi.

Une répétition, pas une promesse

Simuler, c'est exécuter la transaction contre l'état actuel de la chaîne sans la diffuser, et enregistrer ce qui change.

Dans SSP Enterprise, cela se produit à la création d'une proposition, avant que quiconque signe. La simulation est bâtie à partir de ce que le constructeur de la proposition a produit — destinataires, montants, contrat du jeton et données d'appel que SSP a elle-même assemblés — jamais à partir d'un hex signé brut fourni par un client. Elle s'exécute en lecture seule. Trois moteurs couvrent les différentes familles de chaînes :

• Les chaînes EVM exécutent un appel en lecture seule contre un nœud et relisent les variations de solde qui en résultent ainsi que l'appel décodé.
• Les chaînes UTXO n'ont besoin d'aucun nœud. Les entrées et les sorties sont déjà connues, donc l'avant-après est de l'arithmétique sur les pièces sélectionnées, et les destinataires sont classés en monnaie qui vous revient ou véritablement externes.
• Solana désérialise la transaction non signée produite par le constructeur et exécute le simulateTransaction du réseau lui-même, vérification des signatures désactivée, puis lit dans le résultat les soldes de jetons du coffre avant et après.

Ce qui revient est un aperçu : quel était le solde de chaque actif avant, quel il sera après, et — sur EVM — ce qu'est réellement l'appel, décodé en une méthode et ses arguments.

Deux choses qu'il n'est pas. Ce n'est pas une garantie : l'état de la chaîne bouge, et une simulation lancée au moment de la proposition est une photo de la chaîne telle qu'elle était alors. Et ce n'est pas un verrou. C'est la moitié la plus intéressante de la conception, et nous y reviendrons.

Quatorze choses qu'il vaut mieux vous dire

Un aperçu qui ne montre que des chiffres vous demande encore de repérer vous-même le problème. L'aperçu est donc accompagné d'alertes, et il y en a quatorze, sur quatre niveaux de gravité.

Les autorisations — la catégorie qui vide le plus de portefeuilles. Une autorisation illimitée ou non bornée est critique. Toute autorisation de dépense non nulle vers une adresse absente de votre liste d'autorisation est élevée. Et autoriser un compte détenu par une personne plutôt qu'un contrat est élevée, car il n'existe pour ainsi dire aucune raison légitime de le faire : ce sont les contrats qui dépensent des autorisations, pas les gens.

Les destinataires — un destinataire absent des contacts de votre organisation et de la liste blanche du coffre est signalé. De même qu'un destinataire vers lequel votre coffre n'a jamais envoyé. Ni l'un ni l'autre n'est fautif en soi. Les deux méritent une seconde lecture.

Le risque contractuel — un contrat de destination dont la source n'est pas vérifiée, un contrat déployé depuis moins de sept jours, une valeur native envoyée à un contrat tout court, et toute adresse qu'un fournisseur signale comme franchement malveillante.

L'exécution — la transaction qui échoue en simulation, ce qui signifie qu'elle échouera sur la chaîne et gaspillera les frais. Ou la sortie simulée qui ne correspond pas aux montants annoncés par la proposition : le coffre perd plus, ou moins, que ce que dit l'écran.

La dégradation — et, clairement étiqueté, le cas où la simulation n'a pas pu s'exécuter. Un nœud injoignable produit « indisponible », pas du silence ni un certificat de bonne santé inventé.

La distinction entre ces gravités compte davantage que le total. Critique et élevée parlent d'une transaction qui n'est probablement pas ce qu'elle paraît. Moyenne et informative parlent d'une transaction inhabituelle, ce que les transactions légitimes sont parfois.

L'empoisonnement d'adresse : l'attaque qui bat les gens soigneux

Une alerte mérite sa propre section, car elle vise précisément l'habitude que la plupart des conseils de sécurité recommandent.

L'empoisonnement d'adresse fonctionne ainsi. Un attaquant envoie à votre coffre une transaction minuscule ou de valeur nulle depuis une adresse fabriquée pour partager les six premiers et les quatre derniers caractères d'une adresse avec laquelle vous traitez déjà. Rien n'est volé. Rien n'est même vraiment fait. La transaction existe pour que l'adresse sosie apparaisse dans votre historique.

Plus tard — des jours plus tard, quand vous repayez la même contrepartie — vous copiez l'adresse depuis votre propre historique, comme le font les gens soigneux plutôt que de la retaper. Vous la vérifiez comme vérifient les gens soigneux : les premiers caractères, les derniers caractères. Les deux correspondent. Le milieu non, et le milieu est là où va l'argent.

SSP compare chaque destinataire d'une proposition aux adresses que votre coffre connaît déjà, avec exactement la comparaison préfixe-suffixe que fait l'œil humain, et lève une alerte critique nommant l'adresse imitée. Le même contrôle tourne dans l'autre sens sur l'historique entrant, de sorte qu'une adresse empoisonnée est marquée à son arrivée et non seulement quand vous êtes sur le point de l'utiliser.

La raison de connaître cette attaque même si vous n'utilisez jamais SSP : l'habitude de vérification qui arrête toutes les autres attaques d'adresse est justement celle que celle-ci est conçue pour vaincre. Comparez des adresses entières, ou ne comparez rien.

Pourquoi les alertes sont calculées côté serveur — et n'empêchent pourtant rien

L'ensemble des alertes est décidé côté serveur, à partir des contacts de votre organisation et de la liste blanche du coffre comme source de vérité. C'est délibéré : si un client pouvait décider de ce qui compte comme autorisé, un client compromis pourrait décider en silence que tout l'est.

Et pourtant rien de tout cela ne peut arrêter une transaction. La simulation ne conditionne jamais la signature ni la diffusion. Un fournisseur qui échoue, expire ou n'atteint pas de nœud renvoie « indisponible », et la proposition reste entièrement signable. Tout le sous-système est isolé des pannes pour qu'un plantage de l'aperçu ne puisse jamais laisser une proposition en rade.

Cela sonnera comme un choix étrange, aussi vaut-il mieux énoncer clairement le raisonnement. Un aperçu qui peut bloquer est un aperçu qu'on peut faire bloquer — en abattant un nœud, en produisant une fausse alerte critique, par l'une des mille manières dont un logiciel se détraque. Des fonds qui ne peuvent pas bouger parce qu'un service consultatif est en panne sont des fonds que vous avez en partie perdus. C'est le seuil du multisig qui protège l'argent ; la simulation est là pour informer les humains qui détiennent les clés. Ce qui arrête réellement une transaction est la version longue de cet argument.

Quand le serveur et votre appareil ne sont pas d'accord

Tout ce qui précède est la lecture du serveur. Votre appareil fait la sienne.

Quand SSP Wallet vous présente une proposition à signer, il décode les octets lui-même et affiche ce que lui a trouvé — pas le résumé du serveur. Puis il compare les deux. Si l'appel décodé par le serveur implique un ensemble de destinataires différent de celui que l'appareil a dérivé, l'appareil lève sa propre alerte critique de divergence et déclasse visuellement l'aperçu du serveur.

Le décodage de l'appareil fait autorité. Le contrôle est délibérément conservateur : une simulation serveur absente ou en attente est une dégradation, pas une contradiction, et n'est pas signalée comme telle. Il ne s'applique en outre qu'aux chaînes EVM, où le serveur produit un appel décodé ; sur les chaînes UTXO il n'y a rien à comparer, et le décodage propre de l'appareil tient simplement seul.

Voilà la propriété à retenir, quel que soit votre portefeuille. Un second avis ne vaut quelque chose que s'il vient d'un endroit qui n'aurait pas pu être compromis par le même acte que le premier. Deux résumés du même serveur font un seul résumé.

Lire un bandeau de risque sans apprendre à l'ignorer

Les alertes ne fonctionnent que tant qu'elles ne deviennent pas du papier peint. Quelques habitudes les gardent utiles.

Lisez d'abord la gravité, ensuite le détail. Critique et élevée méritent qu'on s'arrête. Une alerte moyenne ou informative sur un premier paiement à un nouveau fournisseur, c'est le système qui fonctionne, pas un motif d'inquiétude.

Traitez toute alerte d'autorisation comme un arrêt net. Les transferts déplacent ce qu'ils disent déplacer. Les autorisations accordent un droit qui survit à la transaction. Si vous n'aviez pas l'intention d'accorder une permission durable, la réponse est non.

Croyez l'appareil plutôt que l'écran. S'ils divergent, le téléphone dans votre main est celui qui tourne sur un matériel qu'un attaquant aurait dû compromettre séparément.

Ne prenez pas « indisponible » pour « tout va bien ». Cela veut dire que personne n'a vérifié. C'est une raison de regarder vous-même de plus près, surtout sur un paiement important ou inhabituel.

Tout ceci concerne l'instant qui précède une signature. Pour ce qui vient après — qui peut signer, combien il en faut, et quelles opérations réclament de nouveau les deux appareils — commencez par configurer votre premier coffre d'entreprise et les actions critiques et la re-signature. Et pour les schémas d'attaque autour desquels ces alertes sont façonnées, les attaques de phishing visant les utilisateurs de crypto couvrent la moitié humaine du problème.