Gateway propose une solution back-end pertinente et disruptive à destination des développeurs de dApps. Un outil complet qui intègre entre autres la possibilité de créer en quelques clics un nœud de communication RPC vers les principaux réseaux blockchain. Décryptage.
Au commencement était la blockchain
Il nous faut ici commencer par rappeler quelques faits essentiels. La “blockchain” est un ensemble d’ordinateurs gérés par des individus et/ou des entreprises. Ils participent collectivement à la vérification de l’état de ce “registre décentralisé”, selon certaines règles prédéfinies.
Dans le cadre d’internet, on parle de serveurs, mais dans le cadre de la technologie blockchain, chaque interface opérationnelle physique est désignée comme un nœud, ou node. Répartis sur la planète entière, c’est la connexion de tous les nœuds qui fait fonctionner les blockchains telles qu’Ethereum ou Bitcoin. Il n’y a pas de serveur principal ou central, la vérité est un consensus distribué de tous les instants, et le réseau est ainsi décentralisé.
Par extension, un nœud est donc un programme qui tourne quelque part sur un ordinateur et vous permet de participer au réseau. Se connectant à d’autres parmi ses semblables, il peut envoyer et recevoir des informations, émettre et vérifier la validité de transactions ou encore stocker et attester de l’état de la blockchain. Ces partages et interactions ont lieu grâce à un petit acronyme lourd de sens: l’API.
L’épineuse question de la communication
Les APIs, ou “Application Programming Interfaces” se définissent comme un ensemble de fonctions informatiques par lesquelles deux logiciels interagissent sans intermédiation humaine. Une API se décompose en trois mots-concepts :
- Application: il s’agit de tout service avec lequel un développeur ou une autre application souhaite interagir. Cela peut être un service bancaire, un réseau social, une dApp de jeu, un portail commercial …
- Programming: fonction informatique créée par le développeur pour qu’elle interagisse de manière autonome lorsque l’application présente une requête. Le programme peut par exemple émettre des données, collecter des informations à intervalles réguliers, ou encore remplir un formulaire …
- Interface: c’est la nature de l’API, elle est située entre les applications et les nodes. Une couche intermédiaire qui traite le transfert de données entre les systèmes.
Trois termes qui résument parfaitement l’enjeu qui se cache sous ces avatars programmatiques parfois complexes. Formellement, ces requêtes comprennent un verbe de requête, des en-têtes (headers) et, parfois, un corps de requête, mais nous aborderons la question plus loin. Leur fonctionnement est le suivant :
- Une application client (dApp) lance un appel d’API pour récupérer des informations, ce que l’on appelle également une requête.
- Après avoir reçu une demande valide, l’API récipiendaire lance un appel à son nœud.
- Celui-ci renvoie une réponse à son API avec les informations demandées.
- L’API transfère les données à l’application requérante initiale.
Sans les APIs, point d’interaction entre les nœuds, et par conséquent, point de blockchain.
Les APIs sont donc nécessaires, mais sont-elles suffisantes ?
L’API rend accessible un service proposé afin qu’il soit consommé par des programmes ou des applications. D’une certaine manière, elle agit comme la prise à laquelle on branche un appareil (une dApp) pour qu’il puisse accéder à la source d’énergie (la blockchain) et consommer l’électricité (les données) dont il a besoin pour fonctionner.
Et bien évidemment, ces interfaces pullulent sur tout ce qui ressemble de prés ou de loin à un réseau informatique comme par exemple internet. Il en existe de nombreux types. La plus répandue est l’API REST. Un nouvel acronyme valant pour “Representational State Transfer”. Cette architecture prend en charge les opérations CRUD (create/read/update/delete) . Ainsi, on dispose de 4 canaux distincts pour créer, lire, mettre à jour ou supprimer les ressources gérées par votre node.
Mais c’est justement ici que le bas blesse. Bien que flexible à l’extrême et compatible avec la majorité des protocoles, les API REST sont en revanche cantonnées à un rôle de gestion des données. Leurs 4 fonctions balisent autant qu’elles entravent leur utilisation dans le cadre de la blockchain. Pourquoi ? La nature immuable de celle-ci n’admet ni modifications ni suppressions, rendant superflues 2 capacités sur 4. En revanche, elle ne se contente pas de gestion, mais nécessite plutôt le moyen de déployer à distance les appels de commandes parfois complexes que recèlent les smart-contracts.
“Less is more !” : Les RPC, une API générique qui tire sa force de sa simplicité
Plutôt que de composer avec une forme inadaptée, les développeurs crypto se sont naturellement dirigés vers un format d’API plus efficient, j’ai nommé les RPC. En informatique distribuée, un RPC (Remote Procedure Call) fait référence au processus par lequel un programme exécute une sous-routine dans un emplacement distinct (l’espace d’adressage).
Un RPC est l’API la plus simple à implémenter sur un nœud. Les développeurs peuvent ainsi communiquer avec d’autres nœuds pour exécuter du code à distance, un peu comme ils feraient un appel de fonction dans un programme. Après l’exécution du code, une réponse est renvoyée vers le nœud client. Il n’a pour ce faire que deux actions à sa disposition : GET et POST. En résumé, GET est utilisé pour récupérer des données distantes, et POST est utilisé pour insérer/mettre à jour des données distantes.
Les seules fonctions GET et POST permettent d’effectuer littéralement n’importe quelle opération “on-chain”. Ainsi, lorsque les développeurs créent des dApps, les RPC leur permettent de déployer les codes consécutifs aux demandes des utilisateurs sur les écosystèmes de services décentralisés. Lorsque les utilisateurs utilisent leurs wallets pour effectuer des transactions, ou accèdent à un DEX, leurs demandes passent par une couche de RPC pour interagir avec les nœuds qui détiennent les données des blockchains qui les intéressent.
Pourquoi faire compliqué lorsqu’on peut faire simple ?
Maintenant, nous savons pourquoi les nœuds-RPC sont vitaux pour les applications. Sans la possibilité d’envoyer un appel RPC, nous ne pouvons pas permettre à nos dApps d’interagir avec la blockchain de notre choix. C’est alors que se pose la question du “comment ?”. Toutes les RPC sont codées sur la même base que les procédures de programmation ordinaires ou les appels de fonctions.
Pour prendre l’exemple d’Ethereum, les procédures RPC les plus répandues sont codées en JSON. Il s’agit d’un format de structuration et d’échange de données léger et populaire basé sur la syntaxe JavaScript. S’agissant tout simplement de texte formaté selon la structure JSON, les “JSON-RPC” sont assez faciles à mettre en œuvre, à lire et à déboguer. C’est pourquoi ils sont si répandus, et pas seulement dans le contexte Blockchain.
Ils accomplissent leurs tâches par une requête qui sollicite la routine hébergée sur un nœud distant. Elle lui transmet trois paramètres d’entrée. Le nœud peut éventuellement renvoyer plusieurs données en réponse.
- Method: une ligne contenant le nom de la routine à invoquer.
- Params: un tableau de valeurs pour paramétrer la routine définie.
- Id: identifie la demande afin que la réponse éventuellement produite lui parvienne.
Une demande n’attend pas forcément de réponse. En revanche, chaque réponse formulée par le nœud destinataire doit être valide. Celle-ci peut contenir les éléments mentionnés ci-dessous.
- Result: les données renvoyées par la routine invoquée.
- Error: élément facultatif présent si une erreur s’est produite lors de la requête.
- Data: élément facultatif pouvant contenir d’autres données spécifiques au nœud.
- Id: l’identifiant de la demande à laquelle il répond.
Simple, efficace, mais devinez quoi …
Les développeurs ont mieux à faire que de gérer des nœuds !
Nous l’avons vu, depuis l’origine de la blockchain, les développeurs ont cherché à se simplifier la vie. J’en veux pour preuve le fait que “Saint” Satoshi Nakamoto a lui (eux)-même choisi le format JSON-RPC pour Bitcoin, back in 2009 ! Mais hélas, les choses ne sont pas si simples … Le développement d’une infrastructure complexe autour du nœud RPC est nécessaire. Ce processus implique une grande quantité d’indexation, la recherche d’informations, la mise en place d’une base de données, etc …
La hantise de tout développeur est de passer trop de temps à configurer un outil qui ne contribue pas directement à ce qu’il essaie de construire, et les nœuds sont parmi les pires exemples dans cette catégorie. Le développement inhérent à la construction d’un nœud RPC peut en-effet être extrêmement coûteux en ressources et en temps. Il n’est d’ailleurs pas rare qu’on les compare à des tueurs de productivité.
Et comme si cela ne suffisait pas, une fois votre node-RPC parfaitement configurée et fonctionnelle, il s’agit maintenant de la maintenir dans le temps. Voici une liste non-exhaustive des tâches qui vous incombent dans cette optique :
- Les nœuds doivent être régulièrement mis à jour, et occasionnellement reconstruits à partir de zéro, dans le cas de hard-forks par exemple.
- Certaines requêtes peuvent impliquer l’exécution de millions de transactions. Ces “Death Request” vous réveilleront souvent à 3 heures du matin pour les déboguer.
- Les nœuds artisanaux peuvent plus facilement prendre du retard sur le réseau pour diverses raisons : problèmes de peering et de connexion, blocage sur des branches obsolètes, problèmes d’état interne. Vos utilisateurs recevront sans le savoir des données périmées, ce qui peut être extrêmement dommageable, vous en conviendrez …
La solution RPC de Gateway
Gateway propose donc un service particulièrement utile, mais aussi très complet puisque cerise sur le gateau, il est multichain ! Développeurs, vous allez pouvoir, en quelques clics, disposer d’une porte d’accès aux données de plusieurs protocoles sans vous soucier de la mise en œuvre de votre propre nœud-RPC !
A cette heure, sont disponibles les réseaux Ethereum (et par extension tous les layer 2 succédanés compatibles EVM), Near et Fantom. Une liste qui est bien évidemment provisoire et qui s’allongera régulièrement dans les mois à venir.
En substance, Gateway fait tourner à votre place des nœuds RPC rapides, entièrement synchronisés et à jour, disponibles 24 heures sur 24 et 7 jours sur 7. Les avantages d’une telle approche sont nombreux :
- Accès illimité à des nœuds légers et complets régulièrement mis à jour, de sorte que vous n’avez pas à vous soucier des forks ou des changements de réseau.
- Évolutivité et fiabilité : les nœuds RPC de Gateway sont disponibles quand vous le voulez, autant que vous le voulez.
- Cohérence : les fournisseurs doivent gérer les cas limites délicats, comme les problèmes de synchronisation du dernier bloc qui peuvent aboutir à des décalages entre l’état du réseau et sa représentation au sein de vos dApps. Un problème que rares sont les fournisseurs concurrents à contrevenir.
- Gain de productivité : vous allez pouvoir vous consacrer à temps plein à bâtir votre projet plutôt que de vous débattre avec des problématiques annexes et chronophages !
Gateway aime à se présenter sous la forme d’un “hub”, un centre névralgique qui propose un ensemble d’outils destinés à prendre en charge toutes les problématiques dites “back-end”. Une offre bien plus large que la simple fourniture de nœuds RPC.
La neutralité carbone de ces derniers dévoile une approche éco-responsable. Leur dissémination géographique en garantit la disponibilité autant que la décentralisation. Une quête d’excellence sur un domaine hautement stratégique qui devrait rapidement faire des nœuds RPC de Gateway un absolu “must-have” du secteur.
