Fournisseur RPC blockchain

JSON-RPC est un protocole sans état qui encode une requête et une réponse en JSON, et les appels d'une application sont peu nombreux et de coût inégal. Lire la tête de la chaîne avec un appel comme eth_blockNumber coûte peu. Lire un solde ou l'état actuel d'un contrat coûte peu. Soumettre une transaction signée coûte peu au nœud et engage l'utilisateur.

L'appel coûteux est la requête de logs. Demander tous les événements correspondant à un filtre sur une large plage de blocs oblige le nœud à parcourir les données, et c'est l'appel qu'un fournisseur restreint en premier, par plage de blocs, par nombre de résultats ou en le refusant purement et simplement sur une offre gratuite. La seconde famille coûteuse est l'abonnement: un abonnement WebSocket aux nouveaux blocs ou aux événements correspondants permet à une application d'apprendre quelque chose sans interrogation répétée, et un endpoint gratuit ne le propose souvent pas. Une application conçue en fonction de ces deux limites est complètement différente d'une application qui ne l'a pas été, et c'est pourquoi le choix de l'endpoint se fait au début d'un projet.

Un endpoint public, celui qu'indique la documentation d'une chaîne ou que propose un explorateur, est gratuit, partagé et ne doit rien à personne. Les limites de débit des offres gratuites et partagées se situent généralement à quelques dizaines de requêtes par seconde, l'endpoint peut être abandonné ou modifié sans préavis, et l'exploitant voit chaque requête. Un endpoint public convient à un prototype et pas à ce dont une entreprise doit répondre.

Un fournisseur hébergé vend un endpoint partagé ou dédié avec un niveau de service, un accès archive sans coût de stockage, des abonnements WebSocket et un routage entre plusieurs centres de données afin qu'une requête aboutisse près de l'application. La règle empirique du marché veut qu'une application au-delà d'environ dix mille requêtes par seconde relève d'une infrastructure dédiée. Un nœud propre donne une exactitude que l'entreprise a vérifiée elle-même et des requêtes que personne d'autre ne voit, au coût opérationnel que décrit la page sur l'infrastructure de nœuds blockchain. La plupart des entreprises finissent avec un fournisseur dédié plus un nœud propre pour les requêtes qui comptent.

Un nœud complet ne conserve que l'état récent, sur Ethereum les 128 derniers blocs par défaut, car l'état plus ancien n'est pas nécessaire pour valider de nouveaux blocs. Toute question sur le passé, un solde à une date, l'état d'un contrat avant une mise à niveau, un événement de l'an dernier, exige un nœud archive qui a tout conservé.

C'est pourquoi l'accès archive est facturé à part ou réservé aux offres supérieures: le nœud qui le sert occupe d'environ deux téraoctets avec un client économe en stockage jusqu'à douze téraoctets et plus, et il grandit. Pour une entreprise financière, le point pertinent est que les questions des auditeurs sont précisément les questions historiques. Une valorisation à une date de reporting, une position en fin d'année, un historique de transactions pour une déclaration fiscale sont tous des requêtes archive, si bien qu'une entreprise dont l'endpoint ne peut pas y répondre a un problème de reporting et non une préférence technique.

C'est la partie du sujet qui reçoit le moins d'attention et qui compte le plus pour une entreprise réglementée. Un fournisseur RPC se situe entre l'application et le réseau, et il peut donc refuser de relayer une transaction, ce que font les grands fournisseurs: les principaux fournisseurs centralisés filtrent les transactions impliquant des adresses de la liste de sanctions de l'OFAC américain, et certains fournisseurs excluent des pays entiers de l'accès. Vitalik Buterin a averti qu'un marché concentré sur quelques fournisseurs RPC subit une forte pression pour exclure ou censurer des utilisateurs.

Pour une entreprise européenne, cela joue dans les deux sens, et les deux ont leur place dans le dossier de risques. Le filtrage des sanctions, l'entreprise doit de toute façon le faire elle-même, si bien qu'un fournisseur qui filtre ne lui nuit pas sur ce plan. Mais un fournisseur qui applique la liste d'une juridiction au trafic d'une entreprise européenne lui impose une politique qu'elle n'a pas choisie et ne peut pas voir, et une transaction silencieusement non relayée est une défaillance opérationnelle qui ressemble à un problème de réseau. La seconde exposition concerne l'information: chaque requête indique au fournisseur les adresses qui intéressent l'entreprise. Pour un gestionnaire d'actifs, ce sont des données de positions, et un fournisseur qui voit les transactions en attente peut aussi agir sur leur ordre.

Deux endpoints de deux fournisseurs sont la réponse évidente, et c'est plus difficile qu'il n'y paraît, car la défaillance qui compte n'est pas un endpoint qui renvoie une erreur. Un endpoint qui répond depuis un nœud en retard de plusieurs blocs sur la tête de la chaîne renvoie une réponse valide avec des données obsolètes, et une application qui ne vérifie que les erreurs HTTP l'accepte.

Un basculement qui fonctionne signifie donc que l'application compare la hauteur de bloc d'une réponse à ce qu'elle attend, traite un endpoint en retard comme défaillant et bascule vers le second fournisseur. Le basculement signifie aussi que le second fournisseur est testé en charge avant d'être nécessaire, et que l'entreprise sait quelles requêtes la solution de repli ne peut pas servir, en général les requêtes archive et les abonnements. Une solution de repli qui n'a jamais porté de trafic de production est un plan et non un contrôle.

Une entreprise réglementée qui dépend d'un fournisseur RPC pour une fonction importante a un accord avec un tiers prestataire de TIC, et les obligations découlent de ce fait et non du montant de la facture. L'accord figure dans le registre d'informations avec la fonction qu'il soutient et l'indication du caractère critique ou important de cette fonction, le contrat doit contenir les clauses d'audit, d'accès et de sortie qu'attend DORA, et l'entreprise a besoin d'une réponse testée à la disparition du fournisseur.

La difficulté est que les conditions standard du marché n'ont pas été écrites pour cela. Une inscription en libre-service avec une carte de crédit n'est pas un contrat qui donne des droits d'audit à un superviseur, et une entreprise dont l'accès à la chaîne repose sur une telle inscription a une lacune documentaire, pas une lacune technique. La page sur le règlement DORA en Allemagne traite la supervision allemande, et celle sur la résilience opérationnelle numérique en Europe le cadre européen.

Seulement en exploitant le nœud soi-même, et votre propre équipe d'exploitation remplace alors le fournisseur. Il n'y a pas de troisième option: quelque chose doit détenir une copie de la chaîne et répondre aux requêtes, et soit l'entreprise l'exploite, soit quelqu'un d'autre le fait. La question utile n'est donc pas de savoir s'il faut dépendre d'un fournisseur, mais quelle dépendance l'entreprise peut documenter et dont elle peut se remettre, et la plupart des entreprises concluent qu'un nœud propre pour les requêtes dont elles répondent plus un fournisseur pour la couverture est la combinaison qu'elles peuvent défendre.

Six questions, et les réponses ont leur place dans le contrat. L'endpoint est-il dédié ou partagé. Les requêtes archive sont-elles incluses et jusqu'à quelle profondeur. Quelles limites de débit s'appliquent par méthode, car la requête de logs est celle qui casse. Le fournisseur filtre-t-il des transactions et selon quelles listes. Où les nœuds sont-ils hébergés et sous quelle juridiction. Enfin, sur quel retard maximal de ses nœuds par rapport à la tête de la chaîne le fournisseur s'engage-t-il, le niveau de service qui compte réellement et le moins souvent proposé.