El explorador y los nodos de archivo
El explorador de ZooBC permite a cualquiera recorrer bloques, transacciones, cuentas y nodos, buscar mensajes de transacciones antiguas y leer estadísticas diarias. La mayor parte de eso no proviene de un nodo normal, sino de un servicio de archivo: un programa separado que se ejecuta junto a un nodo registrado y mantiene un índice consultable del historial de la cadena.
Lo que conserva un nodo normal
Un nodo normal conserva el estado actual (saldos, registros, el registro de nodos) y una ventana reciente de bloques: uno o dos periodos de instantánea, es decir, de 30 a 60 días en mainnet. Eso basta para validar la cadena y para ayudar a nodos nuevos a incorporarse a partir de una instantánea (instantáneas y sincronización rápida). Los bloques, las transacciones y los recibos más antiguos se podan (poda del historial), lo que mantiene ligeros los nodos. Un operador que quiera conservar en local el historial podado puede poner keep_all_history en node.conf.
La consecuencia es que un nodo por sí solo no puede responder a «todas las transacciones desde el bloque 0», ni a una búsqueda de texto completo en los mensajes.
El servicio de archivo
El servicio de archivo, zoobc-archival-api, cubre ese hueco. Un nodo cuyo operador pone archival_node = true lo arranca y lo supervisa. El servicio lee la propia base de datos SQLite del nodo y mantiene un índice de bloques y transacciones en un almacén MySQL, de modo que puede responder sobre el historial, las cronologías de las cuentas, las estadísticas y las búsquedas. Además de versiones de archivo de las rutas normales, sirve las suyas propias:
| Ruta | Qué responde | |
|---|---|---|
/search/transactions | búsquedas en las transacciones, incluidos sus mensajes | |
/stats/… | estadísticas de la red | |
/spine/blocks | los bloques de la [[spine-chain | cadena spine]] |
/network/map | un mapa de la red | |
/archive/stats | estadísticas sobre el propio archivo |
Un detalle importa a los desarrolladores que comparan respuestas: el servicio de archivo escribe los valores hexadecimales en mayúsculas, mientras que el nodo los escribe en minúsculas.
Declararlo en la cadena
El propietario de un nodo registrado declara un servicio de archivo con RegisterArchival (tipo 46). La clave de nodo nombrada debe pertenecer a un nodo registrado propiedad del remitente. No se bloquea ningún stake, y UnregisterArchival (tipo 47) retira la entrada. Cualquiera puede listar los servicios declarados en GET /api/v1/registry/archivals, y la billetera web lee esa lista cuando su pasarela falla.
El explorador
El explorador es una página web que sirven las pasarelas. Está construido sobre las rutas de archivo: bloques, transacciones, cuentas, nodos, la spine, estadísticas y búsqueda. Una pasarela envía cada lectura de la API primero a su servicio de archivo y, si no, pasa a un nodo para las rutas que le faltan al servicio de archivo. El explorador muestra también la versión del software de cada nodo, para que operadores y observadores vean quién se ha actualizado (versiones y actualizaciones).
Todo ello son datos públicos de la cadena: hace falta una clave para actuar en la cadena, nunca para mirarla (API del nodo).
No es la única forma de leer el pasado
Un servicio de archivo es una comodidad, no la memoria de la cadena.
El almacenamiento descentralizado, y no cada nodo, conserva todas las instantáneas desde el bloque 0, de modo que cualquiera puede seguir la cadena spine hacia atrás hasta la instantánea de un momento dado y reconstruir el estado tal como era, sin depender de ningún nodo de archivo (archivo histórico y la lectura del pasado).
Lo que no hacen los servicios de archivo: no producen bloques, algo que solo hacen los nodos registrados, y no existe ninguna base de datos central de la ZooBC Foundation a la que informen los nodos. Los relays transportan llamadas entre billeteras, no transacciones (relays).