Versiones y actualizaciones

ZooBC cambia su software sin cambiar su cadena. Las nuevas versiones se anuncian en la propia cadena, cada nodo las instala mediante un actualizador que controla su propietario, y las nuevas reglas de consenso solo se activan cuando dos tercios de los productores ya las ejecutan. Nadie puede imponer software a un nodo, y una nueva versión nunca necesita una cadena nueva.

El registro de versiones

La autoridad de versiones, una clave nombrada en el génesis de la cadena, registra cada versión con RegisterRelease (tipo 32): una cadena de versión, un hash de manifiesto de 32 bytes (la huella de los archivos de la versión) y una dirección de la versión. Una versión se registra por arquitectura y por cadena, y su cadena de versión nombra ambas. Una cadena de versión solo puede registrarse una vez, así que una corrección necesita una versión nueva, y una versión revocada no puede volver nunca. La autoridad también puede revocar una versión (tipo 35) y ceder su papel a otra clave, lo que requiere dos pasos: proponer (tipo 33) y aceptar (tipo 34).

Las plazas registradas ejercen un control sobre esa clave:

• Veto. Cuando dos tercios de las plazas registradas atestiguan «veto» para una versión, esta queda revocada exactamente como si la hubiera revocado la autoridad: los nodos que se actualizan solos la omiten y el instalador la rechaza. Las plazas suspendidas quedan fuera del recuento, así que con 11 plazas activas el veto necesita 8. Cada voto es una atestación sin comisión firmada con la clave de nodo, y los operadores la emiten ellos mismos; nada vota automáticamente.
• Sustitución. Un voto que nombra una nueva autoridad de versiones solo se cuenta cuando su voto más antiguo tiene una semana (40 320 bloques), de modo que el titular actual lo ve venir. Con dos tercios, el papel pasa a la dirección votada.

Un registro o una revocación es orientativo. Guía a los nodos cuyos propietarios eligieron actualizarse solos; a un operador que ejecuta el binario que él mismo elige no le afecta. Cualquiera puede comprobar una versión descargada contra el registro (comprobar un archivo descargado).

El actualizador

El instalador de ZooBC añade un pequeño actualizador que se ejecuta junto al nodo, no dentro de él. Se ejecuta por primera vez 15 minutos después de que arranca la máquina y luego aproximadamente cada 10 minutos (con 2 de margen arriba o abajo). Cada vez pide al nodo local /api/v1/release/list y busca la versión registrada y no revocada más reciente para su cadena y su tipo de máquina (amd64 o arm64) que sea más nueva que la que está en marcha.

El actualizador instala esa versión solo cuando le toca: en la altura de registro de la versión, más el retraso de actualización, más el turno propio de este nodo. Entonces descarga la versión, comprueba su firma y su hash de manifiesto contra la cadena, la instala junto a la versión en marcha, reinicia el nodo y ejecuta una comprobación de estado. Si la comprobación falla, vuelve a la versión anterior, y reintenta una actualización fallida al cabo de 12 horas.

• El retraso es de 2 días (11 520 bloques) por defecto en mainnet. Cada nodo fija el suyo, y la autoridad de versiones no puede acortarlo. Deja tiempo para revocar una versión defectuosa antes de que se extienda.
• Los turnos ordenan los nodos por clave y reparten sus horas de inicio de modo que, por defecto, como máximo 2 nodos empiecen una actualización en un mismo bloque. La cadena nunca pierde muchos productores a la vez.
• El interruptor del propietario, auto_update, vale on (el valor por defecto), off o chain. Con chain, el actualizador sigue un ajuste que el propietario firma en la cadena desde la billetera, de modo que puede activar o desactivar las actualizaciones sin iniciar sesión en el servidor.

A todo operador se le avisa cuando existe una versión más nueva: el actualizador, incluso desactivado, la nombra junto con el estado de su umbral de preparación, el nodo escribe un aviso diario en su registro, la ruta /node/info del nodo lo indica, la billetera web muestra un aviso y el explorador muestra la versión de cada nodo.

El umbral de preparación

Las nuevas reglas de consenso llegan en una versión como un paquete, con un id de paquete mayor que 0. Cada bloque lleva la versión del software de su productor, y el umbral de preparación la lee. Las reglas del paquete se activan, en todos los nodos a la vez, en la primera altura que cumple todo esto:

• está en la altura programada del paquete o después, y al menos 5760 bloques (un día) después del registro de la versión;
• al menos dos tercios de las plazas registradas (redondeando hacia arriba, sin contar las suspendidas) han producido cada una un bloque con una versión igual o superior al id del paquete dentro de la ventana de señalización, que es la mayor entre 720 bloques y 5 bloques por nodo;
• la versión no ha sido revocada; una revocación detiene un paquete pendiente.

A partir de esa altura, los bloques con una versión anterior se rechazan. Un nodo que no se actualizó no tiene periodo de gracia: pierde sus turnos, no gana nada y pierde puntuación desde su primer turno rechazado (turnos perdidos, suspensión y expulsión). Por eso se avisa a los operadores de cada nueva versión.

Como se cuentan productores y no bloques, una minoría aislada del resto no puede alcanzar los dos tercios por sí sola. Tampoco ninguna clave puede forzar la activación: la autoridad de versiones no firma ningún mensaje de activación, y una altura por sí sola nunca decide mientras los productores no se hayan movido. El umbral tiene límites conocidos: no tiene fecha límite, así que algo más de un tercio de las plazas puede frenar una actualización, y no detecta una versión defectuosa, que es para lo que sirven el retraso y el veto.

Las cadenas lanzadas con la versión 0.5.8 tienen sus 121 reglas de consenso activas desde el bloque 0, y ninguna regla va en un paquete, así que el umbral empieza a importar con una versión posterior. Un nodo también se niega a arrancar si su binario sitúa la activación de una regla en un lugar distinto del que registra la cadena, y una versión puede incluir un pin de versión que la ata a un bloque de la spine conocido.

Véase también

• Operar un nodo
• Comprobar un archivo descargado
• El pin de versión
• Las reglas de los dos tercios
• La ZooBC Foundation