La poda del historial
Una cadena que conserva todos los bloques para siempre obliga a cada nodo a pagar por guardar todo su historial. Los nodos de ZooBC, en cambio, podan: por debajo de un horizonte ligado a las instantáneas, borran los bloques antiguos, las transacciones, las filas del libro contable, los recibos y las versiones superadas de los registros. El estado actual, como los saldos, las plazas del registro y las filas de dataset, no se poda de esta manera; solo el historial antiguo. Un nodo en funcionamiento en mainnet tiene de 30 a 60 días de bloques.
El horizonte
Cada 172 800 bloques (unos 30 días) en mainnet, cada nodo escribe una instantánea del estado (instantáneas y sincronización rápida). El horizonte de poda es la más antigua de las dos alturas de referencia de instantánea más recientes. Con una sola instantánea, es esa altura menos un intervalo, y no se poda nada antes de que exista un manifiesto de instantánea. A partir de la versión 0.5.8 el horizonte nunca puede adelantarse a una fórmula pura que comparten todos los nodos:
horizon(h) = floor(h ÷ interval) × interval − intervalCon un intervalo de 172 800 bloques, el horizonte va entre uno y dos intervalos por detrás de la punta. En la altura 500 000, por ejemplo, el horizonte está como mucho en 172 800, así que el nodo conserva al menos los 327 200 bloques más recientes, unos 57 días. Tras la siguiente instantánea, en 518 400, el horizonte sube un intervalo y quedan unos 30 días.
Dos límites más hacen que la poda sea suave. Los 1440 bloques más recientes (6 horas) nunca se podan, diga lo que diga el horizonte, y un nodo elimina como máximo 500 filas por tabla y bloque, así que el trabajo se reparte.
Lo que se queda por debajo del horizonte
Algunos bloques se conservan por antiguos que sean:
- el bloque 0;
- cada bloque que lleva una transacción cuyo registro de longevidad todavía tiene dinero, conservado junto con esa transacción;
- las transacciones financiadas según la instantánea más reciente, retenidas un intervalo más para que la instantánea pueda llevarlas.
Las instantáneas llevan esas transacciones financiadas y las cabeceras de sus bloques, así que un nodo que se incorpora a partir de una instantánea también las tiene.
Otros relojes
La poda no es la única regla con un plazo, y es fácil confundir las cifras:
| Qué | Cuánto tiempo, en mainnet |
|---|---|
| Bloques en un nodo en funcionamiento | de 30 a 60 días (uno o dos intervalos de instantánea) |
| Bloques que nunca se podan | los 1440 más recientes (6 horas) |
| Recibos | 518 400 bloques, unos 90 días (recibos y la topología de la red) |
| Ids de transacción | al menos 25 horas, más que la ventana de caducidad más larga, de un día (caducidad y marcas de tiempo) |
| Límite de reversión | 720 bloques, 3 horas (finalidad y reversión) |
El límite de reversión indica hasta dónde puede reorganizarse la cadena; no borra nada.
Conservar más
- Un operador puede poner
keep_all_historyen node.conf para conservar en local el historial podado. Es una elección local, no el comportamiento por defecto. - Cualquiera puede pagar por conservar una transacción con un depósito de longevidad.
- Los nodos de archivo ejecutan un servicio de indexación junto a un nodo y sirven el explorador (explorador y los nodos de archivo).
- El almacenamiento descentralizado conserva todas las instantáneas desde el bloque 0, con los trozos de cada instantánea en cinco nodos registrados elegidos por sorteo, para que el estado en cualquier instantánea pasada pueda reconstruirse sin que ningún nodo conserve todos los bloques (archivo histórico y la lectura del pasado).
El estado se recorta con el alquiler
La poda del historial no toca el estado actual. El estado se reduce de otra manera, mediante el alquiler. Una cuenta que no puede pagar su alquiler de cuenta se poda, las filas de dataset cuyo alquiler queda sin pagar se desactivan, y un archivo almacenado cuyo depósito se agota se poda. En cada caso, el dinero que queda va al fondo de longevidad, y no se pierde ningún ZBC.