L’explorateur et les nœuds d’archivage
L’explorateur ZooBC permet à n’importe qui de parcourir les blocs, les transactions, les comptes et les nœuds, de rechercher d’anciens messages de transaction et de consulter des statistiques quotidiennes. L’essentiel de ces données ne vient pas d’un nœud ordinaire, mais d’un service d’archivage : un programme distinct qui s’exécute à côté d’un nœud enregistré et tient un index consultable de l’historique de la chaîne.
Ce que conserve un nœud ordinaire
Un nœud ordinaire conserve l’état courant (soldes, enregistrements, registre) et une fenêtre récente de blocs : une à deux périodes d’instantané, soit 30 à 60 jours sur le mainnet. Cela suffit pour valider la chaîne et pour aider de nouveaux nœuds à la rejoindre à partir d’un instantané (instantanés et synchronisation rapide). Les blocs, transactions et reçus plus anciens sont élagués (élagage de l’historique), ce qui garde les nœuds légers. Un opérateur qui souhaite conserver localement l’historique élagué peut définir keep_all_history dans node.conf.
En conséquence, un nœud seul ne peut répondre ni à « toutes les transactions depuis le bloc 0 », ni à une recherche en texte intégral dans les messages.
Le service d’archivage
Le service d’archivage, zoobc-archival-api, comble cette lacune. Un nœud dont l’opérateur définit archival_node = true le démarre et le supervise. Le service lit la base de données SQLite propre au nœud et tient un index des blocs et des transactions dans un stockage MySQL, ce qui lui permet de répondre aux demandes d’historique, de chronologies de comptes, de statistiques et de recherche. Outre des versions d’archivage des routes ordinaires, il sert des routes qui lui sont propres :
| Route | Ce à quoi elle répond | |
|---|---|---|
/search/transactions | recherche dans les transactions, y compris leurs messages | |
/stats/… | statistiques du réseau | |
/spine/blocks | les blocs de la [[spine-chain | chaîne dorsale]] |
/network/map | une carte du réseau | |
/archive/stats | statistiques sur l’archive elle-même |
Un détail compte pour les développeurs qui comparent des réponses : le service d’archivage écrit les valeurs hexadécimales en majuscules, alors que le nœud les écrit en minuscules.
Le déclarer sur la chaîne
Le propriétaire d’un nœud enregistré déclare un service d’archivage avec RegisterArchival (type 46). La clé de nœud indiquée doit appartenir à un nœud enregistré détenu par l’expéditeur. Aucune mise n’est bloquée, et UnregisterArchival (type 47) retire l’entrée. N’importe qui peut lister les services déclarés à GET /api/v1/registry/archivals, et le portefeuille web lit cette liste lorsque sa passerelle tombe en panne.
L’explorateur
L’explorateur est une page web servie par les passerelles. Il est construit sur les routes d’archivage : blocs, transactions, comptes, nœuds, dorsale, statistiques et recherche. Une passerelle envoie chaque lecture API d’abord à son service d’archivage et se rabat sur un nœud pour les routes que le service d’archivage n’a pas. L’explorateur affiche aussi la version logicielle de chaque nœud, ce qui permet aux opérateurs et aux observateurs de voir qui a fait la mise à jour (versions et mises à jour).
Tout cela relève des données publiques de la chaîne : une clé est nécessaire pour agir sur la chaîne, jamais pour la consulter (API du nœud).
Pas le seul moyen de lire le passé
Un service d’archivage est une commodité, pas la mémoire de la chaîne.
C’est le stockage décentralisé, et non chaque nœud, qui conserve chaque instantané depuis le bloc 0, afin que n’importe qui puisse remonter la chaîne dorsale jusqu’à l’instantané d’une date donnée et reconstruire l’état tel qu’il était, sans dépendre d’aucun nœud d’archivage (archive et la lecture du passé).
Ce que les services d’archivage ne font pas : ils ne produisent pas de blocs, ce que seuls les nœuds enregistrés font, et il n’existe aucune base de données centrale de la ZooBC Foundation à laquelle les nœuds feraient rapport. Les relais transportent des appels entre portefeuilles, pas des transactions (relais).