Kaspa prépare le hard fork Toccata

Kaspa demande à ses opérateurs de se préparer au hard fork Toccata, programmé sur le mainnet au score DAA 474,165,565, soit autour du 30 juin 2026 à 16 h 15 UTC selon le guide officiel du dépôt rusty-kaspa. Le projet présente la version v2.0.1 comme une mise à jour utilisable à la fois pour les nœuds déjà passés sur v2.0.0 et pour ceux qui viennent encore de la branche 1.x. Le message principal est simple : les opérateurs d’infrastructure doivent mettre à jour avant l’activation, car une modification de consensus peut séparer les nœuds non préparés du reste du réseau.

Toccata n’est pas seulement une opération de maintenance. Le guide rattache le hard fork à plusieurs propositions KIP, avec deux objectifs techniques mis en avant : ajouter une forme de programmation native par covenants au niveau L1 et préparer l’infrastructure nécessaire à des applications fondées sur des preuves ZK. Un covenant est une contrainte inscrite dans la logique de dépense d’une sortie, par exemple pour limiter ce qui peut être fait avec des fonds dans une transaction future. Dans Kaspa, l’enjeu est de rendre ce type de règle exploitable sans déplacer toute la logique vers une couche externe.

La partie la plus concrète concerne les intégrateurs. Le guide indique que les wallets et logiciels de soumission de transactions doivent éviter les anciennes hypothèses de frais fixes. Après Toccata, la règle de frais minimum standard passe à 100 sompi par gramme, avec une formule qui tient compte des grammes de calcul et de la taille de transaction. Les logiciels qui utilisent l’estimation de frais du nœud devraient suivre automatiquement, mais les services qui calculent eux-mêmes les frais doivent s’adapter. Les API changent aussi de vocabulaire : le champ mass devient storageMass ou storage_mass, même si une compatibilité temporaire subsiste côté JSON.

Pour les pools, explorateurs et plateformes d’échange, le risque n’est donc pas théorique. Il faut tester les dépôts, retraits, templates de blocs, indexation, calcul de soldes et parsage des transactions sur Testnet-10 avant le basculement. Kaspa rappelle aussi que la mise à niveau de base de données du nœud est à sens unique : revenir à une version antérieure peut obliger à resynchroniser. Le signal est intéressant parce qu’il montre un réseau proof-of-work qui tente d’ajouter des capacités de programmation plus riches tout en exposant très tôt les contraintes opérationnelles. La nouveauté technique ne vaut que si l’écosystème sait l’absorber sans casser ses outils.