Kaspa vise 100 blocs par seconde : DAGKnight, ZK et VProgs

En 2026, Kaspa a cessé d’être « juste » un réseau de paiements rapide. Après que le hard fork Crescendo a porté le réseau à 10 blocs par seconde en 2025, la mise à jour Toccata a ajouté des contrats intelligents natifs, des tokens KRC-20 et la vérification à connaissance nulle (ZK) fin juin 2026. Cela laisse la question que tout suiveur du projet se pose réellement : et après ? La réponse est trois points : DAGKnight, la montée à 100 blocs par seconde et VProgs, plus un écosystème de couche 2 qui prend forme, non sans friction. Voici ce que préparent les prochaines mises à jour, et ce qu’elles ne prouvent pas encore.

Où en est Kaspa fin 2026 ?

Kaspa est une cryptomonnaie PoW construite sur un BlockDAG, un graphe orienté acyclique dans lequel plusieurs blocs valides coexistent en parallèle plutôt que de se concurrencer, grâce au protocole GHOSTDAG. Le résultat est un débit élevé sans sacrifier la décentralisation. Le réseau fonctionne à 10 blocs par seconde depuis le hard fork Crescendo (2025), rendu possible par la réécriture du logiciel en Rust.

Le tournant récent est Toccata. Activée fin juin 2026, cette mise à jour a transformé Kaspa d’une chaîne de paiements rapide en une couche 1 programmable : contrats natifs via les conventions, tokens KRC-20 intégrés au protocole, opcodes de vérification ZK et compilateur SilverScript pour faciliter le développement. Côté marché, le KAS se négociait autour de 0,035 dollars le 18 septembre 2026 (capitalisation proche du milliard), avec un lancement équitable, pas de pré-minage, et une émission proche de la fin de sa courbe. La base technique est donc en place ; la suite consiste à la faire vivre.

DAGKnight : le prochain saut en consensus

C’est la mise à jour la plus attendue. DAGKnight (DK) est un protocole de consensus de nouvelle génération, tiré d’un article de recherche de 2022 par les chercheurs Kaspa Michael Sutton et Yonatan Sompolinsky, conçu pour étendre ou remplacer GHOSTDAG. Sa caractéristique distinctive : il est « sans paramètres » et adaptatif. Là où le système actuel repose sur des hypothèses fixes sur la latence réseau, DAGKnight s’ajuste dynamiquement aux conditions réelles, ce qui devrait permettre une finalité plus rapide (temps cible des blocs de l’ordre de 25 à 40 millisecondes) et une meilleure résilience aux perturbations, avec une tolérance aux pannes byzantines jusqu’à 50 %.

Selon la feuille de route publiée par le projet, DAGKnight devrait être livré avec un pont ZK entre couche 1 et couche 2 dans un seul hard fork. Le calendrier, toutefois, invite à la prudence : initialement envisagé pour le troisième trimestre 2026, il est désormais plus souvent mentionné pour 2026-2027, et l’équipe reconnaît que le sujet a été repoussé après l’effort Crescendo. À retenir : DAGKnight est structurel, mais c’est aussi le jalon dont la date a le plus bougé.

Vers 100 blocs par seconde

Kaspa n’a pas l’intention de s’arrêter à 10 blocs par seconde. La feuille de route prévoit une augmentation progressive du débit, par paliers (environ 25, puis 40, et enfin 100 blocs par seconde), ciblée pour un hard fork en 2027, avec des mécanismes de résilience conçus pour que les paiements continuent de fonctionner même en cas de partition réseau. La logique est une montée en charge « horizontale » : plutôt que d’augmenter la taille de chaque bloc, le réseau traite plus de blocs en parallèle. Si elle aboutit, cette montée en débit ferait descendre les confirmations vers la seule limite de la latence internet.

VProgs : contrats natifs et composables

Encore au stade de recherche, VProgs (« programmes virtuels ») visent à donner à Kaspa des contrats intelligents natifs capables de s’exécuter en parallèle tout en restant composables de manière synchrone, un point délicat pour la finance décentralisée et les applications complexes. L’objectif déclaré est d’offrir une programmabilité à grande échelle sans rompre le modèle de performance du BlockDAG. C’est un travail de fond approfondi, plutôt attendu en 2027, à suivre plus comme une orientation qu’une échéance précise.

Igra et Kasplex : la couche application prend forme

Parallèlement au protocole, l’écosystème Layer 2 se met en place. Des projets comme Igra (un Layer 2 compatible EVM construit sur le BlockDAG de Kaspa) et Kasplex font mûrir la couche application, avec les tokens KRC-20 comme premier terrain d’essai. L’idée est familière mais cohérente : la couche 1 fournit la vitesse, la sécurité et le règlement, tandis que les Layer 2 hébergent une partie de l’activité applicative. C’est cette combinaison, une base rapide plus un écosystème actif, qui déterminera si la programmabilité récemment ajoutée se transforme en usage réel. C’est aussi, pour l’instant, là où se concentrent les risques.

