Oracles, les yeux d'Ethereum

Une fondation solide est essentielle à toute innovation pour assurer sa durabilité et son succès à long terme. Sans une base solide, les nouvelles technologies, les idées et les produits peuvent être instables et ne pas répondre aux besoins réels des utilisateurs, conduisant éventuellement à un échec. Rome ne s’est pas faite en un jour et il en va de même pour le sujet qui nous intéresse dans cet article : la blockchain. L’objectif, cependant, ne sera pas d’énumérer les diverses innovations qui innondent l’écosystème mais plutôt de s’attarder sur une notion fondamentale de ce dernier : les oracles. Si les smart contracts régissent les blockchain par leur gestion des données on-chain, les oracles sont les chefs d’orchestre des données off-chain. Que veut dire tout ce charabia ? Et d’ailleurs, qu’est ce qu’un smart contract ? Vous aurez, je l’espère, la réponse à ces questions à la fin de cet article.

Les smart contracts

Avant de plonger dans les oracles, mouillons nous la nuque en voyant plus en détail ce qu’est un smart contract. Véritable pierre angulaire de la blockchain, un smart contract n’est finalement rien de plus qu’un programme informatique dont l’exécution dépend de conditions prédéfinies. Ces conditions sont, bien entendu, écrites dans le code du programme en question. Bien qu’on associe parfois à tort les smart contracts à une exclusivité de la blockchain Ethereum, toutes les blockchains implémentent bel et bien des smart contracts dans des langages qu’elles sont disposées à comprendre. La petite protégée de Vitalik Buterin peut tout de même se targuer d’avoir “démocratisé” la notion en y dédiant un langage de programmation : Solidity, dont la première version date de 2014. Pour l’anecdote, cette date est antérieure à celle de la sortie d’Ethereum qui est le 30 Juillet 2015.

“Une image vaut mille mots” est un proverbe qu’on attribue, d’après Wikipédia, au célèbre philosophe chinois Confucius. Si mes sources concernant le proverbe sont pauvres, les suivantes le seront beaucoup moins. Ainsi, je vous propose d’appliquer tout de suite ce proverbe avec l’exemple proposé par Nick Szabo, pionnier de la blockchain, sur son blog, Unenumerated. Cet exemple est d’ailleurs mis en avant sur la documentation d’Ethereum : celui d'un distributeur automatique numérique. Tout simplement, imaginez que vous souhaitez un snack d’un distributeur automatique. Vous auriez alors la transaction suivante :

argent + choix d'un snack = distribution du snack

Au même titre que le distributeur automatique, un smart contract a une logique programmée qui se traduirait de la sorte en Solidity. Et comme j’aime ça, nos snacks seront ici des cookies :

Vous trouverez peu de complexité dans cet exemple ludique hormis éventuellement le type de variable address pour notre propriétaire de la machine. Il est nécessaire dans la mesure où l’exécution d’un smart contract sur Ethereum se fait depuis une adresse de la blockchain. Une précision peut s’avérer nécessaire à ce stade : un smart contract n’est pas une transaction. C’est bel et bien un outil déployé sur une blockchain avec lequel on interagit en lui soumettant une transaction (e.g. acheter des cookies) pour exécuter et inscrire cette dernière sur ladite blockchain. Aussi, la technologie de la blockchain assurant une irréversibilité de ses programmes déployés, vous ne pourrez retirer votre smart contract une fois déployé.

Maintenant que la notion de smart contract est limpide, nous allons pouvoir passer au sujet de cet article : les oracles. Si toutefois vous souhaitez éclaircir certaines zones d’ombre récalcitrantes, je vous propose quelques lectures plus détaillées concernant les contrats intelligents :

Introduction to smart contracts | ethereum.org

What are Smart Contracts?

Best Practices for Smart Contract Development

En outre, si vous souhaitez approfondir vos connaissances en programmation de smart contracts avec Solidity, je ne peux que vivement vous conseiller cet article sur le blog d’Ippon :

