Actu-crypto

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
☑ ☆ ✇ blogchain café

Google Cloud intègre l’Oracle décentralisé Chainlink et sa blockchain.

By: Nathan Chiron

L’équipe Google Cloud a intégré le middleware oracle de Chainlink à son stock de données cloud BigQuery, ce qui permet une interaction entre blockchain et cloud pour des applications décentralisées Ethereum qui exécutent des smart-contract. La nouvelle a été annoncée dans un rapport de développement officiel de Google publié le 13 juin et sur les réseau sociaux par Chainlink.

L’annonce officielle via twitter, côté Chainlink.

Après Microsoft qui avait proposé son système d’ID mondial sur bitcoin et Facebook avec son projet Libra, cette nouvelle intégration montre encore une fois que les géants technologiques dans le monde comprennent la rupture majeure que la blockchain apporte et commencent à opérer dans le secteur des crypto-monnaies, au sens large.

Un lien existe désormais entre les blockchain et les services Cloud. Cette annonce est tellement innovante qu’elle a permis à LINK d’atteindre un nouveau sommet sans précédent, avec une hausse de 70% en moins d’une heure, après publication.

Qu’est ce qu’un Oracle ?

La blockchain ne permet pas la collecte de données depuis une source externe. En effet, chaque utilisateur de 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. Cela pose deux problèmes majeurs :

  • Une charge trop importante pour le service
  • La confiance envers le service externe car si il est hors ligne, piraté ou répond à une autre donnée, la résolution du bloc X diffère de 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. 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.

L’Oracle, 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.

En tant que middleware, l’oracle de Chainlink se trouve alors à servir de passerelle d’échange d’informations entre les deux différents réseaux principaux la blockchain ETH d’un côté et le Cloud de BigQuery de l’autre.

L’Oracle ChainLink est un mécanisme DECENTRALISE qui détecte et vérifie les occurrences du monde réel et ajoute ces informations à la blockchain pour qu’elles soient utilisées dans des smart contracts.

Le lien entre le cloud et la blockchain

Schéma de lien entre le Google Cloud et la blockchain
Source : publication officielle Google Cloud – 13 Juin
  1. Les DApps d’Ethereum formulent une demande d’accès aux données à Chainlink, qui à son tour récupère les données d’un service web construit avec Google App Engine et BigQuery.
  2. Pour récupérer les données de BigQuery, une DApp doit donc appeler le contrat Chainlink Oracle correspondant, en incluant le paiement de la demande à traiter.
  3. Les nœuds Chainlink sont en charge de la surveillance de ces requêtes, jusqu’à ce que l’évènement se réalise et qu’un de ses nœuds exécute la tâche demandée. Google App Engine récupère alors les données de BigQuery, qui héberge les ensembles de données dans son Cloud.

Cas d’utilisation

Google Cloud propose l’utilisation des services Chainlink pour interagir avec les données publiques du Cloud. Notamment les données de l’outil BigQuery deviennent disponibles dans un smart contract Ethereum. Cette technique peut être utilisée pour réduire les inefficacités et de nouvelles fonctionnalités voient le jour dans Ethereum

  • Amélioration de la confidentialité de certaines transactions
  • Possibilité de masquer des transactions en les rendant anonymes
  • Possibilité de régler les paris spéculatifs sur les marchés de prédiction, tels que Augur
  • Possibilité de tirer pleinement parti de la technologie du Cloud
  • Exploitation pour la première fois d’un pont fiable cloud-blockchain
  • Essor de nouveaux business-models blockchain

Conclusion

Google prévoit que cette technique d’interopérabilité amènera les développeurs à créer des applications hybrides optimisant les fonctionnalités des plates-formes de smart-contract et cloud. Par ailleurs, l’objectif futur est d’intégrer les services ML de Google Cloud Platform (par exemple, les API AutoML et Inference).

Chainlink est donc un fournisseur de données blockchain qui récupère des tas de données in-chain et off-chaine pour une exécution dans des smart contracts. Son intégration de la part d’un des quatre GAFA crée pour la première fois un pont majeur entre les deux mondes que tout oppose serveurs cloud centralisés vs noeuds blockchain décentralisés.

