Qu'est-ce qui rend Morpher Oracle différent des oracles traditionnels ?

Les blockchains sont des systèmes fermés. Les contrats intelligents sont des programmes qui fonctionnent à l'intérieur de ce cadre. Tant qu'ils n'interagissent qu'entre eux, tout fonctionne bien. Cependant, pour de nombreux cas d'utilisation proposés dans le monde réel, ces programmes ont besoin de données provenant de l'extérieur de la blockchain.

Prenons un exemple : le règlement d'un pari est un exemple célèbre.

Avec les élections américaines de 2024 derrière nous, examinons un contrat intelligent qui a connu un grand succès durant la course présidentielle : Polymarket.

Découvrez Morpher Oracle

Comment fonctionnent les marchés de pari en blockchain

Avec les marchés de pari, vous pouvez parier sur la probabilité d'événements réels. À l'approche des résultats des élections de 2024, il s'agissait d'une course entre Kamala Harris et Donald Trump. Le contrat intelligent fonctionne en permettant aux gens de parier de l'argent sur la victoire ou la défaite de l'un ou de l'autre.

De manière simplifiée : si 10 personnes parient chacune 1 $ sur la victoire de Harris et 5 personnes parient chacune 1 $ sur la défaite de Harris, nous aurions environ 66 % (ou 10 $ / 15 $) sur la victoire de Harris et 33 % sur sa défaite. Vous pourriez acheter le pari que Harris perd pour 0,33 $, et ainsi de suite. C'est un peu plus compliqué que cela, mais voici où interviennent des oracles comme l'oracle Morpher : Comment déterminer, sur la blockchain, qui a gagné ?

Le Problème des Oracles : Qui Fournit des Données Fiables ?

Alors la question est : qui, le cas échéant, a l'autorité d'annoncer sur la blockchain que Trump a gagné ou que Harris a gagné ? Et pourquoi devrions-nous faire confiance à cette personne ou entité ?

Dans le monde réel, c'est simple : il suffit de regarder les nouvelles et d'attendre que les votes soient comptés.

Mais faire entrer ce résultat sur la blockchain est assez complexe.

Parmi d'autres choses, il existe quelques options populaires :

• Vous faites confiance à une seule personne pour annoncer le résultat correct.
• Vous faites confiance à un groupe de personnes et agrégez leurs résultats.
• Vous permettez à quelqu'un de proposer un résultat et laissez les autres contester cette proposition.

La première option est problématique. Dans ce cas, le sort de nombreuses personnes repose entre les mains d'une seule personne. Cela ne fonctionnerait que si cette personne a un intérêt significatif en jeu et peut garantir que le résultat est correct, peut-être en plaçant une caution. Cependant, une fois cela fait, cela se déplace progressivement vers l'option trois, où le résultat n'est qu'une proposition pouvant être contestée.

C'est essentiellement comment fonctionne Polymarket : lorsque un pari se termine et nécessite une résolution, quelqu'un peut proposer un résultat et miser une caution. Si le résultat est contesté par la communauté, la caution peut être réclamée. Si aucune contestation n'a lieu dans un certain délai, le résultat est accepté comme « la vérité », et les paris sont réglés.

Le Défi de la Confiance dans des Communautés Petites ou Inexistantes

Avec Polymarket, ce système fonctionne bien. Tout d'abord, le prix actuel du pari sur une victoire/perte est déterminé par le montant total dépensé de chaque côté. Cela signifie qu'aucune donnée externe n'est nécessaire pour évaluer le pari jusqu'au règlement. De plus, la grande communauté garantit que proposer malicieusement une résolution et éviter les contestations par le contrôle majoritaire n'est pas un problème significatif.

Mais que se passe-t-il s'il n'y a qu'une petite communauté ? Ou pas de communauté du tout, et quelque chose doit être réglé entre seulement deux parties ? À qui faites-vous confiance ?

Comment les données du monde réel atteignent la blockchain

Imaginons que vous soyez une compagnie d'assurance cherchant à régler des sinistres. Vous assurez une chaîne d'approvisionnement pour de la viande fraîche transportée d'Asie vers les États-Unis. Au lieu de compter sur un département pour traiter les réclamations d'assurance, vous mettez en œuvre un « contrat intelligent de réclamation » novateur qui paie automatiquement dès que certains critères sont remplis.

Dans un exemple simple, ce critère pourrait être la défaillance des installations de refroidissement du navire pendant le transport de la viande. Mais comment ces contrats intelligents savent-ils que les installations ont échoué ? Ils ont besoin de données de capteurs.