Premiers pas en Solidity
Cet article présente les premières bases de développement de smart contracts avec le langage de programmation Solidity. Vous y trouverez les instructions de base du langage ainsi que des explications

Que sont les oracles ?

Pourquoi ?

Avant de comprendre ce que sont les oracles, voyons pourquoi ils existent et où ils existent. A propos de géographie, à l’instar des smart contracts, nous ne parlons pas ici uniquement de la blockchain Ethereum mais bien de la majorité des blockchains. Contrairement aux smart contracts cependant, les oracles agiront davantage comme des APIs et sont donc moins dépendants de la blockchain à laquelle ils sont attachés. Pourquoi ? Vous allez vite le comprendre puisqu’après la géographie, parlons un peu d’histoire. Ainsi, dans notre quête de réponse au “pourquoi ?”, il nous faudra expliciter une notion quelque peu philosophique : le déterminisme. En effet, la blockchain, par essence, est déterministe à cause de ses mécanismes de consensus. Si comme moi vous n’avez pas eu la moyenne au bac en philosophie, sachez qu’on peut sobrement définir le déterminisme comme une théorie selon laquelle un événement est déterminé par la chaîne d’événements qui le précède. La blockchain applique donc ce modèle car si quelqu’un s’amusait à télécharger tout un historique de transactions et à “refaire l’histoire” de ces transactions, il (ou elle) se retrouverait au même état que la blockchain au moment où elle a été téléchargée. C’est ce déterminisme qui permet aux blockchains de se mettre d’accord via ce que j’ai nommé plus haut un mécanisme de consensus.

Source : https://chain.link/education/blockchain-oracles

Si la blockchain est déterministe, le reste du monde ne l’est toutefois pas toujours. Notre cher Internet ne l’est même carrément pas du tout. Téléchargez un historique précis au dixième des températures à Londres sur une journée sur plusieurs APIs; donc plusieurs sources de vérité. Il y a de fortes chances pour que vous ayez des variations pour une donnée qui a pourtant trait à la même information initialement. C’est cette divergence qui rend le consensus et, par extension, le déterminisme de la blockchain, impossible à connecter directement au monde réel et à internet. En résumé, les smart contracts qui règlent l’ingestion de données d’une blockchain ne peuvent pas consommer ces données si elles sont hors de ladite blockchain. Alors comment une technologie qui vise à apporter une vérité universelle, interagit-elle avec l’extérieur ? Sur quels tiers de confiance centralisés se base-t-elle pour importer des informations d’Internet ? C’est ce qu’on va voir maintenant.

Des smart contracts aux oracles

Si vous le permettez, j’aimerais rapidement clarifier une notion avant de continuer : on-chain signifie que les données mentionnées sont sur la blockchain donc immuables, sécurisées, etc. tandis qu’off-chain signifie, logiquement, extérieur à la blockchain. Merci pour cette parenthèse, nous sommes maintenant entre expert(e)s.

Spoiler alert, mais vous l’aurez peut-être deviné, les smart contracts peuvent interpréter les données off-chain grâce à des oracles. Mais alors qu’est ce qu’un oracle à la fin ? Si l’on se réfère à la définition présentée dans l’EIP-1154, un oracle est une entité qui rapporte des données à la blockchain. J’en conviens, lorsqu’on a tout le contexte, la simplicité rend la chose presque décevante. Ne vous en faites pas, dans les faits, on peut y trouver un brin de complexité malgré tout. En fait, on va utiliser une nouvelle forme de smart contracts : les hybrid smart contracts, que j’appellerai smart contracts hybrides pour franciser un peu le terme et me rapprocher le plus possible de ce que vous entendrez dans le monde réel. Cette nouveauté va simplement englober les notions d’oracle et de smart contract sous une seule appellation puisqu’un smart contract hybride n’est rien d’autre qu’une exécution de code on-chain basée sur des calculs et des données fournis par des oracles. Les services externes (e.g. un datalake) peuvent donc directement interagir avec les oracles qui géreront la donnée avant de l’inscrire sur une blockchain pour l’éternité.

