Utreexo

Anna quiere enviar a Peter bitcoin que recibió antes. Por eso su transacción hace referencia a ese pago anterior. Cada registro de un importe y de las condiciones para gastarlo se llama salida; mientras no se gaste, es un UTXO. Una entrada de la nueva transacción contiene una referencia a esa salida anterior y los datos necesarios para gastarla. El nodo debe comprobar que el registro existe y que Anna no lo ha gastado ya. Normalmente mantiene el UTXO set, una base de todas las salidas actualmente sin gastar, no de cuentas personales con saldos. Su crecimiento aumenta el trabajo del disco. Thaddeus Dryja presentó Utreexo en 2019 como una forma de reducir esa carga local. [1] [6] [8]

Primero se calcula el hash de cada registro: una huella breve de sus datos. En un árbol de Merkle, las huellas se emparejan y se vuelven a calcular sus hashes hasta llegar a la huella superior, la raíz. Utreexo utiliza varios de estos árboles; el nodo verificador puede guardar sus raíces en lugar de la lista completa. Para la salida de Anna recibe los datos y una prueba con las huellas vecinas necesarias. Así recalcula el camino hasta la raíz y compara el resultado con el estado que ya sigue. La afirmación del remitente no basta. Esta estructura se llama acumulador criptográfico: permite demostrar que un registro pertenece a un conjunto. Las raíces no son una copia de seguridad comprimida. No pueden descomprimirse para recuperar todos los registros originales. [1] [2]

Se calcula el hash de los datos recibidos y la prueba permite comprobar su vínculo con el estado que sigue el nodo. No se puede aceptar una prueba inválida simplemente porque proceda de un servidor conocido. Una firma digital acredita la autorización de un pago mediante una clave privada, un valor numérico secreto, sin revelar esa clave. Un script es un conjunto de condiciones que deben cumplirse para gastar una salida. Incluso una prueba de pertenencia válida no sustituye la verificación de firmas, scripts, importes y demás reglas de la transacción y del bloque. Utreexo cambia el almacenamiento del estado, no autoriza a omitir esas comprobaciones. [2] [5] [8]

Alguien debe seguir conservando suficientes datos para construir las pruebas. La documentación de la biblioteca distingue al prover, que guarda el bosque completo de árboles, del verifier, al que le bastan las raíces. El verificador puede almacenar algunas pruebas en caché, pero las raíces por sí solas no permiten generar cualquier prueba. Los datos no desaparecen: cambia su distribución entre participantes. [2]

Un bloque agrupa transacciones en un lote que se añade al historial compartido. Al gastarse una salida, se elimina del conjunto registrado, mientras se añaden las nuevas salidas sin gastar. Las pruebas también cambian. Una prueba guardada para un estado anterior puede necesitar una actualización después de nuevos bloques. En una reorganización, la red adopta otra rama válida de la cadena y sustituye parte del historial de bloques anterior. La implementación debe gestionar la actualización de pruebas, transacciones simultáneas y retrocesos durante una reorganización de la cadena. No es un certificado que se descarga una vez y sirve para siempre. [2] [3]

Un Pruned Node descarta datos de bloques antiguos después de validarlos, pero tradicionalmente conserva la base UTXO actual. Utreexo se centra en esa base. Son ahorros diferentes que pueden combinarse. Ni la poda ni un acumulador pequeño significan, por sí solos, que el nodo haya verificado el pasado sin procesarlo. El historial de bloques, el estado actual y el método de verificación inicial son tres cosas distintas. [6] [5]

Imagina un nodo nuevo que empieza con un resumen del estado proporcionado por otro, en vez de comprobar los bloques desde el principio. Asume que ese estado inicial es correcto. Un acumulador pequeño no elimina esa confianza: las pruebas posteriores se contrastan precisamente con el estado aceptado. Por eso, en AssumeUTXO se distingue la aceptación de un snapshot, una instantánea del estado en un momento dado, de la posterior validación histórica en segundo plano. La documentación de utreexod describe un inicio predeterminado desde un estado fijado en el programa. Eso por sí solo no es verificar de forma independiente todos los bloques anteriores. El modo de arranque es una decisión separada, no una propiedad inherente a Utreexo. [7] [3]

Existe la implementación utreexod, que utiliza Utreexo para validar la red Bitcoin. Al revisarla el 17 de octubre de 2026, su documentación la describe como beta y desaconseja manejar sumas relevantes en mainnet. También indica --noassumeutreexo para desactivar el inicio desde un estado supuesto. Esto no es una recomendación de instalación: antes de usarla hay que comprobar la versión actual, el modo, la procedencia del software y las opciones de recuperación. [3]

El diseño básico no exige reescribir las reglas monetarias de Bitcoin ni modificar bloques existentes. Sin embargo, alguien debe crear, transmitir y actualizar las pruebas, por lo que los nodos participantes necesitan software y comunicación adecuados. Reducir el estado local puede ayudar a equipos más económicos. No implica automáticamente más transacciones por bloque, menores comisiones para todos ni que todos los nodos adopten un nuevo formato. [1] [4]

Menos datos en disco pueden significar más tráfico de red y dependencia de su disponibilidad a tiempo. Un nodo que valida correctamente rechaza las pruebas falsificadas. Aun así, un proveedor puede no entregar los datos necesarios y retrasar la validación. Por eso se compara el conjunto: almacenamiento, transferencias, caché, verificación del estado inicial y comportamiento ante caídas. Utreexo puede abaratar la validación propia; no vuelve irrelevante la falta de datos. [3] [4]