Je pense que la conception cross-chain est mal comprise parce que les gens se concentrent souvent sur la vitesse et les frais, tout en ignorant où le risque réside réellement.
La plupart des ponts reposent sur de la liquidité qui se trouve quelque part et attend pour faciliter les transferts. Cela fonctionne jusqu’au moment où la liquidité devient rare, fragmentée, ou dépendante d’un petit ensemble d’acteurs agissant comme prévu.
Le modèle CCT de Dusk emprunte une voie différente. Au lieu de passer par un pool, l’actif est retiré de la circulation sur une chaîne et recréé sur une autre via un processus de burn-and-mint.
Le compromis est intéressant.
Vous ne dépendez pas de la liquidité disponible et vous ne vous souciez pas du slippage. Mais cela ne rend pas le système exempt de risques. L’hypothèse critique se déplace : il s’agit de savoir si l’événement de destruction (burn) est correctement vérifié et si le processus de création (mint) s’exécute comme prévu entre les chaînes.
Autrement dit, la question n’est plus « Y a-t-il suffisamment de capital de l’autre côté ? »
Elle devient « Le système peut-il prouver avec certitude que l’offre a été détruite avant que la nouvelle offre n’apparaisse ailleurs ? »
Cela ressemble moins à un problème de liquidité et davantage à un problème de coordination et de finalité.
Je suis curieux de la façon dont Dusk gère les cas limites où un côté atteint la confirmation finale, mais où le mint correspondant reste retardé ou interrompu.
#dusk @Dusk $DUSK
La plupart des ponts reposent sur de la liquidité qui se trouve quelque part et attend pour faciliter les transferts. Cela fonctionne jusqu’au moment où la liquidité devient rare, fragmentée, ou dépendante d’un petit ensemble d’acteurs agissant comme prévu.
Le modèle CCT de Dusk emprunte une voie différente. Au lieu de passer par un pool, l’actif est retiré de la circulation sur une chaîne et recréé sur une autre via un processus de burn-and-mint.
Le compromis est intéressant.
Vous ne dépendez pas de la liquidité disponible et vous ne vous souciez pas du slippage. Mais cela ne rend pas le système exempt de risques. L’hypothèse critique se déplace : il s’agit de savoir si l’événement de destruction (burn) est correctement vérifié et si le processus de création (mint) s’exécute comme prévu entre les chaînes.
Autrement dit, la question n’est plus « Y a-t-il suffisamment de capital de l’autre côté ? »
Elle devient « Le système peut-il prouver avec certitude que l’offre a été détruite avant que la nouvelle offre n’apparaisse ailleurs ? »
Cela ressemble moins à un problème de liquidité et davantage à un problème de coordination et de finalité.
Je suis curieux de la façon dont Dusk gère les cas limites où un côté atteint la confirmation finale, mais où le mint correspondant reste retardé ou interrompu.
#dusk @Dusk $DUSK