Le potentiel d’Ethereum se réalisera (ou non) par l’usage qui sera fait des « smart-contracts », programmes informatiques qui s’exécutent de façon décentralisée et qui apportent au protocole une polyvalence inégalée. Pour la mise en oeuvre de nombreux cas d’usages, le smart-contract doit cependant pouvoir s’exécuter en fonction de données existantes à l’extérieur de la blockchain : qui a gagné ce match, quel est le cours EUR/USD à un instant T, quel temps fait-il, le verrou électronique est-il ouvert, etc. Or, ces données ne sont pas accessibles sur une blockchain, qui ne peut pas, par construction, récupérer directement l’information sur une source de données externes. Pour ces points de contact entre la blockchain et le monde réel, le concept d’Oracle a été inventé.

La blockchain est aveugle au monde extérieur

La technologie couramment appelée « blockchain » ne permet pas la collecte de données depuis une source externe, et Ethereum n’y fait pas exception. C’est le fonctionnement même de la blockchain qui y fait obstacle. En effet, chaque participant à la blockchain doit pouvoir reconstituer à n’importe quel moment les différentes transactions qui s’y sont déroulées afin d’en vérifier l’intégrité. Pour cela, chaque bloc de transactions est lié au suivant par son empreinte ou hash, qui permet d’établir la continuité de la blockchain.

Que se passe-il si le protocole d’une blockchain fait appel à un service extérieur ? L’une des transactions d’un bloc X sera dépendante du contenu de ce service externe. A chaque fois qu’une personne téléchargera la blockchain, un nouvel appel sera effectué à ce service externe, ce qui pose déjà un problème de charge pour ce service. Mais le vrai souci se pose si ledit service n’offre plus la donnée (il est hors ligne, piraté, etc.) ou si il répond avec une autre donnée : le bloc X ne peux pas se résoudre de la même façon que la première fois. Son contenu et donc son empreinte n’est plus identique, et le lien entre lui et le bloc X+1 n’est plus valide. Il en est de même pour les suivants. Cela peut se produire six mois, un an, dix ans après la validation du bloc X. L’ensemble de la blockchain créée après ce bloc ne peut alors plus être vérifiée et l’immutabilité de la blockchain est remise en cause.

Pour cette raison, aucune fonction d’Ethereum ou d’aucune autre blockchain ne permet de faire appel à un service extérieur. La blockchain est donc par construction aveugle au monde extérieur.

L’Oracle éclaire la blockchain de son savoir

L’Oracle, c’est un service chargé d’entrer manuellement une donnée extérieure dans la blockchain. A l’instant T, qui aura été défini à l’avance, le service va récupérer l’information qui lui a été demandée et l’insère dans la blockchain à l’endroit qui lui a été désigné. Lorsque le smart-contract qui requiert cette donnée s’exécute (après l’instant T), il va chercher la donnée sur la blockchain, à l’adresse prévue, et s’exécute en fonction de cette donnée.

Par exemple, l’Oracle a entré à minuit, le 8 juillet 2016 à l’adresse 0x3615087316813abba… que la France a gagné 2-0 contre l’Allemagne à l’Euro. Lors de son exécution le 9 juillet, le smart-contract de pari qui fait appel à cette information en déduit que le parieur A a perdu car il avait envoyé une transaction pariant sur l’Allemagne, alors que B, qui avait envoyé une transaction pariant sur la France, a gagné et doit récupérer ses gains, qui lui sont automatiquement envoyés. 

Bien entendu, cette intervention d’un Oracle, pour pratique qu’elle soit, pose des nombreuses question : Qui est cet oracle ? comment lui faire confiance ? Ne s’agit-il pas de la réintroduction d’un tiers de confiance dans une technologie qu’on vante (vantait ?) comme trustless ? Que se passe-il si l’information n’est pas ajoutée par l’Oracle, ou si elle est fausse ?

Le pouvoir exorbitant du tiers-Oracle est un facteur d’attaque potentiel

Le système d’Oracle implique le recours à une personne ou une société tierce partie dont le rôle est de rechercher d’insérer l’information demandée. Il est a priori rémunéré pour le faire. Cette personne peut être désignée par les participants au smart-contract, si elles se connaissent et le contrat prévoit cette possibilité, ou par le créateur dudit smart-contract, à l’avance.

L’oracle de Delphes avait prédit (décidé ?) l’avenir d’Oedipe et sa fin tragique

