Chainlink (LINK) : comment fonctionnent les oracles et les flux de données

Une décision data-dependency

Un contrat intelligent peut vérifier son propre état de chaîne mais ne peut pas connaître indépendamment un prix d'échange, une preuve d'un autre système ou un événement hors chaîne. Les services Chainlink comblent cette frontière en coordonnant les sources de données, les opérateurs de nœuds et les contrats en chaîne qui publient ou livrent des résultats.

Les développeurs ne doivent utiliser un service que lorsque sa politique de mise à jour, le support réseau, la qualité des données et le comportement en cas de défaillance correspondent à l'application. Les utilisateurs finaux doivent identifier quelle fonction de l'application dépend du flux, au lieu de supposer que le nom Chainlink rend l'ensemble de l'application sûr.

Ce que l'utilisateur fait vraiment confiance

Un marché de prêt peut dépendre d'un flux de prix pour l'évaluation des garanties ; un lieu de produits dérivés peut dépendre de données de marché à faible latence ; une action inter-chaînes peut dépendre de composants de messagerie et d'exécution. Chaque dépendance a un modèle opérationnel et économique différent.

La vérification utile est spécifique au service : adresse du flux, chaîne prise en charge, logique de battement ou d'écart, fraîcheur des données, comportement de repli et conséquence si les mises à jour cessent.

• Identifiez le service exact.
• Vérifiez l'adresse officielle du contrat ou du flux.
• Définissez le comportement en cas de données obsolètes et de panne.
• Traitez le risque de l'application séparément du risque de l'oracle.

Les faits externes ne peuvent pas être lus directement

Un contrat ne peut pas effectuer une requête web ordinaire et traiter la réponse comme un consensus. Les réseaux d'oracles collectent et agrègent des observations via un processus défini, puis mettent un rapport à la disposition des contrats. Cela donne aux applications une entrée partagée sans faire confiance à un appel de site web de l'utilisateur.

Le compromis est une dépendance supplémentaire. La couverture des sources de données, la participation des nœuds, les règles d'agrégation, le coût de transmission et le calendrier des mises à jour comptent tous. Décentraliser la livraison réduit la dépendance à un seul opérateur mais ne rend pas un marché faible ou un événement ambigu objectivement correct.

Les services résolvent différentes frontières

Les flux de données publient des valeurs utilisées par les applications on-chain. L'automatisation peut déclencher un travail de contrat éligible dans des conditions définies. La messagerie inter-chaînes coordonne le mouvement d'état ou de jetons entre les réseaux pris en charge. Les services orientés preuve peuvent attester d'informations externes spécifiques.

Ces produits ne doivent pas être regroupés en une seule revendication d'oracle générique. L'architecture d'une application détermine quel service est pertinent et quel mode de défaillance doit être géré.

Observer, agréger, rapporter et consommer

Les fournisseurs de données et les sources de marché produisent des observations. Les opérateurs de nœuds indépendants récupèrent et rapportent selon la configuration du réseau. Le réseau d'oracles agrège les rapports, et un contrat en chaîne stocke ou vérifie le résultat. Une application consommatrice lit ce contrat et applique ses propres règles métier.

Les développeurs doivent vérifier l'adresse du flux pour le réseau cible et contrôler les données des rounds, les horodatages et les recommandations spécifiques au service. Une réponse d'oracle valide peut néanmoins être dangereuse pour une application si le développeur accepte des données obsolètes ou utilise un flux à des fins non prises en charge.

• Sélectionnez le flux ou le service pris en charge.
• Vérifiez le réseau et l'adresse du contrat.
• Lisez la valeur et mettez à jour les métadonnées.
• Rejetez les états d'application obsolètes ou invalides.
• Surveillez le comportement du service et de l'application.

Les utilisateurs rencontrent la dépendance indirectement

