Skip to main content
La chaîne entérine des blocs. Les applications posent des questions du type quelles ont été les exécutions de ce compte la semaine dernière ou à quoi ressemble le carnet en ce moment — des questions auxquelles un enregistrement en forme de blocs répond mal. L’indexeur est ce qui convertit l’un en l’autre. Sur la plupart des chaînes, l’indexeur est une infrastructure critique : la chaîne émet des événements opaques et des tiers en reconstruisent le sens, de sorte que ce que croit votre application dépend de l’indexeur auquel elle fait confiance. Ici, l’étape de reconstruction n’existe pas. Le noyau émet une sortie typée et attribuée — chaque changement d’état est déjà lié à la transaction qui l’a causé — si bien que l’indexeur reformate les données au lieu de les déduire. Cela change ce à quoi sert l’indexeur. C’est une couche de service, pas une source de vérité. Tout ce qu’il rapporte peut être confronté à la chaîne, et un désaccord est un bug de l’indexeur plutôt qu’une question ouverte.

​
Le chemin

réparti par âge
Nœud completblocs entérinés, en flux typé
Cacherécent — en mémoire
Stockage fichiershistorique — durable
Service de donnéesprésente les deux en un flux
Passerelle → REST · WebSocketaccès, quotas, routage
Pourquoi la séparationSuivre la tête est sensible à la latence et léger ; l’historique est sensible au débit et lourd. Un rattrapage sur un chemin partagé bloquerait le flux en direct.
Couche de service, pas source de véritéLe noyau émet une sortie typée et attribuée : l’indexeur reformate au lieu de déduire. Un désaccord avec la chaîne est un bug de l’indexeur.
Un nœud complet est l’origine. Les enregistrements de trading en sortent en flux, sous forme de données typées, plutôt que de transactions brutes à interpréter. Le cache et le stockage fichiers partagent le flux selon l’âge. Les données récentes sont servies depuis la mémoire, parce que c’est ce que veut la majorité des consommateurs et que la latence compte. Les données historiques sont écrites dans un stockage fichiers durable, parce que tout garder en mémoire n’est pas une stratégie. Un consommateur qui demande quelque chose d’ancien et un consommateur qui suit la tête de chaîne sont servis depuis des endroits différents sans que ni l’un ni l’autre s’en aperçoive. Le service de données présente les deux comme un flux unique. Un client demande une plage commençant n’importe où ; savoir si cette plage est servie depuis le cache, depuis les fichiers ou depuis les deux n’est pas son problème. La passerelle prend en charge ce qui se joue entre un service et l’internet public : accès, quotas et routage. Les surfaces REST et WebSocket sont ce que les applications utilisent réellement — données de marché, historique des ordres et des exécutions, positions, état du compte, paiements de financement et abonnements en direct. Voir la référence de l’API pour le détail au niveau des endpoints.

​
Pourquoi cette séparation existe

Un service unique qui suivrait à la fois la tête de chaîne et répondrait aux requêtes historiques ferait mal les deux. Suivre la tête est sensible à la latence et porte sur peu de données ; les requêtes historiques sont sensibles au débit et portent sur beaucoup, et un seul gros rattrapage bloquerait le chemin temps réel. Les séparer permet d’alimenter un nouveau consommateur depuis plusieurs mois en arrière sans dégrader le flux d’un market maker qui suit la tête, et de dimensionner les deux indépendamment — ce dont ils ont besoin, car leurs profils de charge n’ont rien en commun.

​
Ce sur quoi on peut s’appuyer sans risque

Sans risque. Tout ce que l’indexeur sert et qui dérive de blocs entérinés : exécutions, ordres, positions, paiements de financement, transferts, données de marché. Ce sont des reformatages de la sortie de la chaîne. Pas la même chose. Tout ce qui n’est pas encore entériné. Un ordre accepté dans le mempool n’a pas été séquencé, et l’indexeur n’a rien à en dire. Une absence dans l’indexeur signifie pas-encore-entériné, pas rejeté. Vérifiable. Si une réponse compte assez — un litige de règlement, un audit, un rapprochement comptable — elle peut être confrontée directement à la chaîne plutôt que prise dans l’indexeur. Faire tourner votre propre nœud complet en est la forme la plus forte, et c’est ce que devrait faire un participant qui ne peut pas se permettre de se tromper. Voir Faire tourner un nœud.
Deux consommateurs qui lisent la même plage entérinée devraient obtenir la même réponse. Si ce n’est pas le cas, l’écart se situe dans le chemin de service et constitue un bug à signaler — ce n’est pas une propriété inhérente à la lecture d’une chaîne à travers un indexeur.

​
Pour aller plus loin

Modèle d’état

Ce que lit l’indexeur, et quelle représentation fait autorité.

Développeurs

Les surfaces REST et WebSocket, les SDK et les outils.

Faire tourner un nœud

Vérifier vous-même contre la chaîne, et pourquoi l’ensemble est fermé.

Services de programme

Ce qui consomme ce flux pour calculer l’état dérivé des comptes.