Le développeur de Hazync rapporte qu’un vérificateur autonome de 1,7 Mo a vérifié un reçu cryptographique de 226 434 octets couvrant les 1 789 premiers blocs de Bitcoin en 27 millisecondes. La divulgation du 15 août limite cela à une première partie de l’histoire de Bitcoin. Une campagne complète de preuve de la genèse à la pointe reste inachevée.
Hazync est un prototype de recherche qui utilise la machine virtuelle à connaissance nulle de RISC Zero, ou zkVM, pour rendre la validation Bitcoin réutilisable. Le zkVM exécute le programme de validation et le reçu résultant donne aux autres utilisateurs un fichier compact à vérifier. La conception du développeur concentre la génération des preuves parmi les prouveurs et laisse la vérification des reçus à une population beaucoup plus large.
Ces deux emplois ont des coûts radicalement différents. Le développeur estime qu’il faudra environ 17 années-GPU pour le remplissage historique, suivi d’une capacité équivalente à environ six GPU Nvidia L40S pour suivre le rythme des nouveaux blocs. Les chèques de réception bon marché arrivent après que les vérificateurs, les auditeurs et les opérateurs d’archives ont fourni en amont le travail coûteux.
La vérification est bon marché ; prouver coûte cher
Un nouveau nœud Bitcoin conventionnel rejoue indépendamment la chaîne. Hazync exécute les règles de Bitcoin dans le zkVM, prouve que ces règles acceptent chaque bloc couvert et replie de manière récursive les preuves de bloc en un seul reçu.
Le référentiel public Hazync décrit un programme invité construit à partir de parties substantielles du code de consensus de Bitcoin Core v28 et de libsecp256k1, compilé pour RISC-V 32 bits. La réutilisation du code de Core réduit la quantité de comportements consensuels qui doivent être reformulés dans un circuit séparé.
Le benchmark du bloc 741 000 mesure le coût de génération de preuves sur les données Bitcoin récentes. Le développeur rapporte que le bloc contenait 670 entrées et nécessitait 394 feuilles UTXO. Le prouver sous forme de 16 morceaux sur deux GPU L40S a pris environ 55 minutes, dont 27 minutes pour l’agrégation.
Cette mesure éclaire l’estimation du développeur d’environ 17 années GPU pour un remplissage de la genèse à la pointe. Le matériel disponible fournit des références représentatives du projet au lieu d’une mesure auditée à chaque époque de l’histoire du Bitcoin. Les performances de Hazync sur l’ensemble de la chaîne restent donc une estimation jusqu’à la fin de la campagne.
Les modifications logicielles peuvent également effacer le travail terminé. Chaque reçu Hazync s’engage sur un METHOD_ID, une empreinte digitale du programme invité compilé. Une nouvelle version invitée reçoit un nouvel identifiant, laissant les reçus antérieurs liés à la version précédente.
Le projet a redémarré son comité de genèse le 4 août après qu’un audit interne ait imposé une nouvelle référence. Un correctif de solidité ultérieur pourrait déclencher la même réinitialisation après que beaucoup plus de temps GPU se soit accumulé. Le budget de démonstration couvre donc le code stable, le remplissage historique et la capacité continue pour la pointe.
La vitesse de vérification est la partie visible par l’utilisateur final. L’estimation de 17 années GPU mesure l’effort industriel concentré requis pour produire cette expérience.
Ce que le reçu ne remplace pas
Un reçu compresse la vérification de la validité. Les opérateurs d’archives fournissent toujours la disponibilité des transactions et conservent les octets historiques des témoins et des signatures. Les futures révisions invitées ont besoin de ces octets pour prouver à nouveau la chaîne, donc une vérification succincte préserve un rôle de stockage à long terme pour l’infrastructure d’archives.
La sélection de la meilleure chaîne reste la règle du travail le plus important de Bitcoin. Hazync place le travail cumulé dans la sortie publique du reçu, donnant au vérificateur la valeur nécessaire pour comparer les conseils concurrents. Le reçu établit la conformité aux règles pour son segment de chaîne ; le nœud choisit toujours la chaîne valide à suivre.
Un pont d’archives conserve également le pouvoir de gaspiller les ressources du prouveur. Les règles de composition énoncées dans le projet relient chaque frontière d’état à l’épingle de genèse, provoquant l’échec de l’état falsifié lorsqu’un reçu rejoint la colonne vertébrale. Un pont hostile peut à la place servir des entrées inutilisables et consommer du temps GPU d’un travailleur, transformant la disponibilité en un risque économique de déni de service.
Le développeur décrit une preuve composée depuis la genèse comme inconditionnelle dans le cadre du logiciel et des hypothèses cryptographiques de Hazync. Un point de contrôle ultérieur entre dans le système en tant qu’entrée de confiance explicite.
L’invité lui-même contient une limite de révision importante, car un code consensuel de base important s’y déroule, ainsi que des tranches maintenues par le projet pour le calendrier de subvention et les hauteurs d’activation du script. Le projet affirme que son programme de script-flag est testé de manière différentielle en tant que sur-ensemble solide des règles de Core, permettant un rejet supplémentaire dans la direction destinée à préserver la solidité.
Une couche de portabilité C++ adapte Core pour le zkVM, et un accumulateur Utreexo non Core valide les modifications dans l’ensemble de sorties de transactions non dépensées de Bitcoin. Les hypothèses divulguées couvrent également le système de preuve de RISC Zero, SHA-256 et secp256k1. Hazync identifie les cales de portabilité et l’accumulateur comme ses cibles d’examen résiduelles les plus prioritaires.
Le référentiel rapporte deux examens externes assistés par l’IA en août qui n’ont pas réussi à trouver un moyen permettant à l’invité d’accepter une chaîne invalide. Un audit professionnel commandé reste en suspens. Le code public permet un examen externe, et l’assurance de la production repose toujours sur un examen contradictoire de l’invité exact et de chaque composant à l’intérieur de sa limite de preuve.
Hazync divise la synchronisation sans confiance en plusieurs tâches avec différents opérateurs et budgets. La vérification des reçus peut atteindre des millisecondes pour une plage éprouvée. La génération de preuves consomme de la capacité GPU, les opérateurs d’archives conservent les données sous-jacentes, les nœuds comparent les astuces et les auditeurs évaluent l’invité.
Une implémentation stable avec suffisamment de calcul et un examen externe pourrait réduire les validations répétées sur les nouveaux nœuds. Au stade actuel du projet, la vérification de 27 millisecondes rapportée par le développeur couvre une colonne vertébrale limitée, tandis que l’estimation de 17 années GPU décrit le chemin inachevé vers la pointe de Bitcoin.
