Pearl 1.5.7 añade monitoreo del nodo y corrige un bloqueo de la red de pruebas
Publicación de la fuente: 2026-11-12 · Análisis editorial publicado: 2026-11-13
La versión del 12 de noviembre añade métricas opcionales y refuerza el manejo de mensajes entre nodos. El cambio de validación afecta a la red de pruebas.
Una versión para operadores de nodos y pools
Pearl Research Labs publicó v1.5.7 el 12 de noviembre. Incorpora monitoreo del nodo, refuerza el tratamiento de mensajes de otros nodos y corrige un punto donde la sincronización inicial podía atascarse en la red de pruebas. Un nodo verifica y comparte bloques; el programa minero hace los cálculos para encontrarlos. Si un pool prepara tareas con su propio nodo, el estado de ese nodo importa aunque los equipos indiquen la velocidad habitual.
Las notas describen cambios en el nodo y la red de pruebas. La versión no activa la propuesta FP8 en la cadena principal ni añade requisitos para las GPU. Si minas en un pool, sigue sus instrucciones de compatibilidad. Si operas el nodo que suministra el trabajo, las novedades afectan a cómo lo observas y mantienes.
Anota dos versiones. La de pearld indica qué programa comprobó los bloques; la del minero, cuál produjo la prueba. Las dos sirven al diagnosticar un pool. Actualizar un nodo puede facilitar la vigilancia o reducir interrupciones sin cambiar el trabajo de la tarjeta gráfica.
Qué muestran las métricas
El programa pearld puede ofrecer métricas a Prometheus, una herramienta que recoge mediciones a intervalos. Incluyen la altura y hora del último bloque, las conexiones con otros nodos, los tiempos de procesamiento y las peticiones al nodo. Se pueden comparar a lo largo del tiempo. Si los equipos calculan a su ritmo normal y el nodo va por detrás de una fuente independiente, conviene mirar primero el nodo y sus conexiones.
El punto de acceso está apagado hasta activarlo expresamente y no tiene autenticación propia. Déjalo en el servidor o en una red privada de monitoreo, con acceso limitado al recolector. Para escoger alertas, observa primero cómo se mueven los indicadores normalmente. Pocas conexiones o una petición lenta sirven como pista; por sí solas no prueban que el pool dejó de emitir trabajo útil.
Por ejemplo, compara cuándo recibió el nodo el último bloque con cuándo emitió el pool su siguiente trabajo. Si otro nodo ya avanzó y el tuyo conserva la altura antigua, empieza por ahí. Si tu nodo ve el nuevo bloque y los equipos siguen recibiendo tareas viejas, revisa la conexión entre el nodo y el pool. Cada evento requiere su propio registro.
También se mide el tiempo de procesar un bloque. Un nodo puede tardar con un bloque y luego alcanzar a la red. Una alerta que combine un retraso persistente con otras señales puede aportar más que un aviso por un solo bloque lento. Escoge síntomas que realmente interrumpan el trabajo del pool.
Por qué se atascaba la sincronización de prueba
El arreglo describe dos bloques, el 36 761 y el 36 762, cuyos certificados de minería tenían rango 64. El rango es un parámetro de las reglas de la prueba. El calendario anterior exigía al menos 128 desde el primero de esos bloques, así que un nodo nuevo podía rechazar el 36 761 y volver a pedirlo. La versión desplaza el inicio de la regla al bloque 36 763. La sincronización puede pasar los dos anteriores y después se conserva el mínimo.
La corrección se aplica a la red de pruebas afectada y no altera las reglas de la cadena principal. Un pool que prueba una compilación nueva puede arrancar un nodo de pruebas desde cero y comprobar que supera ambos bloques. Esto comprueba la sincronización; no dice cuánto gana una GPU en la cadena principal.
Los desarrolladores también indican que verificaron cabeceras históricas con los parámetros revisados de la red de pruebas. Es evidencia sobre este fallo concreto de validación. Si una instalación se atasca en otro punto, anota la última altura aceptada y la versión. Puede ser otro problema; un cambio en la red de pruebas no obliga a cambiar equipos de la principal.
Qué comprobar tras actualizar
La versión también limita cuánta memoria pueden hacer reservar algunos mensajes antes de que lleguen los datos. Restringe parte del procesamiento solicitado por pares de baja calidad y deja de usar sus marcas para desplazar la hora ajustada del nodo. Son cambios en la gestión del tráfico externo. Tras actualizar, mira si el nodo sigue recibiendo bloques y si el pool continúa emitiendo tareas nuevas y aceptando trabajo.
Anota la versión y configuración anteriores antes de cambiarlas. Comprueba el origen del lanzamiento y la versión que realmente está ejecutándose. El panel puede ayudarte a ver dónde empezó una parada. La comparación con una fuente independiente y los registros del pool permiten comprobar si el problema llegó a los mineros.
Para comprobar el despliegue, toma lecturas antes y después en condiciones parecidas. Observa si avanza la altura, se mantienen conexiones y el pool sigue aceptando trabajo. Si un tramo se detiene primero, guarda su registro para ese intervalo. Así será más fácil reproducir el incidente sin tratar cada variación breve como un fallo.
Fuente: Pearl Research Labs ↗ · Pearl — metrics implementation ↗ · Pearl — testnet sync fix ↗ · Pearl — network security changes ↗
Calculadora de minería ↗