Source : https://chain.link/education/blockchain-oracles

Les différents oracles

Pour prévenir la croissance incessante du nombre de type de données, il s’est rapidement avéré nécessaire de segmenter les oracles. A ce jour, et d’après les ressources dont je dispose, il m’est possible d’en mentionner 4 différents, à savoir :

  • Les input oracles. Ce sont ceux qui suivent le plus strictement la définition donnée plus haut et, probablement pour cette raison, les oracles les plus répandus dans le monde de la blockchain. Ils rassemblent simplement les données extérieures pour qu’elles transitent sur la blockchain afin d’être consommées par des smart contracts.
  • Les output oracles. Logiquement, ces oracles font le chemin inverse et font donc transiter des données présentes sur la blockchain et émises par des smart contracts vers l’extérieur. Eh oui, il n’y a pas de raison pour que le chemin soit à sens unique.
  • Les oracles cross-chain. Qui a dit que les données extérieures d’une blockchain ne provenaient pas d’une autre blockchain ? Si jamais vous rencontrez ce cas précis, ce type d’oracle pourra vous servir.
  • Les compute-enabled oracles. Les petits nouveaux du groupe, qui réalisent des calculs off-chain lorsque ces derniers ne sont pas possibles on-chain pour des raisons, le plus souvent, d’ordre technique, financier ou juridique.

Exemples et limites

De nos jours, plusieurs solutions sérieuses existent sur le marché du web 3. Leur proposition de valeur raréfie peu à peu le besoin d’implémenter votre oracle maison, ce qui n’enlève rien à leur nécessité assez systématique lorsqu’on développe une solution qui tient compte du monde extérieur de la blockchain. De surcroît, il existe de bien meilleurs tutoriels d’implémentation que celui que je pourrais vous proposer ici, je m’abstiendrai donc de vous en faire un. En voici toutefois quelques-uns si vous souhaitez vous essayer à cette pratique :

Create your own oracle with an Ethereum smart contract - LogRocket Blog
Learn how to build an oracle, which helps connect blockchains to external systems and enable access to data from off-chain systems.
Implementing a Blockchain Oracle on Ethereum
TLDR: In this post, I explain how you can build an Ethereum blockchain oracle. This service will query APIs, upon request by…

Exemples…

Commençons donc notre tour d’horizon d’Oracles “as a service” avec la solution utilisée par les tutoriels susmentionnés.

Source : https://chain.link/

Chainlink est un outil open source écrit en Solidity (donc basé sur Ethereum) qui propose divers outils pour connecter vos smart contracts à l’extérieur. Les solutions proposées par Chainlink aux développeurs utilisent toutes un DON (Decentralized Oracle Network ou réseau décentralisé d’oracle en français).

La solution la plus simple est l’utilisation de data feeds qu’on peut globalement diviser en 4 entités :

  • Un Consumer : une application on-chain ou off-chain qui utilise des data-feeds et joue le rôle de pont final. Ce Consumer utilise le Proxy contract pour récupérer les données depuis l’Aggregator contract;
  • Un Proxy contract : un smart contract on-chain qui joue donc le rôle de proxy entre le Consumer qui demande un data feed particulier et l’Aggregator contract. Le Proxy contract permet également de maintenir un service continu lors d’une mise à jour de l’Aggregator contract;
  • Un Aggregator contract : un smart contract on-chain qui reçoit des mises à jour régulières de données depuis le réseau de l’oracle. L’Aggregator contract stocke les données agrégées on-chain pour que les consommateurs puissent les utiliser au cours de la même transaction, donc via une seule validation par le mécanisme de consensus;
  • Un DON Chainlink : un réseau de nœuds validateurs de données, raison d’exister première de la blockchain Chainlink servant de tiers de confiance décentralisé pour la donnée agrégée par les Aggregator contracts.