L’envers du décor : l’exploit Kasplex et l’avertissement de Shai Wyborski

Fin septembre 2026, une vulnérabilité de contournement de signature dans l’indexeur off-chain des tokens KRC-20 de Kasplex a permis à des attaquants de frapper, sans posséder les clés privées, 186 millions de tokens ZEAL et environ 54,4 milliards de NACHO, via la couche EVM d’Igra Labs et le Layer 2 Kasplex, avant de les vendre sur le DEX Zealous Swap. Selon des médias spécialisés (KuCoin, ChainCatcher), la valeur des pools affectés a chuté de 94 % à 99,6 %. Point crucial pour la précision : le consensus Layer 1 de Kaspa et les actifs non bridgés n’ont pas été touchés, la faille se situant dans un composant Layer 2 plutôt que dans le protocole de base. Igra a suspendu les retraits iKAS, et Zealous Swap a déclaré devoir corriger et réindexer son indexeur.

C’est dans ce contexte qu’il faut lire le post public de Shai Wyborski (@DesheShai). Pour rappel : co-auteur des recherches PHANTOM et GHOSTDAG qui sont le socle de Kaspa, docteur en cryptographie quantique, et première contributeur du projet. Depuis avril 2026, il s’était éloigné et exprimait publiquement sa défiance envers une partie de l’écosystème. Selon la couverture du média CaptainAltcoin, il pointait la rivalité entre trois projets de programmabilité (le ZK-EVM de Kasplex, Igra et les vProgs de l’équipe core), reprochait aux leaders core (Michael Sutton et Yonatan Sompolinsky) leur hostilité envers Igra, jugeait que Kasplex cachait des détails de protocole et des frais, et craignait que la dépendance au financement de Kaspa Eco Foundation (KEF) et des rancunes personnelles orientent les décisions au détriment de la communauté. Sa formulation traduisait sa position : il ne peut pas travailler avec des personnes en qui il n’a pas confiance.

Après l’exploit, Wyborski a soutenu que ses avertissements se matérialisaient, affirmant avoir signalé maintes fois la nécessité de régler les problèmes de sécurité avant tout lancement, et qualifiant brusquement KEF d’imprudente et Kasplex de mauvais projet. Ce sont ses opinions, exprimées publiquement ; elles visent des entités de l’écosystème (KEF, Kasplex, Igra) distinctes du Layer 1 de Kaspa, et les parties concernées communiquent sur l’incident de leur côté. Notamment, il n’a pas rayé le protocole de base, dont il a loué la performance ailleurs.

À surveiller (et les mises en garde)

Une note d’honnêteté s’impose. La feuille de route de Kaspa est crédible et son historique d’exécution réel (Crescendo, puis Toccata, ont été livrés), mais trois mises en garde subsistent. 

• Premièrement, les délais glissent : DAGKnight est l’exemple, repoussé plusieurs fois. 
• Deuxièmement, avoir la capacité n’est pas la même chose que l’utiliser : plusieurs analyses notent que l’activité on-chain reste faible par rapport au débit disponible, un cas classique du « construisez-le et ils viendront » dont l’issue n’est pas assurée. 
• Troisièmement, comme l’exploit Kasplex et la critique interne le rappellent, la sécurité et la gouvernance de l’écosystème Layer 2 sont des travaux en cours à part entière, distincts de la solidité du Layer 1.

La bonne manière de suivre Kaspa n’est donc pas de viser un prix, mais de vérifier trois choses : l’atterrissage effectif des branches DAGKnight et ZK dans le dépôt de développement, la matérialisation de la demande applicative sur Layer 1 et Layer 2, et la manière dont l’écosystème corrige ses défauts et clarifie sa gouvernance. La prochaine étape technique vérifiable sera que le travail DAGKnight et le pont ZK atteignent le testnet, puis s’activent via hard fork.

Cet article est informatif et ne constitue pas un conseil en investissement. Les marchés cryptos sont volatiles ; les chiffres cités sont datés et évoluent vite. Les calendriers des mises à jour sont indicatifs et sujets à glissement. Les déclarations attribuées à des personnes nommées sont leurs remarques publiques ; la présomption d’innocence et de bonne foi s’applique aux entités mentionnées.

Millycrypto

Créatrice de contenu spécialisée dans les cryptomonnaies et le Web3. Je décrypte l'actualité du marché, les nouveaux protocoles et les usages on-chain pour rendre l'écosystème accessible au plus grand nombre.