Le prochain hardfork centré sur les alliances de Kaspa : ce que nous savons

Qu’est-ce que le hardfork centré sur les alliances de Kaspa ?

Selon Le fil de Terah,Quand prépare un hardfork centré sur les alliances prévu pour activation du réseau principal le 5 mai 2026. La mise à niveau s’étend Couche 1 (L1) programmabilité en introduisant des actifs natifs et des fonctionnalités d’engagement étendues. Il jette également les bases d’un programmes vérifiables (vProgs) et intégrations sans connaissance (ZK).

Kaspa fonctionne comme une blockchain de preuve de travail utilisant une architecture blockDAG. C’est Mise à niveau crescendo en mai 2025, le débit a été augmenté à 10 blocs par seconde (BPS). Ainsi, le prochain hardfork s’appuie sur cette fondation sans modifier les exigences des nœuds ou les principes fondamentaux du consensus.

Les développeurs principaux décrivent la version comme une mise à niveau limitée. Il se concentre sur l’activation de l’émission de jetons natifs, des règles de dépenses programmables et de la vérification ZK sur L1.

Quel est le calendrier du Hardfork du 5 mai 2026 ?

Plusieurs étapes précèdent l’activation du réseau principal, selon le fil de discussion de Terah :

• Réinitialisation Testnet 12 (TN12) : Prévu pour début février 2026 pour prendre en charge les tests de clauses restrictives et d’actifs natifs.
• KIP d’engagement du séquenceur : Attendu vers le 12 février 2026. Cette proposition introduit des engagements en matière de charge utile des mineurs pour renforcer la décentralisation en temps réel.
• Version SilverScript : Un langage de programmation de haut niveau pour écrire des programmes sur Kaspa. Développé par Ori Newman et ses contributeurs, il simplifie le développement des alliances.
• Hardfork du réseau principal : 5 mai 2026.

Les mises à niveau post-hardfork incluent DAGKnight, ciblant un consensus adaptatif et un débit supérieur à 100 BPS, ainsi que le déploiement complet de vProgs.

Comment fonctionnent les actifs et les clauses natives sur Kaspa ?

Actifs natifs sur la couche 1

Le hardfork introduit des actifs natifs, notamment la prise en charge de Jetons KRC20. Ces actifs existent directement sur L1 et peuvent être transférés de manière atomique.

Les transferts atomiques s’appliquent à :

• Engagements en ligne réguliers
• Exécutions des clauses ZK et non-ZK
• Transferts de jetons KRC20

Les clauses en ligne génèrent des preuves immédiates dans le portefeuille. Il n’y a pas de découplage entre les données de transaction et la transition d’état. Cette conception prend en charge l’atomicité et l’exécution déterministe.

Covenants étendus (Covenants++)

Le système d’engagement de Kaspa s’inspire de la recherche Bitcoin sur les conditions de dépenses UTXO programmables. Covenants++ étend ce système pour permettre des règles de transaction plus expressives.

Les cas d’utilisation incluent :

• Contrôles de sécurité de type coffre-fort
• Mécanismes de dépôt
• Transferts conditionnels
• Logique de jeton structurée

Le système maintient un modèle UTXO plutôt que des contrats intelligents entièrement basés sur un compte.

Quel est le calcul $JOUR (CDAG) ?

Le hardfork introduit le calcul $JOUR (CDAG). CDAG enregistre toutes les déclarations de lecture et d’écriture faites par les programmes.

Cette structure :

• Suit l’utilisation des ressources
• Régule les dépendances entre les programmes
• Faire respecter les engagements gaziers

La conception est comparable aux modèles d’exécution dans les blockchains telles que Solana et Sui, mais implémentée sous sa forme complète dans l’environnement blockDAG de Kaspa.

CDAG joue un rôle central dans la souveraineté des vProgs.

Que sont les vProgs et en quoi diffèrent-ils des contrats intelligents ?

Les vProgs sont des programmes souverains qui s’exécutent en dehors de L1 tout en réglant les résultats sur L1 via des preuves.

Propriétés clés :

• Exécution souveraine : Chaque vProg définit ses propres règles de débit et de dépendance.
• Contrôle de dépendance basé sur le gaz : Un vProg ne peut pas lire l’état d’un autre vProg à moins de payer du gaz pour la consommation des ressources.
• Transferts non atomiques : Les vProgs ne sont pas transparents pour L1 de la même manière que les actifs natifs. Les transferts sont asynchrones et non atomiques.
• Emballé $QUOI exigence: Tout engagement non-inline doit utiliser enveloppé $QUOI à travers un pont canonique. Natif L1 $QUOI ne peut pas être utilisé directement.

