Messages inter-chaînes : comparez la vérification, la livraison et l'exécution
Une application cross-chain peut présenter une seule action tout en s'appuyant sur plusieurs systèmes distincts. Un message doit être reconnu sur la chaîne source, vérifié selon un modèle de sécurité déclaré, livré et accepté par la logique de destination. Appeler l’ensemble du processus « un transfert de pont » peut cacher les changements dans ses hypothèses.
La comparaison pratique ne consiste pas à déterminer quel système a le temps de transfert annoncé le plus court. Il s'agit de savoir quelles preuves la destination accepte, qui peut modifier cette règle et ce qui se passe lorsqu'une étape est retardée ou contestée.
Séparez les étapes d'une instruction
Considérons une instruction hypothétique visant à reconnaître un dépôt sur la chaîne A et à libérer un solde d'application sur la chaîne B. La transaction source incluse ne prouve pas, en elle-même, que l'action de destination est terminée.
Suivez quatre états : l'événement source et sa finalité, le résultat de la vérification, la livraison du message et l'exécution de la destination. Un composant de livraison peut transmettre des informations sans décider si elles sont valides. À l’inverse, un message vérifié peut toujours échouer dans son exécution si le contrat de destination rejette ses entrées ou ne dispose pas des ressources requises.
Cet exemple décrit un modèle de recherche, et non l'architecture de chaque protocole ou une fonctionnalité OrangeX actuellement proposée.
Demandez ce que le vérificateur prouve
Documentation des ponts d'Ethereum décrit les ponts qui déplacent les jetons, les messages et les données, et distingue les conceptions vérifiées en externe des approches reposant sur des chaînes connectées. Lisez l'implémentation spécifique plutôt que de traiter l'une ou l'autre étiquette comme une garantie de sécurité complète.
Pour un ensemble de vérificateurs externes, étudiez l’adhésion, les règles de seuil, l’indépendance et les compromis clés. Pour une approche basée sur des preuves, identifiez ce qui est prouvé, quelles hypothèses consensuelles subsistent et comment le logiciel de vérification peut être mis à niveau. Les preuves cryptographiques ne suppriment pas tous les risques contractuels, opérationnels ou de gouvernance.
Traitez la latence et la finalité séparément
Une candidature peut afficher des progrès provisoires avant que les conditions de finalité ou de défi pertinentes ne soient remplies. Demandez si le délai annoncé fait référence à l'observation, à la livraison, à la liquidité des utilisateurs ou au règlement final. Ces jalons peuvent différer.
Ne comparez pas deux chiffres de latence à moins que l'événement de départ, l'événement de fin et les conditions de sécurité correspondent. Une reconnaissance plus rapide ne signifie pas automatiquement une finalité plus forte. Un itinéraire interrompu peut également être une réponse délibérée à l’incertitude plutôt qu’une preuve de la disparition de la transaction source.
Examiner les tentatives et l'autorité de destination
Une action de destination échouée soulève une deuxième série de questions : peut-elle être réessayée, qui peut la réessayer, quels frais s'appliquent et qu'est-ce qui empêche que la même instruction soit exécutée deux fois ? Lisez les identifiants documentés du protocole et les protections contre la relecture plutôt que de supposer qu'une deuxième soumission est sûre.
Vérifiez les clés de mise à niveau, les pauses d'urgence, la configuration de l'itinéraire et les autorisations au niveau de l'application. Une couche de messagerie sécurisée ne peut pas émettre le son d'une application de destination dangereuse. De même, une interface réputée ne prouve pas que toutes les routes prises en charge partagent un même modèle de confiance.
Tenir un dossier de recherche spécifique à un itinéraire
Enregistrez les chaînes exactes, les contrats, la représentation des actifs, le modèle de sécurité, les hypothèses de finalité et la procédure de récupération pour l'itinéraire évalué. Utilisez la documentation officielle actuelle et distinguez les contrôles mis en œuvre des plans futurs.
Un dépôt d'échange est un flux de travail distinct d'un message d'application inter-chaînes arbitraire. Avant d'envoyer sur OrangeX.com, suivez les instructions de réseau et d'adresse indiquées dans l'interface de dépôt. Ne présumez pas qu’une opération de pont réussie rend acceptable un réseau de destination non pris en charge.