In fine, le recours à un Oracle revient à introduire un tiers de confiance, au pouvoir aussi exorbitant que son équivalent mythologique : il décide seul de l’issue des smart-contracts, qui sont par principe impossibles à arrêter… Mais à l’inverse de son homologue de Delphes, il peut faillir ; et de plusieurs façons :

• Il n’envoie aucune information dans la blockchain, il est déficient. Dans ce cas, le contrat ne pourra jamais s’exécuter. Il faut que les concepteurs du contrat aient prévu une porte de sortie pour ce cas de figure ; par exemple si aucune information n’a été entrée par l’Oracle à l’instant T, le contrat est annulé et chacun récupère sa mise de départ. Si rien n’a été prévu, le risque existe que les sommes éventuellement bloquées soient définitivement perdues.
• Il envoie par erreur ou de façon volontaire une information inexacte, par exemple parce que l’exécution conformément à cette fausse information a un intérêt pour lui. Dans ce cas, il est impossible de revenir en arrière, sauf à ce que le contrat prévoie une porte de sortie. L’information est entrée et enregistrée définitivement dans la blockchain ; et le programme va s’exécuter en prenant comme base cette information.

Qui contrôle l’Oracle ?

Pour limiter le pouvoir de l’Oracle, plusieurs structures plus ou moins complexes ont été envisagées.

• Si la donnée est disponible sur un serveur, il est possible d’avoir recours à un service dit provable-honest, qui permet de s’assurer de la validité de la donnée entrée. C’est notamment ce que propose la société Oraclize, qui fonctionne comme l’indique le schéma suivant.
  

  Le fonctionnement d’Oraclize

  Oraclize et les oracles similaires fonctionnent avec une « preuve d’honnêteté » (TLS Notary proof) qui garantit que la donnée entrée sur la blockchain est identique à celle qui a été récupérée par Oraclize. Comme la blockchain, cette preuve est publique et vérifiable par l’utilisation de méthodes cryptographiques. Cela signifie que si Oraclize entre un jour dans la blockchain une donnée non-conforme à la donnée récupérée sur le serveur, cette information « malhonnête » sera immédiatement repérable par n’importe quelle personne au fait de ces techniques. Ici, c’est la nécessité pour l’Oracle de conserver sa réputation à long terme qui garantit la fiabilité de ses prédictions.

• L’Oracle basé sur le consensus (consensus-based oracle) consiste à déporter le processus de collecte et d’envoi de l’information à un grand nombre de participants qui ont une motivation particulière à fournir la réponse correcte. Les sociétés Gnosis et Augur travaillent notamment sur des marchés prédictifs qui ont également pour vocation de servir d’Oracles à une multitude de contrats. Ce modèle est plus complexe mais pourrait permettre, à terme, de fournir une information fiable de façon entièrement décentralisée : ces marché prédictifs fonctionnent en effet directement sur Ethereum !

Enfin, l’oracle physique est une solution complémentaire voire indispensable lorsque la donnée nécessaire est une donnée physique particulière : la porte X est-elle ouverte ? quelle température fait-il à tel endroit ? Il est ici impossible de demander à une ou plusieurs personne de valider cette information spécifique. Il faut alors faire confiance à un objet qui mesure la donnée physique et à un mécanisme permettant de s’assurer que la donnée n’a pas été modifiée avant l’envoi sur la blockchain. La société Ledger, notamment, travaille sur un concept d’Oracle physique.

Ces mécanismes, loin de régler l’ensemble des problèmes posés par les oracles, laissent cependant entrevoir des solutions pragmatiques. Des constructions plus complexes peuvent également être imaginés, par exemple un appel à un second Oracle si l’une des parties à un smart-contract conteste le résultat entré par le premier, ou encore un mécanisme de résolution de conflits d’Oracles automatisés…  Quoi qu’il en soit, il ne fait aucun doute que les Oracles, publics ou privés, vont jouer un rôle déterminant dans le développement des applications décentralisées les plus ambitieuses.

Si vous êtes intéressés par ces questions, je vous recommande également la lecture des articles suivants, en anglais :

• Ethereum and Oracles, par Vitalik Buterin, sur le blog officiel de la Fondation
• A Visit to the Oracle, par Matt Liston sur ConsenSys Media
• Understanding Oracles, sur le blog officiel d’Oraclize.it