L'idée est simple : lorsque les capteurs de température dans la chambre de stockage détectent un certain seuil, les marchandises sont considérées comme avariées, et le paiement d'assurance est déclenché. Bien sûr, dans un scénario du monde réel, il y aurait plusieurs capteurs surveillant diverses conditions à l'intérieur et à l'extérieur du produit. Mais pour simplifier, cet exemple se concentre sur le fonctionnement du système.

Comment ces lectures de données de capteurs arrivent-elles sur la blockchain ? Après tout, dans ce cas, il n'y a que deux acteurs, alors qui garantit que les données sont fiables ? Idéalement, aucune des parties ne devrait avoir le contrôle exclusif, c'est là qu'un tiers (ou encore mieux, plusieurs tiers) intervient.

Et si les données ne provenaient pas d'un seul capteur mais d'un réseau entier de capteurs ? Et si plusieurs entreprises étaient impliquées, chacune avec ses propres capteurs et lectures indépendantes ? Plus il y a de sources contribuant aux données, moins le risque de manipulation est élevé, rendant les lectures plus fiables.

Imaginez des milliers d'entreprises intégrant leur propre technologie de capteurs à l'intérieur de conteneurs d'expédition, de produits ou d'emballages, chacune fournissant indépendamment des points de données. Un agrégat de ces lectures serait-il plus digne de confiance ? Cela le serait certainement, beaucoup plus que de compter sur une seule personne prenant une seule lecture à l'intérieur d'un porte-conteneurs et soumettant une seule transaction.

Ce type de données agrégées de capteurs existe déjà aujourd'hui, mais n'a pas encore été intégré à la blockchain.

Cela introduit un autre problème : qui faisons-nous confiance pour agréger ces lectures de capteurs ? Et pouvons-nous également faire confiance à cette personne pour envoyer la transaction mettant à jour la blockchain ?

En pensant quelques étapes en avant, tous les acteurs impliqués doivent être « suffisamment décentralisés » pour créer un environnement de confiance. Plus nous avons de participants indépendants fournissant des données, plus le système devient fiable.

Soumission de données basée sur des seuils : Comment fonctionnent les oracles de type push

Jusqu'à l'invention de l'Oracle Morpher, il y avait deux principales manières de faire entrer des données sur la blockchain.

Revenons à notre exemple avec les lectures de capteurs. Imaginons que le navire parte d'Asie, et qu'une lecture initiale soit effectuée, enregistrant -15°C, marquant le début du voyage. Cette première lecture est entrée avec succès sur la blockchain.

Cependant, nous savons que mettre à jour des valeurs sur la blockchain n'est pas gratuit (du moins pas habituellement). De plus, les blockchains ont une capacité de transaction limitée par seconde. Maintenant, pensez à combien de navires sont en opération à l'échelle mondiale et à la fréquence à laquelle ils pourraient enregistrer des lectures de capteurs, peut-être des dizaines de fois par minute, voire par seconde. Si chaque lecture nécessitait une transaction sur la blockchain, le système deviendrait rapidement submergé.

Une solution potentielle ? N'envoyer une transaction que lorsque un certain seuil est atteint.

C'est exactement ainsi que fonctionnent les oracles de type push, comme Chainlink.

Dans ce cas particulier, nous ne sommes intéressés par une lecture de capteur que si la valeur change de 1 à 2 degrés Celsius. De plus, une transaction de « heartbeat » pourrait être envoyée toutes les 1 à 2 heures si la température reste dans le seuil.

Pour notre contrat intelligent, il récupérerait les lectures de capteurs d'un autre contrat intelligent. Ce contrat continuerait à afficher -15°C jusqu'à ce que la température change de 1 ou 2 degrés, mettant à jour à -13°C, et ainsi de suite. Notre contrat intelligent permettrait alors de faire une réclamation si les lectures de température atteignent +5°C ou plus. Ce processus pourrait être entièrement automatisé, et tant que l'oracle (l'intermédiaire transportant les données) est suffisamment décentralisé, le système reste digne de confiance.

Cependant, c'est là que les choses deviennent délicates. Les oracles de type push peuvent avoir des intervalles de mise à jour lents. Bien que cela puisse fonctionner pour les réclamations d'assurance, où une lecture de capteur déclenche un paiement (semi-)automatique, ce n'est pas aussi efficace pour d'autres cas d'utilisation.

Un de ces cas ? Les informations de prix en temps réel sur la blockchain.

Oracles de type pull : Une nouvelle approche pour les données en temps réel

Pour obtenir des données encore meilleures en temps réel, un autre type d'oracle a émergé : l'oracle de type pull. Dans ce cas, les données sont fournies en dehors de la blockchain, mais d'une manière qui permet de vérifier leur authenticité, même si elles sont envoyées par une partie non fiable.

