Toccata Hard Fork de Kaspa : alliances, codes d'opération ZK et nouvel objectif de juin

KaspaLa prochaine mise à jour Toccata ajoutera deux nouvelles voies de programmabilité au réseau : la programmation native L1 et l'infrastructure d'applications à connaissance nulle (zk), l'activation du réseau principal étant désormais prévue entre le 5 et le 20 juin 2026, repoussée par rapport à la date cible initiale du 5 mai.

Michael Sutton de Kaspa Core a publié un mise à jour détaillée Ce document détaille le contenu de la bifurcation dure, les raisons du report de la date et les prévisions pour les prochains mois. Initialement initiée par Ori Newman, cette bifurcation visait à intégrer les covenants au moteur de script de Kaspa, notamment en réaction aux discussions autour d'OP_CAT dans la communauté Bitcoin. Elle a depuis pris une ampleur considérable.

Qu'est-ce que la fourchette à dents Toccata ?

Toccata est une mise à jour majeure (hard fork) du réseau Kaspa qui introduit de nouvelles fonctionnalités directement dans la couche de base. Pour rappel, une mise à jour majeure est une mise à niveau du protocole non rétrocompatible. Tous les nœuds doivent effectuer la mise à jour pour continuer à participer au réseau.

Ce nom s'inscrit dans la tradition de Kaspa, qui consiste à utiliser des références musicales pour ses mises à jour majeures. Celui-ci tire son nom d'une forme musicale classique, la toccata, une pièce conçue pour mettre en valeur la virtuosité technique sur un instrument à clavier.

Globalement, Toccata ajoute deux choses à Kaspa :

• Programmation native des accords L1 via un nouveau compilateur appelé Silverscript
• Infrastructure d'application basée sur zk, bâties sur ces mêmes fondements d'alliance

Ces systèmes ne sont pas interchangeables. Ils répondent à des cas d'utilisation différents et ciblent des publics de développeurs différents.

Que sont les alliances et pourquoi sont-elles importantes pour Kaspa ?

Les clauses contractuelles définissent les conditions d'utilisation des fonds issus d'une transaction. Dans une transaction Bitcoin ou Kaspa standard, une fois les cryptomonnaies envoyées, le destinataire peut en disposer librement. Les clauses contractuelles modifient ce comportement en intégrant des règles d'utilisation directement dans le script.

Kaspa utilise un modèle UTXO, similaire à Bitcoin, où chaque transaction consomme des sorties existantes et en crée de nouvelles. Les conventions (covenants) d'un système UTXO permettent aux développeurs de concevoir des flux multi-contrats avec état d'une complexité surprenante, même si les calculs sous-jacents restent locaux à chaque UTXO.

Pour faciliter le développement de covenants, Kaspa Core finalise Silverscript, un compilateur initié par Ori Newman, Michael Sutton, IzioDev et Manyfest. Silverscript est conçu pour simplifier et sécuriser l'écriture et le déploiement de covenants complexes directement sur Kaspa L1, sans que les développeurs aient à intervenir directement au niveau du moteur de script.

Que sont les applications ZK basées sur ce modèle ?

Le second pilier de programmabilité introduit dans Toccata repose sur les applications zk. Il est plus complexe techniquement et mérite d'être analysé en détail.

Découvrez des projets prometteurs...

Des projets prometteurs...

(Publicité)

L'article continue...

ZK signifie « preuve à divulgation nulle de connaissance », une méthode cryptographique permettant à une partie de prouver la véracité d'une information sans révéler les données sous-jacentes. Les preuves ZK sont de plus en plus utilisées pour la mise à l'échelle des blockchains car elles permettent de vérifier à moindre coût et en toute sécurité les calculs effectués hors chaîne.

Dans ce contexte, « basé » signifie que le système zk respecte intégralement le séquencement L1. Une application zk basée sur ce système ne peut ni ajouter ni supprimer de transactions de manière indépendante. Elle est ancrée à l'ordre des transactions de Kaspa, ce qui garantit sa fiabilité sans séquenceur externe.

Toccata introduit plusieurs composants pour soutenir cela :

• codes d'opération de vérification ZK, notamment un vérificateur Groth16 flexible et un vérificateur RISC Zero STARK
• Opcode d'accès à l'engagement de séquençage, permettant aux applications de base de s'ancrer à l'ordonnancement L1
• KIP-21, une architecture d'engagement de séquencement partitionnée qui garantit que les coûts de preuve d'une application zk évoluent en fonction de sa propre activité, et non de l'activité globale du DAG

Le vérificateur RISC Zero STARK est déjà implémenté et activé sur le réseau de test 12. Son activation sur le réseau principal est encore en cours de décision.

Pourquoi prouver les coûts est important

