Para decidir si una transacción nueva es válida, un nodo no busca en toda la cadena de bloques. Consulta una tabla: el conjunto UTXO, la lista de cada moneda que existe y no se ha gastado.
Qué se guarda
Cada entrada se indexa por su outpoint (txid + índice de salida) y guarda el importe, el script de bloqueo, la altura del bloque que la creó y una bandera si vino de una transacción coinbase. En Bitcoin Core, esta base de datos se llama chainstate y vive en LevelDB en la carpeta chainstate.
Cómo la cambian los bloques
Cuando se conecta un bloque, se eliminan sus entradas gastadas y se añaden sus nuevas salidas. Bitcoin Core también guarda datos «undo» por cada bloque, así que si una reorganización quita un bloque, las monedas gastadas pueden devolverse.
Velocidad y memoria
Las consultas ocurren por cada entrada de cada transacción, así que la velocidad importa. Bitcoin Core cachea monedas en RAM, controlado por -dbcache. La versión 31.0 subió el valor por defecto de 450 MiB a 1.024 MiB en sistemas con al menos 4.096 MiB de RAM. Una caché mayor puede acelerar mucho la primera sincronización.
Tamaño
El conjunto UTXO es mucho más pequeño que la cadena completa, pero sigue siendo varios gigabytes en disco, y cada nodo completo debe mantenerlo entero. Cada salida nueva lo aumenta hasta gastarse, así que crear muchas salidas minúsculas tiene un coste para todos. Esa es una razón de los límites de dust.
Pruning
Un nodo podado puede borrar archivos de bloque antiguos, guardando tan poco como 550 MiB de ellos, pero debe mantener el chainstate completo. Los nodos podados siguen validando todo.
Instantáneas
Bitcoin Core puede exportar el conjunto con dumptxoutset. Con assumeutxo, un nodo nuevo puede cargar esa instantánea si su hash coincide con uno escrito en el código fuente, y luego comprobar la historia en segundo plano. Léelo en Initial block download.