Release e aggiornamenti

ZooBC cambia il proprio software senza cambiare la propria catena. Le nuove versioni vengono annunciate sulla catena stessa, ogni nodo le installa tramite un programma di aggiornamento controllato dal suo proprietario, e le nuove regole di consenso si attivano solo quando due terzi dei produttori le eseguono già. Nessuno può imporre software a un nodo, e una nuova versione non richiede mai una nuova catena.

Il registro delle release

L'autorità di release, una chiave indicata nella genesi della catena, registra ogni release con RegisterRelease (tipo 32): una stringa di versione, un hash del manifest di 32 byte (l'impronta dei file della release) e un indirizzo della release. Una release viene registrata per architettura e per catena, e la sua stringa di versione indica entrambe. Una stringa di versione può essere registrata una sola volta, quindi una correzione richiede una nuova versione, e una versione revocata non può mai tornare. L'autorità può anche revocare una release (tipo 35) e cedere il proprio ruolo a un'altra chiave, in due passi: proposta (tipo 33) e accettazione (tipo 34).

I seggi registrati esercitano un controllo su quella chiave:

• Veto. Quando due terzi dei seggi registrati attestano «veto» per una versione, questa viene revocata esattamente come se l'avesse revocata l'autorità: i nodi ad aggiornamento automatico la saltano e l'installer la rifiuta. I seggi sospesi sono esclusi dal conteggio, quindi con 11 seggi attivi il veto ne richiede 8. Ogni voto è un'attestazione senza commissione firmata con la chiave del nodo, e sono gli operatori a esprimerlo; nulla vota automaticamente.
• Sostituzione. Un voto che indica una nuova autorità di release viene conteggiato solo quando il suo voto più vecchio ha una settimana (40.320 blocchi), così chi detiene il ruolo lo vede arrivare. Raggiunti i due terzi, il ruolo passa all'indirizzo votato.

Una registrazione o una revoca ha valore indicativo. Orienta i nodi i cui proprietari hanno scelto l'aggiornamento automatico; un operatore che esegue un binario di sua scelta non ne viene toccato. Chiunque può verificare una release scaricata rispetto al registro (verificare un file scaricato).

Il programma di aggiornamento

L'installer di ZooBC aggiunge un piccolo programma di aggiornamento che gira accanto al nodo, non al suo interno. Si avvia la prima volta 15 minuti dopo l'accensione della macchina, poi circa ogni 10 minuti (2 in più o in meno). Ogni volta chiede al nodo locale /api/v1/release/list e cerca la release registrata e non revocata più recente per la sua catena e il suo tipo di macchina (amd64 o arm64) che sia più nuova di quella in esecuzione.

Il programma di aggiornamento installa quella release solo quando è il momento: all'altezza di registrazione della release, più il ritardo di aggiornamento, più lo slot proprio di questo nodo. A quel punto scarica la release, ne verifica la firma e l'hash del manifest rispetto alla catena, la installa accanto alla versione in esecuzione, riavvia il nodo ed esegue un controllo di salute. Se il controllo fallisce torna alla vecchia versione, e ritenta un aggiornamento fallito dopo 12 ore.

• Il ritardo è di 2 giorni (11.520 blocchi) per impostazione predefinita su mainnet. Ogni nodo fissa il proprio, e l'autorità di release non può accorciarlo. Lascia il tempo di revocare una release difettosa prima che si diffonda.
• Gli slot ordinano i nodi per chiave e ne distribuiscono gli orari di avvio in modo che, per impostazione predefinita, al massimo 2 nodi avviino un aggiornamento nello stesso blocco. La catena non perde mai molti produttori tutti insieme.
• L'interruttore del proprietario, auto_update, è on (il valore predefinito), off o chain. Con chain, il programma di aggiornamento segue un'impostazione che il proprietario firma sulla catena dal wallet, così il proprietario può attivare o disattivare gli aggiornamenti senza accedere al server.

Ogni operatore viene avvisato quando esiste una release più recente: il programma di aggiornamento, anche se disattivato, la indica insieme allo stato della sua soglia di prontezza, il nodo scrive un avviso giornaliero nel suo log, la route /node/info del nodo la segnala, il wallet web mostra un banner e l'explorer mostra la versione di ogni nodo.

La soglia di prontezza

Le nuove regole di consenso arrivano in una release come pacchetto, con un id di pacchetto maggiore di 0. Ogni blocco porta la versione del software del suo produttore, e la soglia di prontezza la legge. Le regole del pacchetto si attivano, su tutti i nodi contemporaneamente, alla prima altezza che soddisfa tutte queste condizioni:

• è uguale o successiva all'altezza prevista per il pacchetto, e almeno 5.760 blocchi (un giorno) dopo la registrazione della release;
• almeno due terzi dei seggi registrati (arrotondati per eccesso, esclusi i seggi sospesi) hanno prodotto ciascuno un blocco con una versione pari o superiore all'id del pacchetto entro la finestra di segnalazione, che è la maggiore tra 720 blocchi e 5 blocchi per nodo;
• la release non è stata revocata; una revoca ferma un pacchetto in attesa.

Da quell'altezza in poi, i blocchi con una versione più vecchia vengono rifiutati. Un nodo che non si è aggiornato non ha alcuna tolleranza: salta i suoi turni, non guadagna nulla e perde punteggio dal primo turno rifiutato (turni mancati, sospensione ed espulsione). È per questo che gli operatori vengono avvisati di ogni nuova release.

Poiché si contano i produttori e non i blocchi, una minoranza isolata dal resto della rete non può raggiungere da sola i due terzi. Nessuna chiave può nemmeno forzare l'attivazione: l'autorità di release non firma alcun messaggio di attivazione, e un'altezza da sola non decide mai finché i produttori non si sono mossi. La soglia ha limiti noti: non ha una scadenza, quindi poco più di un terzo dei seggi può frenare un aggiornamento, e non intercetta una release difettosa, compito per cui esistono il ritardo e il veto.

Le catene avviate con la versione 0.5.8 hanno tutte le loro 121 regole di consenso attive dal blocco 0, e nessuna regola fa parte di un pacchetto, quindi la soglia diventa rilevante solo con una release successiva. Un nodo si rifiuta inoltre di partire se il suo binario colloca l'attivazione di una regola in modo diverso da quanto registrato dalla catena, e una release può includere un pin della release che la lega a un blocco spine noto.

Vedi anche

• Gestire un nodo
• Verificare un file scaricato
• Il pin della release
• Le regole dei due terzi
• La ZooBC Foundation