En toute logique cette action stratégique de Google facilitera le développement d’applications hybrides cloud-blockchain mais prouve surtout et avant tout que la rupture blockchain est actée et désormais nettement reconnue par les géants du vieux monde.

☑ ☆ ✇ blogchain café

The Graph : queries decentralisées pour blockchain

By: Nathan Chiron

The Graph est un protocole décentralisé permettant d’indexer et d’interroger des données de blockchains Ethereum. Cela permet une recherche plus optimisée de données difficilement accessibles. The Graph constitue un des premiers language de requête blockchain pour permettre de récupérer des informations.

Imaginez pouvoir accéder aux données blockchain via un language
de requête aussi simple que efficace que votre SQL tout en gardant vos données décentralisées. C’est en deux mots la promesse de The Graph, un protocole permettant de créer rapidement des applications décentralisées sous Ethereum et IPFS via le langage GraphQL développé en interne par Facebook en 2012.

The Graph indexe les données Ethereum en fonction de descriptions dites sous-graphiques et manifestes de sous-graphiques. Ces entitées définissent les smart-contracts et leurs événements qu’on veut surveiller ainsi que la façon de mapper les données d’événement aux données que The Graph stockera dans sa base de données.

Une fois que l’application a exécuté une requête, le graph l’achemine vers les nœuds de requête qui contiennent l’index. Les nœuds de requête renvoient le résultat au nœud de passerelle, puis au développeur.

Le token sous-jacent est utilisé pour sécuriser et gérer le réseau. En bref, il est lié par des nœuds de requête et ceux-ci peuvent être utilisés comme moyen d’échange au sein du réseau.

Une fois qu’un manifeste de sous-graphiques est écrit, vous utilisez la CLI graphique pour stocker la définition dans IPFS et indiquez au service hébergé de commencer à indexer les données de ce sous-graphique.

Il est important de souligner que via The Graph, les requêtes sont traitées sur un réseau décentralisé, ce qui garantit que les données restent publiques et que les dApps continuent de s’exécuter quoi qu’il arrive derrière. Les utilisateurs n’ont pas besoin de faire confiance à des équipes pour faire fonctionner des serveurs et les développeurs peuvent déployer leurs efforts sur une infrastructure publique de confiance qu’ils n’ont pas à gérer. The Graph fournit par ailleurs une API puissante pour obtenir exactement les données dont vous avez besoin en une seule requête, en parcourant et en combinant de manière transparente les sources de données.

Pourquoi l’accès aux données blockchain est si difficile ?

Dans le système des blockchain classiques il existe trois points caractéristiques de requête nécessitant une amélioration :

  • Décentralisation : les données contenues dans une blockchain résident dans un réseau décentralisé de nœuds qui répliquent en permanence des enregistrements entre eux. Ainsi, dans ce modèle l’accès aux données est beaucoup plus complexe que les infrastructures de base de données centralisées.
  • Opacité : les données dans la blockchain sont soumises à différents niveaux de cryptage ce qui rend leur interprétation difficile. L’intérêt d’un protocole de requête est de connaître par sa base de données et ses liens entre les informations, comment interroger la blockchain.
  • Stockage séquentiel des données : les données contenues dans les blockchain sont transporter en groupe séquentiel de blocs dans les transactions. Cette structure de données par transaction en blocs offre de très mauvaises capacités de navigation.

Ainsi, une pile d’accès aux données Web 3.0 efficace devrait avoir trois fonctionnalités principales :

  1. Possibilité d’accéder aux informations comme si elles étaient stockées dans un référentiel centralisé.
  2. Possibilité d’interroger des enregistrements en fonction de ses attributs.
  3. Capacité à naviguer efficacement dans les données de la blockchain en fonction de critères spécifiques.

Un index décentralisé

