Prochain hard fork de Kaspa centré sur les alliances : ce que nous savons

Qu'est-ce qu'une fork dure centrée sur les alliances de Kaspa ?

Selon  Le fil de Terah, Kaspa prépare une mise à jour majeure centrée sur les accords prévue pour activation du réseau principal le 5 mai 2026. La mise à niveau étend Couche 1 (L1) La programmabilité est améliorée grâce à l'introduction de ressources natives et de fonctionnalités de contrat étendues. Elle jette également les bases de… programmes vérifiables (vProgs) et les intégrations à divulgation nulle de connaissance (ZK).

Kaspa fonctionne comme une blockchain à preuve de travail utilisant une architecture blockDAG. Mise à niveau Crescendo En mai 2025, le débit a été porté à 10 blocs par seconde (BPS). Par conséquent, la prochaine mise à jour majeure s'appuie sur cette base sans modifier les exigences relatives aux nœuds ni les principes fondamentaux du consensus.

Les développeurs principaux décrivent cette version comme une mise à jour ciblée. Elle vise à activer l'émission native de jetons, les règles de dépenses programmables et la vérification ZK sur la couche 1. 

Quel est le calendrier prévu pour la mise à jour majeure (hard fork) du 5 mai 2026 ?

Plusieurs étapes clés précèdent l'activation du réseau principal, d'après le fil de discussion de Terah :

• Réinitialisation du réseau de test 12 (TN12) : Prévu pour début février 2026 afin de soutenir les tests de conformité aux engagements et aux actifs natifs.
   
• KIP d'engagement du séquenceur : Prévue aux alentours du 12 février 2026, cette proposition introduit des engagements de charge utile des mineurs afin de renforcer la décentralisation en temps réel.
   
• Version de 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 de covenants.
   
• Hardfork du réseau principal : Mai 5, 2026.

Les mises à jour post-hard fork incluent DAGKnight, visant un consensus adaptatif et un débit supérieur à 100 BPS, ainsi que le déploiement complet des vProgs.

Comment fonctionnent les actifs et les clauses contractuelles natives sur Kaspa ?

Ressources natives sur la couche 1

Cette mise à jour majeure introduit des ressources natives, notamment la prise en charge de Jetons KRC20Ces ressources existent directement sur le niveau de couche 1 et peuvent être transférées de manière atomique.

Les transferts atomiques s'appliquent à :

• clauses régulières en ligne
• Exécutions des pactes ZK et non-ZK
• Transferts de jetons KRC20

Les conventions intégrées génèrent des preuves immédiates au sein du portefeuille. Il n'y a pas de dissociation entre les données de transaction et la transition d'état. Cette conception garantit l'atomicité et l'exécution déterministe.

Alliances étendues (Alliances++)

Le système de conventions de Kaspa s'inspire des recherches de Bitcoin sur les conditions de dépense programmables des UTXO. Covenants++ étend ce système pour permettre des règles de transaction plus expressives.

Découvrez des projets prometteurs...

Des projets prometteurs...

(Publicité)

L'article continue...

Les cas d'utilisation incluent :

• Contrôles de sécurité de type coffre-fort
• mécanismes de séquestre
• Transferts conditionnels
• Logique de jetons structurée

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

Qu'est-ce qu'un DAG computationnel (CDAG) ?

Le hard fork introduit le DAG computationnel (CDAG).). CDAG enregistre toutes les déclarations de lecture et d'écriture effectuées par les programmes.

Cette structure:

• Suivi de l'utilisation des ressources
• Régule les dépendances entre les programmes
• Respecte les engagements en matière de gaz

La conception est comparable aux modèles d'exécution des blockchains telles que Solana et Sui, mais implémentée intégralement dans l'environnement blockDAG de Kaspa.

CDAG joue un rôle central dans la mise en œuvre de 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 du L1 tout en réglant les résultats sur le L1 par le biais de 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 la dépendance au gaz : Un vProg ne peut pas lire l'état d'un autre vProg à moins de payer du gaz pour la consommation de ressources.
• Transferts non atomiques : Les vProgs ne sont pas transparents pour le niveau 1 de la même manière que les ressources natives. Les transferts sont asynchrones et non atomiques.
• Exigence KAS encapsulée : Tout pacte non intégré doit utiliser KAS encapsulé via un pont canonique. Le KAS L1 natif ne peut pas être utilisé directement.

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

Qui devrait développer des vProgs ?

D'après les discussions au sein de la communauté, la plupart des développeurs d'applications classiques n'ont peut-être pas besoin de vProgs.

Cependant, vProgs peut intéresser :

• architectes d'Appchain
• Équipes évaluant les systèmes de type agrégation
• Projets de construction d'agents d'IA avec un état on-chain important
• Comparaison des modèles par les concepteurs de systèmes : contrats de niveau 1, regroupements de niveau 2 et modèles hybrides

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

Quel rôle joue la connaissance zéro (ZK) ?

Cette version modifiée intègre la vérification ZK sur L1, étendant des propositions antérieures telles que KIP-16.

Les fonctionnalités prises en charge incluent :

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

Les premières applications devraient fonctionner directement sur le système, les portefeuilles générant les preuves directement. Même les implémentations ZK basées sur des conventions, développées par des contributeurs comme 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 dans les conditions actuelles.

Des programmes axés sur la protection de la vie privée sont techniquement possibles après la mise à jour majeure. Cependant, la protection de la vie privée ne figure pas parmi les priorités de la feuille de route.

Quel est le lien entre Sparkle et vProgs ?

Sparkle est une architecture proposée par Anton pour combiner les graphes acycliques orientés (DAG) calculatoires et les preuves ZK. Bien que Sparkle et vProgs utilisent tous deux des composants CDAG et ZK, ils répondent à des problématiques de conception différentes.

La caractéristique principale des 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 favorise la composabilité tout en préservant l'isolation.

La mise à jour Hardfork aura-t-elle un impact sur la sécurité, MEV ou les exigences relatives aux nœuds ?

• Budget de sécurité : Aucun impact direct n'est attendu à court terme. Les améliorations dépendent davantage de l'adoption réelle du produit que de changements d'infrastructure.
   
• Exigences du nœud : Aucun changement.
   
• Ventes aux enchères MEV Kickback : Considéré comme prématuré compte tenu du stade actuel de développement de l'écosystème.
   
• Farming de PoW pour STARKs : Les discussions font référence à des pratiques historiques sur les premières versions d'Ethereum, où les adresses avec des zéros non significatifs réduisaient les frais de gaz, ce qui a engendré des marchés de broyage basés sur la preuve de travail. Cette mention était contextuelle et ne décrivait pas une fonctionnalité actuelle.

Qu'apporte SilverScript ?

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

Ses objectifs de conception comprennent :

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

SilverScript devrait faciliter l'écriture d'applications basées sur des conventions une fois les ressources natives mises en service.

Conclusion

La mise à jour majeure de Kaspa, axée sur les conventions, étend les fonctionnalités de la couche 1 grâce aux actifs natifs, aux conventions étendues et à la vérification ZK. Elle introduit CDAG pour un suivi structuré des dépendances et jette les bases des vProgs souverains. Cette mise à jour préserve les exigences relatives aux nœuds et le consensus par preuve de travail existants, tout en permettant l'émission programmable de jetons et les transferts atomiques.

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

Sources:

• Hard Fork centré sur Kaspa ConvenantCompte à rebours sur Kas.live
• Fil Terah XÉtapes clés à venir et hard fork centré sur Covenant
• Recherche Kaspa: Un modèle formel de structure de base pour le DAG de calcul vProg