La première chose que j’ai apprise sur les échanges inter-chaînes, c’est que « échoué » ne veut pas automatiquement dire « perdu ».
Quand quelque chose ne se passe pas comme prévu, la question importante est ce que fait ensuite l’architecture sous-jacente.
Un transfert via un pont et un échange inter-chaînes atomique peuvent échouer de façons complètement différentes.
Cela peut vous laisser en train de déterminer si un relais, une transaction de destination ou une étape de remboursement est toujours en attente.
L’autre peut être conçue de sorte que, si l’échange ne se termine pas, les contrats se déplacent automatiquement vers un processus de dénouement.
Cette distinction est importante lorsque vous transférez de vrais actifs entre chaînes.
L’échec dépend de l’architecture
Une transaction inter-chaînes n’est pas un seul événement.
Il peut y avoir une transaction sur la chaîne source, des confirmations, une transaction côté destination, de la liquidité ou l’exécution du resolver, ainsi que le règlement.
Si une partie ne se finalise pas, la suite dépend de la manière dont le système a été conçu.
Dans certaines architectures de pont, les fonds peuvent rester verrouillés dans un contrat, attendre un processus de relai, ou nécessiter un remboursement manuel ou une tentative de reprise.
Cela ne signifie pas nécessairement que les fonds ont disparu. Cela signifie que l’itinéraire est entré dans un état intermédiaire qui doit être résolu.
C’est pourquoi l’architecture compte autant quand une transaction échoue que lorsqu’elle réussit.
La différence entre « bloqué » et « atomique »
C’est là que je trouve l’idée d’exécution atomique intéressante.
Un itinéraire inter-chaînes à portée ouverte peut potentiellement laisser l’utilisateur se demander :
Où mes fonds se sont-ils arrêtés ?
La transaction source a-t-elle confirmé ?
La transaction de destination a-t-elle échoué ?
Un relayer est-il toujours en train de la traiter ?
Y a-t-il un remboursement disponible ?
Une conception atomique essaie de réduire ces possibilités.
L’objectif est simple :
Soit l’échange convenu se termine, soit les actifs reviennent conformément aux conditions de remboursement du protocole.
Cela ne veut pas dire que les échecs n’arrivent jamais.
Cela signifie que l’échec a été pris en compte dans la conception de la transaction plutôt que d’être traité comme une situation inhabituelle qui obligerait quelqu’un à décider quoi faire ensuite.
Comment Omniston gère le cas d’échec
Omniston adopte une approche basée sur un resolver, utilisant des contrats HTLC (Hashed Timelock Contracts) jumelés.
Pour un échange inter-chaînes, il y a un HTLC côté source et un autre côté destination.
Les deux sont liés par la même condition cryptographique.
Le resolver verrouille l’actif côté destination.
L’actif côté utilisateur (côté source) est également verrouillé.
Quand le secret requis est révélé, les conditions permettent à l’échange d’aboutir : l’utilisateur reçoit l’actif de destination, tandis que le resolver peut réclamer l’actif source.
C’est le chemin de succès.
Mais la partie la plus intéressante est ce qui se passe quand ce chemin ne se termine pas.
Et si le resolver ne répond pas ?
Supposons que je demande un échange inter-chaînes et qu’un resolver s’engage sur le devis, mais ne finalise pas sa partie de la transaction.
Le système ne devrait pas laisser mes fonds rester là indéfiniment.
Le HTLC a un timelock.
Si la condition requise n’est pas remplie dans la fenêtre de temps définie, le timelock permet à la partie appropriée de récupérer ses fonds verrouillés.
Pour l’utilisateur, cela signifie que la transaction peut se dénouer (unwind) au lieu de devenir un mystère sans fin.
Et si le secret n’est jamais révélé ?
Le même principe s’applique si le secret nécessaire pour finaliser le règlement n’est jamais divulgué.
Sans le secret, les HTLC liés ne peuvent pas suivre le chemin normal de règlement.
Une fois le timelock pertinent expiré, les actifs bloqués deviennent remboursables conformément à la logique du contrat.
C’est ce qui rend la conception « tout ou rien ».
Le résultat escompté n’est pas :
« « L’échange a échoué, donc un côté garde l’argent. » »
C’est :
« « L’échange est terminé, ou les fonds pertinents deviennent récupérables via le timelock. » »
STON.fi décrit la conception d’Omniston comme ayant trois issues possibles : les deux parties reçoivent les actifs quotés, l’utilisateur est remboursé si le resolver ne répond pas, ou le resolver est remboursé si le secret n’est jamais divulgué.
Un unwind n’est pas votre argent qui disparaît
C’est probablement la partie la plus importante à comprendre.
Quand vous voyez le mot unwind, cela peut sembler comme si quelque chose avait terriblement mal tourné.
Mais dans ce contexte, le processus de dénouement (unwind) est en réalité un mécanisme de protection.
Les actifs ont été verrouillés temporairement pour permettre le règlement inter-chaînes.
Si les conditions de règlement ne sont pas remplies, le timelock fournit un chemin de retour vers le propriétaire initial.
Donc, la séquence ressemble davantage à :
Verrouiller → tenter le règlement → conditions remplies → finaliser
ou
Verrouiller → le règlement ne se termine pas → timelock → remboursement
Le deuxième chemin n’est pas un échec du mécanisme de protection.
C’est le mécanisme de protection qui fonctionne.
Que devez-vous vérifier quand un échange semble bloqué ?
Je ne soumettrais pas immédiatement une autre transaction.
D’abord, je vérifierais le statut de l’original.
1. Vérifier le statut de la transaction
Regardez le statut affiché par l’application qui gère l’échange.
Est-ce en attente ?
La transaction source est-elle confirmée ?
La partie destination est-elle toujours en cours de traitement ?
Y a-t-il un message d’échec ?
Le statut peut vous dire quelle partie de l’itinéraire vous attendez réellement.
2. Enregistrer le hash de la transaction
Le hash de la transaction fait partie des informations les plus utiles que vous puissiez avoir.
Cela vous donne un moyen de retracer ce qui s’est passé on-chain.
Si, au final, vous avez besoin de contacter le support, l’envoi du hash de la transaction est bien plus utile que de dire simplement :
« « Mon échange est bloqué. » »
3. Vérifier l’explorateur de la blockchain concernée
Ne vous fiez pas uniquement à l’interface de l’application.
Regardez la transaction côté chaîne source et, le cas échéant, la transaction côté destination.
Vous pouvez vérifier si la transaction a été confirmée, annulée (revert) ou si elle est encore en attente.
4. Vérifier si le timelock a expiré
Pour une transaction basée sur HTLC, le moment de la condition de remboursement est important.
Si l’échange n’a pas encore été finalisé et que le timelock concerné n’est pas expiré, les fonds peuvent simplement rester verrouillés sous les conditions du contrat.
Si cela a expiré, vérifiez le portefeuille et l’état pertinent du contrat pour confirmer que le chemin de remboursement a été finalisé.
Quelles informations devriez-vous collecter avant de contacter le support ?
Si j’ai un jour besoin de contacter le support au sujet d’une transaction inter-chaînes, je collecterais tout d’abord tout ce qui est possible.
Au minimum :
- Adresse du portefeuille source
- Adresse du portefeuille de destination
- Hash de la transaction
- Réseau source
- Réseau de destination
- Actif envoyé
- Actif attendu
- Montant
- Temps approximatif auquel l’échange a été initié
- Statut actuel de la transaction
- Tout message d’erreur affiché par l’application
- Liens d’explorateur pertinents
Cela rend beaucoup plus facile d’identifier à quel moment la transaction s’est arrêtée.
Et surtout, ne partagez jamais votre phrase de seed ni votre clé privée avec qui que ce soit qui prétend fournir du support.
Un hash de transaction est utile.
Une clé privée n’est pas quelque chose dont le support devrait avoir besoin.
Pourquoi c’est important
Les échanges inter-chaînes sont plus complexes que les échanges classiques sur une seule chaîne, car plusieurs réseaux et conditions de règlement sont impliqués.
Donc, la gestion des échecs mérite autant d’attention que le flux de transaction réussie.
C’est l’une des raisons pour lesquelles le modèle d’Omniston m’intéresse.
L’architecture jumelée du HTLC ne prétend pas que chaque transaction inter-chaînes se déroulera toujours parfaitement.
À la place, il construit un chemin de récupération défini directement dans la transaction.
Finalisez l’échange quoté, ou laissez la logique du timelock dénouer (unwind) les fonds verrouillés.
Pour moi, c’est un état d’échec beaucoup plus facile à comprendre que de se demander simplement où sont passés mes actifs.
Un système inter-chaînes ne devrait pas seulement répondre :
« Comment puis-je faire passer mes actifs ? »
Elle devrait aussi répondre :
« Que se passe-t-il pour mes actifs si l’échange ne se termine pas ? »
Cette deuxième question est là où l’architecture commence vraiment à compter.
🌐 STON.fi : app.ston.fi
📝 Blog STON.fi : blog.ston.fi
#STONfi #TON #Omniston #DeFi: #CrossChain $HYPE $TRUMP $G