La plupart des utilisateurs n'envoient pas de transactions à un flux de prix. Ils interagissent avec une application de prêt, de trading ou de stable-asset dont les contrats s'appuient sur celui-ci. Un rapport retardé ou anormal peut modifier la capacité d'emprunt, la liquidation, le règlement ou le comportement de frappe selon le code de cette application.

C'est pourquoi un logo d'oracle devrait mener à une question de dépendance, et non à une conclusion de sécurité générale.

Paiements de services et incitations de sécurité

LINK est utilisé dans l'économie de Chainlink pour les paiements de services et, là où c'est pris en charge, pour le staking ou la participation à la sécurité. Les arrangements de paiement exacts diffèrent selon le service et le déploiement, donc une déclaration générale sur le jeton ne doit pas remplacer la documentation pour un flux, un travail d'automatisation ou une intégration inter-chaînes particulier.

Les opérateurs de nœuds et les participants de l'écosystème évaluent les coûts, les récompenses et les exigences selon le service concerné. Détenir LINK seul ne fait pas d'une adresse un opérateur de nœud et ne crée pas une part automatique de chaque paiement de service.

Ce que LINK ne représente pas

LINK ne représente pas une participation dans une entreprise Chainlink, la propriété d'applications clientes ou une garantie que les données externes sont correctes. Il ne paie pas non plus le gaz normal pour une transaction d'application Ethereum ou Solana de l'utilisateur ; l'actif de frais du réseau d'exécution reste nécessaire.

L'évaluation du jeton doit donc distinguer l'adoption du réseau, l'économie des services et les conditions de staking de la sécurité d'une application individuelle.

Modes de défaillance des données et de l'intégration

Un marché peut devenir illiquide ou désordonné même lorsque le réseau de reporting fonctionne comme prévu. Les nœuds ou les chemins de transmission peuvent être retardés. Un développeur peut utiliser le mauvais flux, ignorer les horodatages, supposer qu'une convention de cotation correspond à une autre, ou ne pas suspendre une action lorsque les mises à jour deviennent obsolètes.

Les services inter-chaînes ajoutent des dépendances de chaîne source, de chaîne de destination et d'exécution de messages. L'automatisation ajoute des exigences d'éligibilité, de financement et de configuration de travail. Ces risques appartiennent au modèle de menace de l'application consommatrice.

• Qualité du marché source
• Fraîcheur du flux et comportement de déviation
• Erreurs d'adresse de contrat et de décimales
• Logique de repli de l'application
• Congestion économique et du réseau

Malentendus à éviter

La livraison décentralisée d'oracles ne signifie pas que chaque entrée est exempte d'hypothèses. Le but d'un flux, sa couverture de marché et sa politique de mise à jour restent spécifiques. Une autre erreur est de traiter l'utilisation de Chainlink par un protocole comme un audit de contrats intelligents ou d'économies de jetons non liés.

Les utilisateurs devraient lire les divulgations de risques de l'application elle-même en plus de la documentation de l'oracle.

Les développeurs devraient définir une réponse pour les valeurs obsolètes, manquantes ou invraisemblables avant le déploiement. Des contrôles utiles peuvent inclure des vérifications de fraîcheur, des limites, des disjoncteurs et un mode de repli délibérément limité. Le contrôle correct dépend de ce que l'application fera avec le rapport ; un widget d'affichage et un moteur de liquidation n'ont pas le même coût de défaillance.

Ce que les utilisateurs de Chainlink doivent vérifier et pourquoi cette conception diffère

Chainlink fournit plusieurs services d'oracle et d'interopérabilité sur les réseaux pris en charge. Pyth met l'accent sur les données de marché provenant des éditeurs et un modèle de mise à jour utilisé par de nombreuses applications de trading. Les deux peuvent se chevaucher dans les cas d'utilisation de données de prix tout en différant dans la livraison, le coût et les hypothèses d'intégration.

Les développeurs doivent comparer le flux exact, la politique de mise à jour et la gestion des pannes. Les utilisateurs peuvent ensuite examiner le réseau hôte et l'application qui consomme les données.