Source de l'article : On-Chain View
Récemment, ce projet AltVMs Catalyst, dont le style UI semble être très MEME, a été lancé sur le réseau principal, mais en consultant la documentation technique officielle, il s'avère que ce n'est pas simple. Il s'agit d'une solution de liquidité multichaîne connectant EVM, SVM, MoveVM et le réseau BTC, appartenant à la catégorie des transactions basées sur l'intention. Comment comprendre cela ? Je résume quelques points forts :
1) Les projets de transactions basées sur l'intention ne se concentrent pas trop sur la complexité technique de "l'inter-chaîne", mais se soucient davantage de l'exécution des ordres d'intention inter-chaînes et de la réalisation des résultats. Les utilisateurs initient des ordres sur la "chaîne source", le Solver exécute les ordres en fonction de la description de l'ordre, et tant que la chaîne distante peut vérifier / prouver la validité de la transaction, elle peut être incluse dans l'échange d'ordres.
Ainsi, bien que ces projets appartiennent à la catégorie "abstraction de chaîne" en raison de leurs caractéristiques d'agrégation de liquidité, il serait plus approprié de définir Catalyst comme un système de trading automatique AMM inter-chaînes.
2) CrossCats est le dernier produit de pont inter-chaînes lancé par Catalyst, capable de connecter divers clients homogènes ou hétérogènes (altVMs), et suit uniquement une logique de "prouvabilité". Les transactions d'intention inter-chaînes courantes comprennent principalement :
Les transactions entre chaînes EVM, par exemple de Ethereum à Base, sont entièrement gérées par le système de contrat, l'utilisateur signe l'ordre de transaction -> Solver réclame l'ordre et fournit des garanties -> la chaîne source verrouille les actifs autorisés par l'utilisateur -> le Solver exécute la commande sur la chaîne cible via le contrat oracle -> après l'exécution, les actifs verrouillés de l'utilisateur sont libérés et réglés.
Les transactions de chaîne EVM vers d'autres chaînes VM (SVM, MoveVM, etc.) relèvent également de l'exécution automatique de contrats intelligents entre chaînes homogènes, mais nécessitent la mise en place d'un mécanisme de validation prouvable sur une chaîne non EVM, avec un oracle et un contrat de validation correspondants. Les logiques de signature, de verrouillage, d'exécution et de règlement des autres ordres sont similaires à celles des transactions entre chaînes EVM.
Les transactions entre Bitcoin et les chaînes VM, par exemple de Bitcoin à Ethereum ou Solana, nécessitent une solution de traitement de type Pseudo Solver car Bitcoin ne peut pas gérer les contrats intelligents. L'utilisateur commence par recueillir des ordres inverses fournis par de véritables Solvers -> le véritable Solver signe cet ordre inverse -> l'utilisateur réclame l'ordre et obtient des actifs sur la chaîne VM -> l'utilisateur initie une transaction de transfert à une adresse spécifique dans un délai imparti -> la vérification de l'état est complétée par le biais d'un client léger SPV Bitcoin, complétant ainsi l'ensemble du processus de transaction.
Il est plus simple d'avoir le même environnement de traitement de machine virtuelle entre les chaînes EVM, tandis que d'autres chaînes homogènes supportant les contrats intelligents nécessitent un mécanisme spécifique de preuve inter-chaînes, ce qui est plus complexe, notamment pour les transactions impliquant Bitcoin, qui nécessitent une logique de validation par client SPV, avec un traitement spécial à chaque étape, comme les oracles et le verrouillage des actifs.
3) Après l'exécution de l'appariement des commandes de transaction basée sur un mécanisme prouvable, il faut considérer la question de l'efficacité d'utilisation des fonds, le partage des mécanismes de gestion, l'optimisation des oracles, etc.
Par exemple, les règles de verrouillage et de libération des fonds affectent directement l'efficacité des fonds. CrossCats permet aux utilisateurs de ne pas avoir à verrouiller les fonds de liquidité à l'avance, mais de verrouiller brièvement les actifs uniquement au cours du processus de transaction réel (minimiser le verrouillage), afin de ne pas sacrifier l'efficacité d'utilisation des fonds autant que possible.
Par exemple, CrossCats a conçu un plan de libération de paiement à plusieurs niveaux pour équilibrer efficacité et risque. De plus, il utilise trois plans de libération : paiement optimiste de la chaîne source, validation de la chaîne cible et mécanisme de souscription.
Le paiement optimiste suppose que l'état de la transaction est normal, libère d'abord des fonds, puis utilise une forme de pré-garantie d'actifs et de fenêtre de contestation pour assurer la sécurité ; la validation de la chaîne cible exige que la chaîne distante fournisse une preuve à la chaîne source ; le mécanisme de souscription transfère une partie de la responsabilité des ordres à d'autres participants pour améliorer l'efficacité de l'appariement.
Voilà.
Comme je l'ai dit dans un commentaire précédent sur le retournement des sanctions de Tornado, avec la résolution des solutions de confidentialité en chaîne, les transactions basées sur l'intention auront un potentiel de croissance rapide dans une nouvelle catégorie narrative.
Dans ce processus, la réalisation de la circulation des actifs inter-chaînes n'est qu'une base. Comment optimiser la perte et l'efficacité des transactions inter-chaînes d'actifs, comment résister aux problèmes de temporalité des prix des oracles face aux fluctuations du marché, et comment enrichir la logique d'exécution des transactions pour améliorer l'expérience d'automatisation, ce sont autant de défis que les transactions basées sur l'intention doivent relever.