La coopération avec Chainlink doit être découpée en trois éléments différents
Dans les annonces de partenariat, on voit souvent apparaître Chainlink. Beaucoup de gens traduisent alors directement cela par « Dusk dispose désormais d’un oracle ». Mais CCIP, DataLink et Data Streams ne résolvent pas le même problème. Les regrouper sous un seul logo, c’est manquer l’endroit précis où ce partenariat touche réellement les flux d’actifs réglementés.
DataLink s’adresse à la diffusion de données côté institutions : l’objectif est d’apporter des données financières existantes à la blockchain de manière vérifiable ; Data Streams est plus proche de la livraison de données à faible latence et convient aux applications qui doivent mettre à jour rapidement les prix ou l’état du marché ; CCIP gère quant à lui les messages et les transferts d’actifs entre chaînes, permettant à l’émetteur de configurer des chemins de connexion entre plusieurs réseaux. L’un s’occupe de la source des données, l’autre de la fraîcheur, le troisième de la communication inter-chaînes : si l’un des trois manque, les deux autres ne peuvent pas le compenser automatiquement.
Pour l’émetteur, le plus critique n’est pas « est-ce que c’est inter-chaînes », mais « vers où », « combien on peut transférer à chaque fois », « en cas d’anomalie, qui peut mettre en pause », et « qui contrôle la mise à niveau du contrat ». Les documents officiels mentionnent des limites de débit et un contrôle des mises à jour : ces réglages apparemment prudents sont en réalité des dispositifs de sécurité dont les institutions ont besoin. Quand des données erronées, une congestion de la chaîne cible ou un risque lié aux clés surviennent, le système doit pouvoir limiter l’impact, plutôt que continuer à exécuter sans conditions.
Le service de données doit aussi répondre à la question du temps. À quel moment la valorisation des titres est-elle calculée ? Si les données sources arrivent en retard, faut-il utiliser la valeur précédente ou suspendre les transactions ? Que faire des ordres déjà exécutés après correction des données ? Tout cela ne peut pas être décidé automatiquement par le simple fait que « l’oracle est connecté ». L’application Dusk doit intégrer, dans ses règles, le horodatage des données, la fréquence de mise à jour et les seuils d’invalidité, afin de savoir quand il est possible de continuer à exécuter.
Je vais classer les avancées de @Dusk avec Chainlink selon la force des preuves : signer un partenariat n’est qu’un signal faible ; le fait que le service soit utilisable dans un environnement de test constitue un signal plus fort ; et la dépendance d’actifs réels à ces données ou à des messages inter-chaînes pour effectuer la compensation, c’est la preuve directe. La prochaine chose qui mérite d’être rendue publique n’est donc pas un nom de plus pour un partenariat, mais d’où proviennent les données d’une transaction, quand elles sont mises à jour, comment gérer l’échec inter-chaînes et finalement qui confirme le tout. Tant que cette chaîne de preuves est complète, Chainlink pourra passer de simple liste d’infrastructure à une partie du workflow de marché de Dusk. $DUSK #dusk
Dans les annonces de partenariat, on voit souvent apparaître Chainlink. Beaucoup de gens traduisent alors directement cela par « Dusk dispose désormais d’un oracle ». Mais CCIP, DataLink et Data Streams ne résolvent pas le même problème. Les regrouper sous un seul logo, c’est manquer l’endroit précis où ce partenariat touche réellement les flux d’actifs réglementés.
DataLink s’adresse à la diffusion de données côté institutions : l’objectif est d’apporter des données financières existantes à la blockchain de manière vérifiable ; Data Streams est plus proche de la livraison de données à faible latence et convient aux applications qui doivent mettre à jour rapidement les prix ou l’état du marché ; CCIP gère quant à lui les messages et les transferts d’actifs entre chaînes, permettant à l’émetteur de configurer des chemins de connexion entre plusieurs réseaux. L’un s’occupe de la source des données, l’autre de la fraîcheur, le troisième de la communication inter-chaînes : si l’un des trois manque, les deux autres ne peuvent pas le compenser automatiquement.
Pour l’émetteur, le plus critique n’est pas « est-ce que c’est inter-chaînes », mais « vers où », « combien on peut transférer à chaque fois », « en cas d’anomalie, qui peut mettre en pause », et « qui contrôle la mise à niveau du contrat ». Les documents officiels mentionnent des limites de débit et un contrôle des mises à jour : ces réglages apparemment prudents sont en réalité des dispositifs de sécurité dont les institutions ont besoin. Quand des données erronées, une congestion de la chaîne cible ou un risque lié aux clés surviennent, le système doit pouvoir limiter l’impact, plutôt que continuer à exécuter sans conditions.
Le service de données doit aussi répondre à la question du temps. À quel moment la valorisation des titres est-elle calculée ? Si les données sources arrivent en retard, faut-il utiliser la valeur précédente ou suspendre les transactions ? Que faire des ordres déjà exécutés après correction des données ? Tout cela ne peut pas être décidé automatiquement par le simple fait que « l’oracle est connecté ». L’application Dusk doit intégrer, dans ses règles, le horodatage des données, la fréquence de mise à jour et les seuils d’invalidité, afin de savoir quand il est possible de continuer à exécuter.
Je vais classer les avancées de @Dusk avec Chainlink selon la force des preuves : signer un partenariat n’est qu’un signal faible ; le fait que le service soit utilisable dans un environnement de test constitue un signal plus fort ; et la dépendance d’actifs réels à ces données ou à des messages inter-chaînes pour effectuer la compensation, c’est la preuve directe. La prochaine chose qui mérite d’être rendue publique n’est donc pas un nom de plus pour un partenariat, mais d’où proviennent les données d’une transaction, quand elles sont mises à jour, comment gérer l’échec inter-chaînes et finalement qui confirme le tout. Tant que cette chaîne de preuves est complète, Chainlink pourra passer de simple liste d’infrastructure à une partie du workflow de marché de Dusk. $DUSK #dusk