Cet article est basé sur l’article de @ michaelsuttonil « Kaspa Covenants++ ‘Toccata’ Hard-Fork Outlook. »
Il présente les éléments clés du hard fork dans un format structuré, avec un contexte et des commentaires supplémentaires pour aider à expliquer comment les éléments s’emboîtent et ce que cela pourrait signifier pour les utilisateurs.
Kaspa entre dans une nouvelle phase. Le prochain hard fork « Toccata » introduit la programmabilité au réseau de manière structurée et délibérée, tout en gardant la couche de base stable et prévisible. Cet article tente de passer en revue ce qui est introduit, comment il se déploie et ce qu’il permet dans la pratique.
Ce qu’apporte Toccata
Michael souligne que ce hard fork introduit deux chemins de programmabilité :
• Un nouveau compilateur pour les scripts L1, appelé Silverscript
• Infrastructure pour les applications basées sur zk, construite sur des bases contractuelles.
Ces systèmes sont conçus pour fonctionner à partir de la même couche de base sous-jacente.
La double structure de la programmabilité
Michael décrit la programmabilité de Kaspa comme reposant sur deux piliers.
1. Programmation native des alliances L1
Ceci est intégré directement au moteur de script de Kaspa.
Il le décrit ainsi :
• destiné aux applications peer-to-peer
• capable de « flux multi-contrats avec état complexes »
• fondé sur le calcul UTXO local
Silverscript est en cours de finalisation pour rendre ce système plus facile et plus sûr à déployer.
2. Applications zk basées
Cette couche comprend :
• Opcodes de vérification zk
• séquencement de l’accès aux engagements
• l’architecture d’engagement de séquençage partitionné (KIP-21)
Michael explique que celles-ci, ainsi que les alliances, constituent le fondement de :
• Applications basées sur ZK
• pont canonique entre les couches
Il note également que ces applications suivent le séquençage L1 et ne peuvent pas ajouter ou supprimer de transactions.
Où cela s’inscrit-il dans la feuille de route
Michel écrit :
« C’est aussi une étape importante sur la route des vprogs (livre jaune) »
Il déclare également :
« Nous n’en sommes pas encore là. »
L’étape à laquelle il fait référence est celle des programmes vérifiables composables de manière synchrone (vprogs).
Il explique :
• l’accent est actuellement mis sur les applications zk autonomes
• ceux-ci communiquent via un pontage basé sur des preuves L1
• la composition synchrone fait partie d’une étape ultérieure
Il note également que la couche d’exécution vprogs est déjà en cours de développement, principalement par Hans Moog.
Ce qui est déjà mis en œuvre
Michael déclare qu’une partie substantielle du hard fork est déjà en place :
• KIP-17 : opcodes de moteur de script étendus, formant l’épine dorsale des clauses contractuelles.
• KIP-20 : identifiants d’alliance, permettant le suivi de la lignée
• KIP-16 : opcodes zk et sous-système de vérification
Le système zk prend actuellement en charge :
• un vérificateur Groth16 flexible
• un vérificateur RISC Zero STARK, actif sur testnet 12, avec une décision en attente pour le réseau principal
Également inclus :
• Opcode d’accès à l’engagement de séquençage
Il mentionne également les travaux de preuve de concept terminés :
• Clauses zk en ligne
• des clauses zk basées sur un pont KAS canonique
Pourquoi le séquençage des engagements est important (KIP-21)
Michael explique que les applications zk doivent prouver des coûts qui évoluent en fonction de leur propre activité, plutôt qu’en fonction de l’ensemble du DAG.
Cela permet aux applications zk de fonctionner d’une manière qui reste pratique à mesure que le réseau se développe.
KIP-21 est conçu pour répondre à cette exigence.
Ce qui est en train d’être finalisé maintenant
** Gel des fonctionnalités prévu : 15 avril 2026**
Éléments en cours de finalisation :
• Politiques tarifaires des moteurs de script
• Examen du KIP-21
• Prise en charge de l’engagement de sous-réseau et de gaz
Cette étape se concentre sur le verrouillage des interfaces avant de passer au réseau principal.
Pourquoi la date du réseau principal a été déplacée
Ciblé initialement : 5 mai 2026
Mise à jour : ~du 5 au 20 juin 2026
Michael explique que l’architecture d’engagement de séquençage devait être finalisée correctement avant l’activation, en particulier pour les systèmes zk. Une fois que les circuits et les temps d’exécution zk se lient à cette structure, les changements structurels ultérieurs deviendraient rompus. Le temps supplémentaire est utilisé pour finaliser cette conception avant le lancement.
Le chemin vers le réseau principal
Michael décrit la séquence de déploiement :
1. Gel des fonctionnalités (15 avril 2026)
2. Redémarrez TN12 en tant que réseau de test propre avec toutes les fonctionnalités finales
3. Fusionner la branche de développement de longue durée dans master
4. Travail final d’audit, de nettoyage et de logique d’activation
5. Simulez une transition complète via un hard fork sur TN10
6. Finalisez et codez en dur la date d’activation du réseau principal
Il souligne que la répétition du TN10 est l’étape clé avant le réseau principal.
Les étapes après le gel des fonctionnalités ne sont pas assignées à des dates spécifiques. Ils se déroulent dans l’ordre, le calendrier dépendant de la réussite des tests et de l’intégration.
L’activation du réseau principal est attendue dans une fenêtre allant du **~5 juin au 20 juin 2026** et n’est finalisée qu’une fois la répétition complète de la transition terminée de manière satisfaisante.
Des notes de version détaillées, comme toujours, seront disponibles et l’équipe d’assistance pourra vous aider dans toute intégration sur demande.
État de préparation de l’écosystème
Michael décrit un impact opérationnel simple :
• Mise à niveau des opérateurs de nœuds
• Les fonctionnalités existantes continuent de fonctionner
• L’utilisation du disque peut augmenter d’environ 20 à 50 %
Pour les développeurs :
• De nouveaux SDK et API prendront en charge les nouvelles fonctionnalités.
• Les API existantes continuent de fonctionner
• L’outillage continuera d’évoluer après le fork
Le noyau de Kaspa a également l’intention de prendre en charge l’adoption via des compilateurs, des SDK et des environnements d’exécution.
Ce qui n’est pas inclus dans cette étape
Michael ne présente pas ce hard fork comme la forme finale de la programmabilité de Kaspa.
Il déclare explicitement :
• le réseau n’est pas encore au niveau des vprogs, décrits comme des programmes vérifiables composables de manière synchrone
• L’accent est actuellement mis sur les applications zk autonomes, et non sur la composition entièrement synchrone.
Aucun calendrier pour l’achèvement des vprogs n’est donné dans cet article.
Pourquoi le nom « Toccata »
Michael introduit le nom dans le cadre de la tradition de dénomination musicale de Kaspa.
Une toccata est une composition associée à l’expression et à la portée techniques.
Le nom reflète une phase où le système commence à prendre en charge un comportement plus expressif.
(Un commentaire plus approfondi sur la pertinence de ce nom est à venir)
Pourquoi c’est important
Cette section reflète ce que ces capacités pourraient permettre dans la pratique.
👩🏻💻Développeurs
• Possibilité de définir des flux de transactions avec des règles exécutoires
• Accès direct aux scripts L1 via des contrats
• Base pour la création d’applications zk alignées sur le séquençage L1
💳Marchands
• Paiements qui suivent des conditions définies
• Flux structurés tels que paiements échelonnés ou libération conditionnelle
• Coordination assurée au niveau de la transaction
🏢Entreprises et institutions
• Flux d’actifs avec des règles définies et une traçabilité vérifiable
• Systèmes basés sur une logique de transaction partagée et vérifiable
• Chemins d’intégration pour les applications basées sur zk et le pontage
⛏️Mineurs et opérateurs de nœuds
• Participation continue avec des nœuds mis à niveau
• Capacités réseau étendues
• Modèle opérationnel similaire avec une augmentation modérée des ressources
🙋🏽Utilisateurs quotidiens
• Transactions incluant des conditions et une structure
• Interaction avec des applications qui coordonnent plusieurs étapes
• Actifs avec une origine et un historique de mouvement plus clairs
En termes simples
Toccata introduit deux formes de programmabilité sur Kaspa construites sur la même base :
• Programmation native des alliances L1
• Applications basées sur zk qui suivent le séquençage L1
À partir de cette base, les transactions peuvent comporter des règles définies et suivre des chemins structurés, permettant ainsi aux applications de coordonner la valeur sur plusieurs étapes avec des résultats imposés par le réseau lui-même.
Beaucoup de ces éléments existent aujourd’hui dans l’industrie. Mais c’est en les réunissant au niveau de la couche de base, avec un traitement parallèle, une logique de convention et des systèmes zk alignés sur le séquençage L1, que ce développement et cette voie future peuvent distinguer Kaspa.