Pruning della cronologia

Una catena che conserva ogni blocco per sempre fa pagare a ogni nodo la memorizzazione di tutta la sua cronologia. I nodi ZooBC invece fanno pruning: sotto un orizzonte legato agli snapshot, cancellano blocchi vecchi, transazioni, righe del registro contabile, ricevute e versioni superate dei record. Lo stato attuale, come saldi, seggi del registro e righe di dataset, non viene eliminato in questo modo; solo la cronologia vecchia lo è. Un nodo in funzione su mainnet detiene da 30 a 60 giorni di blocchi.

L'orizzonte

Ogni 172.800 blocchi (circa 30 giorni) su mainnet, ogni nodo scrive uno snapshot dello stato (snapshot e fast sync). L'orizzonte di pruning è la più vecchia delle due altezze di riferimento degli snapshot più recenti. Con un solo snapshot, è quell'altezza meno un intervallo, e nulla viene eliminato prima che esista un manifest di snapshot. Dalla versione 0.5.8 l'orizzonte non può mai superare una formula pura che ogni nodo condivide:

horizon(h) = floor(h ÷ interval) × interval − interval

Con un intervallo di 172.800 blocchi, l'orizzonte resta indietro rispetto alla punta da uno a due intervalli. All'altezza 500.000, per esempio, l'orizzonte è al massimo 172.800, quindi il nodo conserva almeno i 327.200 blocchi più recenti, circa 57 giorni. Dopo lo snapshot successivo, a 518.400, l'orizzonte sale di un intervallo e restano circa 30 giorni.

Altri due limiti rendono il pruning graduale. I 1.440 blocchi più recenti (6 ore) non vengono mai eliminati, qualunque cosa dica l'orizzonte, e un nodo rimuove al massimo 500 righe per tabella per blocco, così il lavoro viene distribuito.

Che cosa resta sotto l'orizzonte

Alcuni blocchi vengono conservati per quanto vecchi siano:

• il blocco 0;
• ogni blocco che contiene una transazione il cui record di longevità ha ancora denaro, conservato insieme a quella transazione;
• le transazioni finanziate al momento dello snapshot più recente, mantenute un intervallo in più così che lo snapshot possa portarle con sé.

Gli snapshot portano con sé quelle transazioni finanziate e le intestazioni dei loro blocchi, quindi anche un nodo che entra a partire da uno snapshot le detiene.

Altri orologi

Il pruning non è l'unica regola con una durata, e i numeri si confondono facilmente:

Il limite di rollback dice fino a dove la catena può riorganizzarsi; non cancella nulla.

Conservare di più

• Un operatore può impostare keep_all_history in node.conf per conservare localmente la cronologia eliminata. È una scelta locale, non il comportamento predefinito.
• Chiunque può pagare per conservare una transazione con un deposito di longevità.
• I nodi di archivio eseguono un servizio di indicizzazione accanto a un nodo e servono l'explorer (explorer e i nodi di archivio).
• L'archiviazione decentralizzata conserva ogni snapshot dal blocco 0, con le porzioni di ogni snapshot su cinque nodi registrati scelti a sorte, così che lo stato a qualsiasi snapshot passato possa essere ricostruito senza che alcun nodo conservi tutti i blocchi (archivio e la lettura del passato).

Lo stato si riduce con il canone

Il pruning della cronologia lascia intatto lo stato attuale. Lo stato si riduce in un altro modo, tramite il canone. Un account che non può pagare il suo canone viene eliminato, le righe di dataset il cui canone non viene pagato vengono disattivate, e un file archiviato il cui deposito si esaurisce viene eliminato. In ogni caso il denaro rimasto va al pool di longevità, e nessuno ZBC va perso.

Vedi anche

• Pagare per conservare i dati (longevità)
• Snapshot e fast sync
• L'archivio e la lettura del passato
• Canone degli account e pruning
• Finalità e rollback