Comme développé ci-dessus, The Graph est un protocole décentralisé permettant d’indexer et d’interroger des données de blockchain. Le graph commence par créer un manifeste décrivant les données de la blockchain. Le manifeste peut spécifier les attributs d’un protocole spécifique de DApp. Une fois le manifeste créé, le graph capture tous les événements blockchain de ce protocole ou de cette application spécifique et les indexe dans IPFS à l’aide du manifeste comme référence. Enfin, les données sont exposées par des API basées sur le protocole GraphQL populaire. Le noeud final Graph traduira les requêtes GraphQL en commandes IPFS utilisées pour accéder aux données.

Dans une base de données centralisé, un utilisateur peut modifier l’index et orienter un autre utilisateur vers un mauvais fichier. Un index décentralisé évite ce problème en utilisant un réseau de nœuds possédant une copie de l’index. De la même manière, que la blockchain fonctionne.

Ce schéma donne plus de détails sur le flux de données une fois qu’un manifeste de sous-graphiques a été déployé, traitant des transactions Ethereum:

Architecture du protocole The Graph

Le flux suit ces étapes:

  1. Une application décentralisée ajoute des données à Ethereum via une transaction sur un smart-contract.
  2. Le smart-contract émet un ou plusieurs événements lors du traitement de la transaction.
  3. Graph Node recherche continuellement dans Ethereum de nouveaux blocs et les données de votre sous-graphique qu’ils peuvent contenir.
  4. Graph Node recherche les événements Ethereum pour votre sous-graphique dans ces blocs et exécute les gestionnaires de mapping que vous avez fournis. Le mapping est un module WASM qui crée ou met à jour les entités de données que Graph Node stocke en réponse à des événements Ethereum.
  5. L’application décentralisée interroge le noeud graphique pour obtenir des données indexées à partir de la chaîne de blocs, à l’aide du noeud final GraphQL. Le nœud graphique convertit à son tour les requêtes GraphQL en requêtes pour son ensemble de données sous-jacent afin d’extraire ces données, en utilisant les fonctionnalités d’indexation.
  6. L’application décentralisée affiche ces données dans une interface utilisateur riche pour les utilisateurs finaux, qu’ils utilisent pour émettre de nouvelles transactions sur Ethereum.
  7. Le cycle se répète.
Un manifeste de sous-graphique YAML

« Tout ce dont vous avez besoin pour exécuter un sous-graphique est open source. Pour l’instant, nous utilisons Postgres comme moteur de stockage. Graph Node définit une abstraction que nous implémentons en utilisant Postgres et nous nous réservons le droit de modifier la base de données sous-jacente à l’avenir. Nous avons écrit beaucoup de code, mais c’est du code open source, donc rien de tout ça n’est propriétaire. »

Le sous-graphique

Un sous-graphique définit les données que le graphe indexera à partir d’Ethereum et comment il les stockera. Une fois déployé, il fera partie d’un graphique global de données blockchain.

La définition du sous-graphique comprend quelques fichiers :

  • subgraph.yaml : un fichier YAML contenant le manifeste de sous-graphique
  • schema.graphql : un schéma GraphQL qui définit quelles données sont stockées pour votre sous-graphique et comment les interroger via GraphQL
  • Mappages AssemblyScript : code AssemblyScript qui traduit les données d’événement dans Ethereum vers les entités définies dans votre schéma.

Conclusion

The Graph est une méthode innovante de résolution d’équation par approximations successives pour relever l’un des défis les plus importants des applications Web 3.0. En exploitant des technologies établies telles que IPFS, Postgress ou GraphQL, The Graph simplifie les points d’entrée blockchain pour les développeurs. Afin d’optimiser la solution, la version actuelle de The Graph a récemment été mise en open source et est activement mise à jour. Bien qu’il n’en soit encore qu’à ses débuts, The Graph semble disposer des bases technologiques pour devenir l’un des protocoles les plus importants du mouvement Web 3.0. The Graph peut devenir un écosystème véritablement décentralisé dans lequel la communauté collabore pour gérer des sources de données de qualité accessibles à tous. Une nouvelle génération du Web qui ne passe plus par des silos de données et qui bypasse tous monopoles est en train de prendre forme.

❌