Source : https://chain.link/data-feeds

Le schéma ci-dessus fournit par Chainlink dans sa documentation présente un exemple d’utilisation des data feeds pour la récupération de données de marchés financiers décentralisés sur des agrégateurs (en utilisant les Aggregator contracts mentionnés ci-dessus). Le DON de Chainlink, indépendant à ces agrégateurs, constitue notre tiers de confiance décentralisé qui va contrôler la donnée avant la réalisation d’un smart contract de référence par le Proxy contract. Enfin, un utilisateur peut consommer la donnée, il représente notre Consumer.

Pour aller plus loin sur la gouvernance de la blockchain Chainlink qui constitue un tiers de confiance sur la validité de la donnée, le projet implémente un token, extension de l’ERC-677, interface Ethereum appelée transferAndCall Token Standard. Le token Chainlink est appelé LINK et est référencé sur la plupart des exchanges. Il sert notamment à récompenser les validateurs de la donnée. Notez toutefois que, bien qu’implémenté en Solidity et basé sur des interfaces d’Ethereum, Chainlink fournit un oracle décentralisé sur bien d’autres blockchains. Vous pourrez en lire davantage sur la gouvernance à ce sujet ici :

LINK Token Contracts | Chainlink Documentation
Chainlink is the most widely used oracle network for powering universally connected smart contracts, enabling any blockchain to access real-world data & APIs.

Enfin, et pour conclure sur cette présentation du leader actuel des oracles, il faut noter la pluralité des solutions qu’il apporte. En effet, Chainlink ne se limite pas aux data feeds présentés ci-dessus. On peut notamment mentionner les Functions qui sont des outils clé en main pour consommer de la donnée publique dans des smart contracts. Cet outil est le petit dernier sorti par Chainlink et constitue une sorte d’abstraction supplémentaire pour les développeurs de smart contracts qui peuvent désormais consommer les APIs du web 2 de façon encore plus abstraite, contre rémunération, évidemment. Voici d’ailleurs le schéma présentant ce fonctionnement sur le site de Chainlink :

Source : https://chain.link/functions

Vous l’aurez compris, Chainlink ne tarie pas d’outils pour faciliter la consommation on-chain de données off-chain mais cet article se veut relativement exhaustif sur les organisations proposant des oracles, je vous laisserai donc découvrir le reste de leur travail sur leur site, partagé plus haut. Maintenant, il est temps de passer à la concurrence.

Witnet

Si fondamentalement, le fonctionnement de Witnet est similaire à celui de Chainlink, quelques subtilités peuvent toutefois motiver certains consommateurs de données à utiliser une solution plutôt que l’autre.

Comme mentionné plus tôt dans cet article, Chainlink base principalement son implémentation sur les outils fournis par la blockchain Ethereum. Les deux blockchains sont donc intimement liées contrairement à Witnet qui est codé en Rust et promeut un neutralité des autres blockchains d’une part et des cas métiers d’autre part. En un mot comme en cent, que vous demandiez de la donnée sur le cours de Bitcoin, sur une messagerie publique ou sur la météo de Londres, Witnet vous la fournit de façon vérifiée et sécurisée sans connaître ni le type de la donnée ni sa provenance. Ceci étant, à l’instar de Chainlink, Witnet implémente son propre token, le WIT, qui se base, non pas sur des EIPs (Ethereum Improvments Proposals) mais sur des WIPs (Wit Improvement Proposals).

Source : https://witnet.io/

Provable (ex Oraclize)

Enfin, je souhaitais mentionner Provable comme dernier exemple de réseau Oracle disponible pour les développeurs. Cependant, je ne m’étendrai pas sur le projet qui s’appelait initialement Oraclize puisque sa centralisation le rend inévitablement moins pertinent et moins attirant à l’utilisation que ses deux concurrents.

