El desarrollador de Hazync informa que un verificador independiente de 1.7 MB verificó un recibo criptográfico de 226,434 bytes que cubre los primeros 1,789 bloques de Bitcoin en 27 milisegundos. La divulgación del 15 de agosto limita ese resultado a un período temprano de la historia de Bitcoin. Una campaña de prueba completa desde el génesis hasta el final sigue sin finalizar.
Hazync es un prototipo de investigación que utiliza la máquina virtual de conocimiento cero de RISC Zero, o zkVM, para hacer que la validación de Bitcoin sea reutilizable. El zkVM ejecuta el programa de validación, y el recibo resultante proporciona a otros usuarios un archivo compacto para verificar. El diseño del desarrollador concentra la generación de pruebas entre los probadores y deja la verificación de recibos a una población mucho más grande.
Esos dos trabajos tienen costos radicalmente diferentes. El desarrollador estima aproximadamente 17 años de GPU para el relleno histórico, seguido de una capacidad equivalente a aproximadamente seis GPUs Nvidia L40S para mantener el ritmo con los nuevos bloques. Las verificaciones de recibos económicas llegan después de que los probadores, auditores y operadores de archivo hayan proporcionado el trabajo costoso aguas arriba.
Un nuevo nodo de Bitcoin convencional reproduce independientemente la cadena. Hazync ejecuta las reglas de Bitcoin dentro del zkVM, prueba que esas reglas aceptaron cada bloque cubierto y pliega recursivamente las pruebas de bloques en un solo recibo.
El repositorio público de Hazync describe un programa invitado construido a partir de partes sustanciales del código de consenso de Bitcoin Core v28 y libsecp256k1, compilado para RISC-V de 32 bits. Reutilizar el código de Core reduce la cantidad de comportamiento de consenso que debe ser declarado en un circuito separado.
El punto de referencia del bloque 741,000 mide el costo de generación de pruebas en datos recientes de Bitcoin. El desarrollador informa que el bloque contenía 670 entradas y requería 394 hojas UTXO. Probarlo en 16 fragmentos a través de dos GPUs L40S tomó aproximadamente 55 minutos, incluidos 27 minutos para la agregación.
Esa medición informa la estimación del desarrollador de aproximadamente 17 años de GPU para un relleno desde el génesis hasta el final. El material disponible proporciona puntos de referencia representativos del proyecto en lugar de una medición auditada a través de cada era de la historia de Bitcoin. Por lo tanto, el rendimiento de la cadena completa de Hazync sigue siendo una estimación hasta que se complete la campaña.
Los cambios de software también pueden borrar el trabajo completado. Cada recibo de Hazync se compromete a un METHOD_ID, una huella digital del programa invitado compilado. Una nueva compilación de invitado recibe un nuevo identificador, dejando los recibos anteriores vinculados a la versión anterior.
El proyecto reinició su tablero de génesis el 4 de agosto después de que una auditoría interna obligara a un nuevo punto de referencia. Una posterior corrección de solidez podría desencadenar el mismo reinicio después de que se haya acumulado mucho más tiempo de GPU. Por lo tanto, el presupuesto de prueba abarca código estable, el relleno histórico y capacidad continua para el final.
La velocidad de verificación es la parte visible para el usuario final. La estimación de 17 años de GPU mide el esfuerzo industrial concentrado requerido para producir esa experiencia.
Un recibo comprime la verificación de validez. Los operadores de archivo aún suministran la disponibilidad de transacciones y retienen los bytes de testigos y firmas históricos. Las futuras revisiones de invitados necesitan esos bytes para probar la cadena nuevamente, por lo que la verificación sucinta preserva un papel de almacenamiento a largo plazo para la infraestructura de archivo.
La selección de la mejor cadena permanece con la regla de mayor trabajo de Bitcoin. Hazync coloca el trabajo acumulado en la salida pública del recibo, dando a un verificador el valor necesario para comparar puntas competidoras. El recibo establece el cumplimiento de las reglas para su segmento de cadena; el nodo aún elige qué cadena válida seguir.
Un puente de archivo también retiene el poder de desperdiciar recursos de probadores. Las reglas de composición declaradas del proyecto conectan cada límite de estado al pin de génesis, causando que un estado forjado falle cuando un recibo se une a la columna vertebral. Un puente hostil puede, en cambio, servir entradas inutilizables y consumir el tiempo de GPU de un trabajador, convirtiendo la disponibilidad en un riesgo económico de denegación de servicio.
El desarrollador describe una prueba compuesta desde el génesis como incondicional dentro del software y las suposiciones criptográficas de Hazync. Un punto de control posterior ingresa al sistema como una entrada de confianza explícita.
El invitado en sí contiene un límite de revisión importante, ya que un código de consenso sustancial de Core se ejecuta dentro de él, junto con partes mantenidas por el proyecto para el cronograma de subsidios y las alturas de activación de scripts. El proyecto dice que su cronograma de banderas de script se prueba diferencialmente como un superconjunto sólido de las reglas de Core, permitiendo un rechazo adicional en la dirección destinada a preservar la solidez.
Una capa de portabilidad en C++ adapta Core para el zkVM, y un acumulador Utreexo no Core compromete cambios en el conjunto de salidas de transacciones no gastadas de Bitcoin. Las suposiciones divulgadas también cubren el sistema de pruebas de RISC Zero, SHA-256 y secp256k1. Hazync identifica los adaptadores de portabilidad y el acumulador como sus objetivos de revisión residual de mayor prioridad.
El repositorio informa de dos revisiones externas asistidas por IA en agosto que no lograron encontrar un camino para que el invitado aceptara una cadena inválida. Una auditoría profesional encargada sigue pendiente. El código público permite el escrutinio externo, y la garantía de producción aún descansa en el examen adversarial del invitado exacto y cada componente dentro de su límite de prueba.
Hazync divide la sincronización sin confianza en varios trabajos con diferentes operadores y presupuestos. La verificación de recibos puede alcanzar milisegundos para un rango probado. La generación de pruebas consume capacidad de GPU, los operadores de archivo retienen los datos subyacentes, los nodos comparan puntas y los auditores evalúan el invitado.
Una implementación estable con suficiente capacidad de cálculo y revisión externa podría reducir la validación repetida a través de nuevos nodos. En la etapa actual del proyecto, la verificación de 27 milisegundos reportada por el desarrollador cubre una columna vertebral limitada, mientras que la estimación de 17 años de GPU describe el camino inacabado hacia el final de Bitcoin.
Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.





