Pour qu'une application ZK soit viable, le coût de génération des preuves doit rester proportionnel à son activité. Si une application ZK devait prouver son travail par rapport à l'ensemble des activités du DAG, les coûts deviendraient imprévisibles et ingérables. KIP-21 résout ce problème en partitionnant les engagements de séquencement, ce qui permet à chaque application de gérer sa propre charge de travail.

Qu'est-ce qui est déjà en place ?

Une part importante de la mise à jour majeure est déjà implémentée. Les fonctionnalités suivantes sont déjà développées :

• Prise en charge étendue des opcodes du moteur de script, l'épine dorsale des conventions de base, dans le cadre de KIP-17
• Identifiants d'alliance pour la gestion des lignées en tant que fonctionnalité de consensus et de moteur, dans le cadre de KIP-20
• Opcodes ZK avec un sous-système de précompilation zk-verifier, sous KIP-16, rédigés par Alexander Safstrom
• Opcode d'accès à l'engagement de séquençage
• Le KIP-21, conçu par Sutton et mis en œuvre par Maxim Biryukov, est entièrement implémenté et en attente d'évaluation.

Maxim a également réalisé des étapes clés de validation de concept, notamment des accords zk intégrés et des accords zk basés sur un pont canonique KAS, qui ont joué un rôle déterminant dans la conception finale de la bifurcation.

Pourquoi la date du hard fork a-t-elle été repoussée à juin ?

La date de lancement initiale du réseau principal était le 5 mai 2026. Elle a depuis été reportée à la période du 5 au 20 juin 2026.

La raison est d'ordre architectural. Une fois que les circuits et les environnements d'exécution zk sont liés à une structure de hachage d'engagement de séquencement, toute modification structurelle ultérieure devient incompatible. Une conception erronée, suivie d'une correction a posteriori, serait bien plus perturbatrice que de prendre le temps nécessaire dès maintenant.

KIP-21 est conçu pour être compatible avec le système d'engagement qui sera requis par vprogs, la feuille de route à long terme de Kaspa pour les programmes vérifiables composables de manière synchrone. Définir la structure adéquate avant l'activation du réseau principal permet d'éviter des migrations coûteuses ultérieurement.

Le gel des fonctionnalités est prévu pour le 15 avril 2026.

Que se passe-t-il entre le gel des fonctionnalités et le réseau principal ?

Après le gel des fonctionnalités du 15 avril, Kaspa Core prévoit un redémarrage complet du réseau de test dédié TN12, intégrant l'ensemble des fonctionnalités finales. Il ne s'agit pas d'une simulation de la transition vers une bifurcation dure, mais d'un réseau vierge destiné à tester l'ensemble des fonctionnalités dans sa version finale.

L'équipe fusionnera ensuite le travail accumulé pendant des mois sur une branche en attente de longue durée avec le code source principal. Ce processus comprend un audit final, la résolution des problèmes en suspens, la mise au point de la logique d'activation des hard forks et la gestion de la mise à jour de la base de données.

Une fois ce travail terminé, une mise à jour de test (hard fork) sera exécutée sur TN10, le réseau de test à long terme, afin de simuler une transition complète vers le réseau principal. La date de lancement du réseau principal ne sera fixée qu'après que cette répétition générale aura été validée par l'équipe.

À quoi les opérateurs de nœuds doivent-ils s'attendre ?

Pour les mineurs et les opérateurs de nœuds, la mise à niveau se veut simple. Les nœuds doivent être mis à jour, mais les fonctionnalités existantes resteront opérationnelles. L'espace disque requis devrait augmenter d'environ 20 à 50 %. Aucun changement majeur d'infrastructure n'est prévu.

Ce que Toccata apporte réellement à Kaspa

Toccata ajoute deux systèmes de programmabilité fonctionnels à la couche de base de Kaspa : un système de scripts L1 natif via Silverscript et une infrastructure d'applications zk basée sur les KIP-16, KIP-20 et KIP-21. Une grande partie du travail technique est déjà réalisée. Il reste à finaliser les interfaces, à fusionner la branche en attente avec la branche principale et à effectuer une répétition générale sur TN10 avant la confirmation de la date de lancement sur le réseau principal.

La période du 5 au 20 juin 2026 est prévue car l'équipe a préféré optimiser l'architecture de séquencement dès le départ plutôt que de la corriger ultérieurement en production. Pour les opérateurs de nœuds, la mise à niveau se veut simple et ne nécessite aucune modification majeure de l'infrastructure, hormis une légère augmentation de l'espace disque.

Ressources

1. Kaspa sur X: Publication (avril 2026)

2. Article de blog de Michael Sutton: Kaspa Covenants++ « Toccata » Hard-Fork Outlook