En effet, Provable base la validation de ses données sur une API centralisée, faisant de Provable un tiers de confiance centralisé dans lequel il faut avoir confiance. Pourquoi le mentionner, me direz vous ? Bien que ce ne soit pas le sujet de cet article, et malgré des solutions éprouvées, la blockchain n’en demeure pas moins une technologie innovante qui n’a pas encore terminé son adolescence dans le monde adulte de la technologie de l’information. Il est donc peu étonnant de trouver des solutions centralisées, très “web 2” by design, sur des sujets sensibles tels que la validation des données. Certaines entreprises souhaitent en effet innover en utilisant de la blockchain mais ne sont pas encore prêtes à sauter le pas de la totale décentralisation.

Cette critique, ni positive, ni négative de la centralisation des solutions liées à la blockchain forme une parfaite ouverture vers la dernière partie de cet article : les limites des oracles.

… et limites

Au risque de vous décevoir, je prendrai peu de risques sur l’énumération des limites des oracles. Il y a deux raisons à cela. D’une part, et en toute humilité, je manque d’expérience sur l’utilisation des oracles pour des projets d’envergure. D’autre part, Ethereum propose dans sa documentation une section intitulée “the oracle problem?”. C’est donc en toute transparence que je vais exploiter cette ressource open source et gratuite pour exprimer les limites des oracles.

En effet, à l’instar des doutes subsistants vis-à-vis du web 3, les oracles font malgré tout face à certains défis. Le principal, le plus mentionné et le plus évident est la confiance nécessaire envers les opérateurs d’oracles (Chainlink, Witnet, Provable, …) de fournir aux smart contracts une donnée effectivement fiable et correcte. On n’aime pas trop la confiance dans la blockchain dans la mesure où la technologie permet justement par essence de décentraliser le tiers de confiance que représente une source d’information. Ce principal problème se décline en 3 défis auxquels les opérateurs susmentionnés doivent faire face dans le quotidien de leur développement :

  • L’exactitude. Un oracle doit garantir l’authenticité et l’intégrité des données off-chain qu’il fournit. L’authenticité signifie que les données fournies proviennent de la bonne source et l’intégrité qu’elles sont restées intactes depuis cette source jusqu’au smart contract.
  • La disponibilité. Les smart contracts doivent disposer de la donnée lorsqu’ils en ont besoin. Il n’est pas concevable qu’un élément en dehors de la blockchain bloque leur bon fonctionnement.
  • La compatibilité incitative. Les oracles ont également une fonction incitative aux fournisseurs de données off-chain de fournir une donnée correcte aux smart contracts. Cela implique la responsabilité du fournisseur quant à l’information qu’il met à disposition.

Finalement, les limites des oracles tiennent à assurer la fiabilité et la confiance dans les données off-chain qu’ils font transiter.

Conclusion

En définitive, les oracles sont des outils bien pratiques dans le monde du développement lorsqu’il s’agit de blockchain. Si OpenAI a récemment connecté son IA générative à internet pour décupler la puissance de celle-ci, la blockchain n’a pas attendu l’IA pour ingérer les données du World Wide Web. Néanmoins conscientes du grand bazar que cela représente, à l’instar des sociétés créatrices d’IA d’ailleurs, les organisations responsables du développement des blockchain, dans notre article l’Ethereum Foundation, ont rapidement trouvé des moyens de régenter les données extérieures. La blockchain, même dans son implémentation la plus simple, doit rester déterministe pour conserver tout l’intérêt technologique qu’elle représente et cela passe parfois, au détriment des plus maximalistes de la décentralisation, par une certaine confiance à accorder à des outils extérieurs, centralisés. Enfin, dernier amalgame avec l’intelligence artificielle, la blockchain n’en est qu’aux prémices de son innovation. Nous sommes encore dans la rupture ce qui signifie qu’il ne faut en aucune façon exclure que de nouvelles solutions apparaîtront dans un avenir relativement proche. C’est toute la beauté de l’innovation : rédiger rapidement un article dont on espère que le contenu sera obsolète dans peu de temps. Finalement donc, je vous dis à bientôt.