Cela peut sembler inhabituel au premier abord, mais imaginez que vous écriviez une information importante dans une lettre. Vous placez la lettre dans une enveloppe, la scellez et appliquez un sceau en cire sur le dessus. Ensuite, vous l'envoyez par la poste. Lorsque le destinataire reçoit l'enveloppe, il peut immédiatement savoir si quelqu'un a altéré le contenu rien qu'en regardant le sceau en cire.

Un exemple concret de ce concept est utilisé par certaines entreprises : elles sous-vide un petit colis avec des haricots ou des billes colorées à l'intérieur d'un emballage transparent. Avant de l'envoyer, elles prennent une photo et l'envoient par e-mail au destinataire. À la livraison, vous pouvez comparer le colis à la photo, si les haricots ou les billes sont exactement comme montrés, le colis est intact. Mais si quelqu'un y a touché, il serait presque impossible de remettre tout en ordre exact.

C'est très similaire à la manière dont fonctionnent les oracles de type pull. Vous interrogez un point de données en dehors de la blockchain. Il est signé cryptographiquement (le sceau en cire), puis vous envoyez vous-même ces données au contrat intelligent récepteur. Le contrat intelligent peut alors vérifier la signature cryptographique, garantissant que les données sont authentiques et n'ont pas été altérées.

Cette approche est idéale pour des données quasi en temps réel et est largement utilisée aujourd'hui par des entreprises comme Pyth.

Cependant, cela introduit un autre problème : vous voyez les données avant de les envoyer, ce qui signifie que vous pouvez choisir de les envoyer ou non. Cela pose des problèmes, en particulier pour les plateformes qui permettent une sorte de levier ou de placer de gros paris basés sur des données évoluant progressivement.

Vous, en tant que porteur de nouvelles, pouvez décider de livrer ou non la nouvelle. C'est-à-dire que vous interrogez des données à l'épreuve de la falsification, mais vous pouvez toujours choisir de les envoyer ou non. Les données sont visibles et clairement lisibles avant soumission.

Cela soulève deux grands problèmes :

• Premièrement, bien que les données elles-mêmes, si elles sont envoyées, puissent être fiables, il n'y a aucune garantie que les données seront envoyées si le résultat est défavorable à un éventuel contrepartie.
• Deuxièmement, cela introduit des problèmes potentiels de licence de données, car les données doivent être visibles avant d'être réglées sur la blockchain.

C'est ici que l'Oracle Morpher introduit une nouvelle approche de l'architecture des oracles. C'est un oracle basé sur l'intention, représentant un saut en avant par rapport au modèle basé sur le pull.

Morpher Oracle : Une nouvelle solution pour les flux de données blockchain

Avec le Morpher Oracle, l'utilisateur n'est pas responsable de l'envoi d'une transaction mais envoie plutôt une intention d'envoyer une transaction. Cela inverse le mécanisme des oracles de tirage :

• L'utilisateur place sa transaction dans une enveloppe, la scelle avec un sceau de cire et la remet à l'oracle.
• L'oracle ne peut pas altérer le contenu de l'enveloppe.
• L'oracle n'a aucun intérêt à retenir la transaction, car il est payé pour l'envoyer.
• L'oracle constate que l'utilisateur a besoin d'informations à jour et peut ajouter un point de données fiable au-dessus de la lettre de l'utilisateur.

Il s'agit essentiellement de mettre la lettre de l'utilisateur dans sa propre enveloppe et de soumettre le tout à la blockchain.

Avec cela, l'utilisateur est assuré que sa transaction est envoyée. Le contrat intelligent garantit que les informations sont à jour et signées de manière cryptographique, similaire aux oracles de tirage. Mais la contrepartie a également des garanties que la transaction est soumise, même si le point de données de l'oracle est défavorable à l'utilisateur, c'est un jeu équitable.

De plus, les données ne peuvent pas être siphonnées en masse, ce qui empêche les problèmes de licence auxquels font face les oracles de tirage traditionnels.

Rejoignez le groupe Telegram de Morpher Oracle pour en savoir plus.

Morpher Oracle garantit des flux de données en temps réel, inviolables, sans manipulation ni délais—garantissant des transactions équitables et sans confiance sur la chaîne. Testez-le maintenant sur BNB et Radix.

Avertissement : Tous les investissements comportent des risques et les performances passées d'un titre, d'un secteur, d'un marché, d'un produit financier, d'une stratégie de trading ou des transactions d'un individu ne garantissent pas les résultats ou les rendements futurs. Les investisseurs sont entièrement responsables de toutes les décisions d'investissement qu'ils prennent. Ces décisions doivent être basées uniquement sur une évaluation de leur situation financière, de leurs objectifs d'investissement, de leur tolérance au risque et de leurs besoins en liquidités. Ce post ne constitue pas un conseil en investissement.