vProgs Kaspa : ce que sont les programmes vérifiables et où en est la feuille de route

vProgs Kaspa : de quoi parle-t-on

Les vProgs, pour verifiable programs (programmes vérifiables), sont une architecture de programmes pour Kaspa, la blockchain en preuve de travail organisée en graphe de blocs (BlockDAG). Le projet a été exposé en août 2025 sur le forum de recherche de Kaspa par Yonatan Sompolinsky, alias hashdag, et Michael Sutton, dans un billet intitulé « Concrete proposal for a synchronously composable verifiable programs architecture ».

Le principe tient en une phrase des auteurs : chaque vProg est « en pratique une mini zkVM », une machine virtuelle à preuves à divulgation nulle de connaissance, qui inscrit et fait progresser son état sur la couche 1 (L1) par l'intermédiaire de son propre covenant. Le calcul se fait hors de la chaîne principale. La L1 ne réexécute pas les programmes : elle vérifie des preuves cryptographiques et ancre l'état de chaque programme.

Au 3 décembre 2025, date de la première version de cet article, les vProgs restaient un projet de recherche. Aucun programme vérifiable ne tournait alors sur le réseau principal.

Souveraineté et composabilité synchrone

La proposition repose sur deux notions. La première est la souveraineté : chaque vProg fixe ses propres paramètres, régule son débit et son état, et passe à l'échelle de façon indépendante. Selon le billet, les vProgs sont « mutuellement sans confiance » : un programme ne dépend jamais de l'exécution correcte ni de la disponibilité de l'état d'un autre.

La seconde est la composabilité synchrone. Une même transaction peut lire et modifier des comptes appartenant à plusieurs vProgs, de façon atomique, sans pont ni délai entre les programmes. Le modèle de comptes s'inspire de celui de Solana. C'est la différence revendiquée avec les rollups séparés, qui communiquent entre eux de façon asynchrone.

Prouveurs et « scope » : ce que dit le texte

Chaque vProg dispose de son propre ensemble de prouveurs, « idéalement sans permission », qui font avancer son état en soumettant des preuves à la L1. Les prouveurs peuvent produire des preuves partielles sur leur segment d'exécution, assemblées ensuite.

Le billet introduit aussi la notion de scope : l'ensemble des transitions d'état qu'une transaction doit prendre en compte, depuis le dernier point déjà ancré par une preuve. Une transaction qui touche un autre programme paie à ce programme le gaz correspondant aux ressources que consomme ce scope. Le mécanisme vise à empêcher qu'un programme gourmand fasse porter son coût aux autres.

La première version de cet article affirmait que les prouveurs devraient bloquer (staker) des KAS et que cela réduirait l'offre en circulation. Le texte de la proposition ne contient aucune obligation de ce type. Cette affirmation est retirée.

D'autres billets du forum ont détaillé l'architecture : un modèle formel du DAG de calcul des vProgs par Michael Sutton (août 2025) et une analyse de la sûreté de l'élagage (pruning) (septembre 2025).

La feuille de route : Crescendo, Toccata, puis les vProgs

Les vProgs s'appuient sur des évolutions du protocole décrites dans les propositions d'amélioration de Kaspa (KIP).

• Crescendo (KIP-14) : ce hard fork a porté la cadence de production de 1 à 10 blocs par seconde et a ajouté des opcodes d'introspection (KIP-10), première brique des covenants.
• Toccata (KIP-16, 17, 20 et 21) : ce hard fork apporte, selon la note de version de Rusty Kaspa 2.0.0 publiée le 5 juin 2026, « la programmation native de covenants sur la L1 et l'infrastructure pour des applications ZK » ancrées sur la couche 1.
• vProgs : le cadre logiciel est développé dans un dépôt dédié, kaspanet/vprogs, qui se décrit comme en « phase de développement précoce / prototype ».

KIP-16 crée l'opcode OpZkPrecompile, qui permet de vérifier des preuves à divulgation nulle de connaissance directement sur la L1. Deux systèmes de preuve sont prévus : Groth16 et RISC Zero (Succinct, à base de STARK). La motivation est explicite : jusque-là, les couches 2 de Kaspa reposaient sur des solutions centralisées ou semi-centralisées, comme des portefeuilles multisignatures.

Ce qui n'a pas pu être vérifié

La première version de cet article s'appuyait sur des publications sur X. Elle évoquait un portefeuille détenant plus de 1,2 milliard de KAS, une présentation de Yonatan Sompolinsky devant des banques à Londres en décembre 2025 et une finalité d'une seconde. Aucune de ces affirmations n'a pu être rattachée à une source primaire ; elles sont retirées. Les perspectives de hausse du cours ont aussi été supprimées : aucune évolution de prix n'est prévisible, et une mise à jour technique ne produit pas d'effet mécanique sur le cours.

Ce qui s'est passé depuis

Le 5 juin 2026, l'équipe de Rusty Kaspa a publié la version 2.0.0 du nœud, qui embarque Toccata. La note de version fixait l'activation au score DAA 474 165 565, soit vers le 30 juin 2026 à 16 h 15 UTC, et demandait aux opérateurs de mettre à jour leurs nœuds. La version 2.1.0 a ensuite mentionné une « rationalisation du consensus post-Toccata » et isolé un kit de développement ZK autonome (kaspa-txscript-zk-sdk).

Les covenants et la vérification de preuves ZK sur la L1, prérequis des vProgs, sont donc intégrés au protocole. Les vProgs eux-mêmes restent, d'après leur dépôt, à l'état de prototype dont l'API et l'architecture peuvent encore changer. Aucune date de lancement sur le réseau principal n'y figure.