En général, quand on regarde des ponts inter-chaînes, on a toujours les yeux rivés sur l’argent : est-ce que les fonds sont arrivés ? Mais, en réalité, sur un pont, ce qui circule, c’est vraiment deux choses : l’argent et… les messages. L’argent peut être vérifié : solde, confirmations, et il n’en manque pas un centime sans que l’on puisse le constater. En revanche, cette phrase envoyée via le pont — le « message » — est-elle bien arrivée exactement où il fallait ? Est-ce qu’elle a pu être interceptée puis rejouée une seconde fois ? Les personnes concernées se posent étrangement moins souvent ces questions.
Sur le schéma de l’architecture du @Dusk , c’est indiqué très clairement : Bridge transfère deux catégories de choses en même temps, DUSK et les messages. Le premier a des garanties sur la chaîne : du gas, un solde, des confirmations. C’est comme une voie avec un prix affiché, au centime près. Le second ressemble plutôt à un petit chemin sur le pont, qui ne fait pas l’objet d’une tarification séparée : dès qu’il y a un problème, on ne sait même plus à qui s’adresser.
Dans ce système, le rôle de DUSK n’a pas besoin d’être longuement expliqué : la couche d’exécution le consomme, et il faut aussi qu’il serve aux allers-retours entre L1 et DuskEVM. À chaque mouvement — transactions, règlement, appels de contrats — il faut dépenser $DUSK , donc sa valeur peut se traduire par le débit (throughput). Mais les messages ne sont pas des tokens. Ils peuvent correspondre à des appels inter-chaînes, des autorisations, des changements d’état, ou à une forme d’instructions qui doit être exécutée dans un ordre précis.
Dans la documentation, on ne reconnaît vraiment que la manière dont un contrat Dusk identifie l’appelant, et cela est différent de ce qui se fait sur Ethereum. Le pontage côté sémantique et la « collecte de valeur » doivent être spécialisés pour Dusk, mais tout ce qui concerne l’acheminement des messages — garanties de livraison, protection contre le rejeu, règles d’ordonnancement, chemins d’échec — n’est presque jamais développé. Et réfléchissez : dans la finance régulée, c’est précisément la zone aveugle la plus dangereuse. Un virement d’argent envoyé par erreur peut encore être renvoyé. Mais si une instruction est exécutée discrètement deux fois, sans que personne ne s’en rende compte, la responsabilité ne peut plus être « remontée en arrière ».
N’est-ce pas justement le genre de point à rendre plus scrupuleux que les actifs ? Dit autrement : DUSK paie pour la voie « argent », mais ne peut pas garantir automatiquement la voie « messages ». Les détenteurs de tokens achètent du calcul réseau, pas la responsabilité de la compensation liée au messagerie de pontage. Si ça déraille, il faudra peut-être que l’application, l’utilisateur, ou un malheureux particulier absorbe l’erreur du pont : le gas de DUSK ne deviendra pas, par magie, une promesse d’indemnisation. #dusk
De mon point de vue, en regardant les choses de près, les véritables « mines » d’un système inter-chaînes ne se trouvent souvent pas dans la jambe des actifs, mais dans la jambe des messages. Les actifs ont un prix ; les messages, eux, n’ont que l’ordre et les permissions. Le premier peut être surveillé ; le second, s’il se mélange ou se désordonne, devient une violation d’accord (défaut) impossible à attribuer, même pour la partie adverse.
DYOR : faites vos propres recherches et votre propre travail de fond. Ne vous contentez pas d’écouter ce que je dis avec ma seule bouche.
Sur le schéma de l’architecture du @Dusk , c’est indiqué très clairement : Bridge transfère deux catégories de choses en même temps, DUSK et les messages. Le premier a des garanties sur la chaîne : du gas, un solde, des confirmations. C’est comme une voie avec un prix affiché, au centime près. Le second ressemble plutôt à un petit chemin sur le pont, qui ne fait pas l’objet d’une tarification séparée : dès qu’il y a un problème, on ne sait même plus à qui s’adresser.
Dans ce système, le rôle de DUSK n’a pas besoin d’être longuement expliqué : la couche d’exécution le consomme, et il faut aussi qu’il serve aux allers-retours entre L1 et DuskEVM. À chaque mouvement — transactions, règlement, appels de contrats — il faut dépenser $DUSK , donc sa valeur peut se traduire par le débit (throughput). Mais les messages ne sont pas des tokens. Ils peuvent correspondre à des appels inter-chaînes, des autorisations, des changements d’état, ou à une forme d’instructions qui doit être exécutée dans un ordre précis.
Dans la documentation, on ne reconnaît vraiment que la manière dont un contrat Dusk identifie l’appelant, et cela est différent de ce qui se fait sur Ethereum. Le pontage côté sémantique et la « collecte de valeur » doivent être spécialisés pour Dusk, mais tout ce qui concerne l’acheminement des messages — garanties de livraison, protection contre le rejeu, règles d’ordonnancement, chemins d’échec — n’est presque jamais développé. Et réfléchissez : dans la finance régulée, c’est précisément la zone aveugle la plus dangereuse. Un virement d’argent envoyé par erreur peut encore être renvoyé. Mais si une instruction est exécutée discrètement deux fois, sans que personne ne s’en rende compte, la responsabilité ne peut plus être « remontée en arrière ».
N’est-ce pas justement le genre de point à rendre plus scrupuleux que les actifs ? Dit autrement : DUSK paie pour la voie « argent », mais ne peut pas garantir automatiquement la voie « messages ». Les détenteurs de tokens achètent du calcul réseau, pas la responsabilité de la compensation liée au messagerie de pontage. Si ça déraille, il faudra peut-être que l’application, l’utilisateur, ou un malheureux particulier absorbe l’erreur du pont : le gas de DUSK ne deviendra pas, par magie, une promesse d’indemnisation. #dusk
De mon point de vue, en regardant les choses de près, les véritables « mines » d’un système inter-chaînes ne se trouvent souvent pas dans la jambe des actifs, mais dans la jambe des messages. Les actifs ont un prix ; les messages, eux, n’ont que l’ordre et les permissions. Le premier peut être surveillé ; le second, s’il se mélange ou se désordonne, devient une violation d’accord (défaut) impossible à attribuer, même pour la partie adverse.
DYOR : faites vos propres recherches et votre propre travail de fond. Ne vous contentez pas d’écouter ce que je dis avec ma seule bouche.