Cette conception sépare le calcul et l’état de L1 tout en préservant le séquençage et le règlement partagés.

Qui devrait créer des vProgs ?

Selon les discussions de la communauté, la plupart des développeurs d’applications classiques n’ont peut-être pas besoin de vProgs.

Cependant, les vProgs peuvent plaire à :

• Architectes d’applications
• Équipes évaluant les systèmes de type cumulatif
• Projets créant des agents d’IA avec un grand état en chaîne
• Concepteurs de systèmes comparant les contrats L1, les cumuls L2 et les modèles hybrides

Les vProgs combinent un séquençage L1 unifié avec un état et un calcul externalisés.

Quel rôle joue Zero-Knowledge (ZK) ?

Le hardfork intègre la vérification ZK sur L1, étendant les propositions antérieures telles que KIP-16.

Les fonctionnalités prises en charge incluent :

• Vérification de la preuve Groth16
• Ponts sans confiance vers les systèmes L2
• Applications potentielles axées sur la confidentialité

Les applications initiales devraient fonctionner en ligne, les portefeuilles générant directement des preuves. Même les implémentations ZK basées sur des conventions et développées par des contributeurs tels que Hans et Maxim devraient fonctionner sur du matériel standard. Aucune infrastructure de preuve spécialisée n’est requise pour les premiers déploiements.

Un ordinateur portable standard peut générer des preuves sous les hypothèses actuelles.

Les programmes axés sur la confidentialité sont techniquement possibles après le hardfork. Cependant, la confidentialité ne figure pas parmi les objectifs principaux de la feuille de route.

Quel est le lien entre Sparkle et vProgs ?

Sparkle est une architecture proposée par Anton pour combiner des preuves informatiques DAG et ZK. Bien que Sparkle et vProgs utilisent les composants CDAG et ZK, ils répondent à des questions de conception différentes.

La caractéristique déterminante de vProgs est la régulation des dépendances. Chaque programme contrôle son débit et évite les dépendances externes arbitraires. Ce modèle prend en charge la composabilité tout en préservant l’isolement.

Le Hardfork affectera-t-il la sécurité, le MEV ou les exigences en matière de nœuds ?

• Budget de sécurité : Aucun impact direct n’est attendu à court terme. Les améliorations dépendent de l’adoption réelle du produit plutôt que des changements d’infrastructure.
• Exigences du nœud : Aucun changement.
• Ventes aux enchères de pots-de-vin MEV : Considéré comme prématuré compte tenu du stade actuel de développement des écosystèmes.
• Broyage PoW pour les STARK : Les discussions font référence au comportement historique des premiers Ethereum, où les adresses avec des zéros non significatifs ont réduit les coûts du gaz, ce qui a conduit à des marchés de broyage de preuve de travail. La mention était contextuelle plutôt qu’une fonctionnalité actuelle.

Qu’ajoute SilverScript ?

SilverScript est un langage de haut niveau conçu pour les programmes Kaspa. Il vise à simplifier le développement des conventions et des programmes.

Ses objectifs de conception comprennent :

• Syntaxe lisible
• Accessibilité pour les nouveaux développeurs
• Compatibilité avec les outils automatisés

SilverScript devrait réduire les obstacles à l’écriture d’applications basées sur des clauses contractuelles une fois que les actifs natifs seront mis en ligne.

Conclusion

Le hardfork centré sur les clauses de Kaspa étend les fonctionnalités de couche 1 grâce à des actifs natifs, des clauses étendues et la vérification ZK. Il introduit CDAG pour le suivi structuré des dépendances et jette les bases des vProgs souverains. La mise à niveau préserve les exigences de nœuds existantes et le consensus de preuve de travail tout en permettant l’émission de jetons programmables et les transferts atomiques.

L’activation du 5 mai 2026 marque une étape technique dans la feuille de route de Kaspa. Il ajoute une programmabilité structurée au niveau du protocole et prépare le réseau à d’autres mises à niveau, notamment le déploiement de DAGKnight et de vProgs complet.

Sources :

• Hard Fork centré sur Kaspa Convenant: Compte à rebours sur Kas.live
• Sujet de Terah X: Jalons à venir et Hard Fork centré sur les Covenants
• Recherche de cas: Un modèle de base formel pour le calcul vProg $JOUR