Dévoilement de la feuille de route Hard-Fork « Crescendo » – 10BPS et plus

Avec le déploiement réussi du logiciel de nœud Rusty Kaspa (RK) (version stable) et sa large adoption par le réseau P2P et la communauté minière de Kaspa (~ 97 % des blocs Kaspa sont extraits via des nœuds RK), l’équipe de développement open source principale commence maintenant à se préparer à un hard-fork¹ qui augmentera, entre autres choses², le taux de bloc du réseau de 1 à 10 blocs par seconde (BPS). Dans cet article, je présente la feuille de route provisoire du prochain hard-fork, nommé ici le Crescendoce qu’il inclura probablement et le processus de déploiement.

Aperçu

À un niveau élevé, voici comment nous envisageons les étapes nécessaires pour mettre en œuvre une telle accélération sur le réseau principal de Kaspa. Le processus implique les phases itératives suivantes :

• Lancer et stabiliser : Lancez un testnet avec le taux de blocage souhaité et les paramètres réseau associés, et travaillez à sa stabilisation. Cela a été accompli avec TN11, le réseau de test Kaspa 10-BPS existant, opérationnel depuis le 7 janvier 2024. (Fait)

• Identifiez les goulots d’étranglement : Identifiez de manière itérative les goulots d’étranglement de traitement et effectuez des optimisations de performances pour réduire les spécifications matérielles requises pour l’exécution d’un nœud. (Fait)

• Amélioration itérative: Répétez ce qui précède jusqu’à ce que les spécifications minimales soient suffisamment abordables et suffisamment basses pour satisfaire la décentralisation requise pour le réseau principal. (Nous sommes icise rapprochant de la convergence de cette boucle d’optimisation. Calendrier approximatif : dans environ 2 mois.)

• Expérience utilisateur améliorée: Une fois les exigences de performances définies, perfectionnez le logiciel du nœud au niveau d’expérience utilisateur requis par les opérateurs du réseau principal. Autrement dit, certains problèmes mineurs qui peuvent être négligés dans un environnement testnet doivent être résolus ici (dans environ 3 mois). (Suivant)

• Fonctionnalités supplémentaires: implémentez toutes les fonctionnalités hardfork supplémentaires et déployez-les sur TN11. (Calendrier cible : dans environ 4 à 5 mois. Certaines fonctionnalités peuvent être exclues pour s’adapter au calendrier.)

• Version hardfork : Implémenter la version de transition hardfork

• Déployer le testnet de transition: Déployez la version de transition sur TN10 (1 testnet BPS) pour simuler la transition du réseau principal.

• Déploiement du réseau principal avec transition hardfork activée 1 à 2 mois plus tard

Une procédure pas à pas plus détaillée

Actuellement, les développeurs de RK sont occupés à préparer une version du réseau principal axée sur l’introduction de nombreuses fonctionnalités de mempool dont la nécessité a été détaillée lors du lancement bêta de KRC-20. Il s’agit notamment de fonctionnalités délicates telles que le RBF (replace-by-fee) et une API d’estimation des frais, qui nécessitent toutes deux un travail minutieux avec les développeurs de l’écosystème.

Après la sortie de cette version³, l’accent sera mis sur la création d’une version orientée performances destinée à stabiliser les nœuds TN11. Cette version sera utilisée pour aligner les participants TN11 derrière une version qui, espérons-le, résoudra tous les goulots d’étranglement de traitement actuels et assurera un fonctionnement fluide du réseau dans son ensemble.
L’essentiel du travail consisterait à fusionner les PR existants suivants :

Une fois ces fonctionnalités fusionnées, TN11 sera déployé avec cette nouvelle version et fonctionnera sous charge maximale pendant quelques semaines. Cela nous permettra de comprendre la configuration système requise pour exécuter un tel nœud. Si les exigences minimales du système sont jugées trop élevées, certains paramètres (tels que la taille de la fenêtre d’ajustement de la difficulté et les taux d’échantillonnage, la profondeur de finalité, etc.) devront être ajustés, suivis de quelques semaines supplémentaires de tests. Alternativement, d’autres cycles de performance pourraient être envisagés.

Pendant la période de test, le travail reprendra sur d’autres fonctionnalités, notamment :

• Améliorer et perfectionner le processus IBD, en résolvant certains cas extrêmes dans le nouveau processus de synchronisation des nœuds qui sont extrêmement rares sur le réseau principal, mais qui seront exacerbés par des BPS plus élevés et des périodes d’élagage plus courtes.
• Améliorations des règles de finalité et nouveau processus de validation à l’épreuve des en-têtes de nœuds (KIP7, KIP8).
• Reçus cryptographiques (KIP6), une modification qui permet une preuve beaucoup plus petite et plus simple qu’une transaction arbitrairement ancienne a été confirmée.
• Activation des charges utiles de transaction, ce qui rationalisera les spécifications telles que KRC-20.

Une fois tout ce qui précède terminé, nous pouvons commencer par le processus d’écriture d’une version réseau principal de ce hard-fork. Cette version devra inclure la logique de transition des paramètres de protocole actuels vers les nouveaux. Il s’agit d’un processus complexe qui devra être mis à rude épreuve et implique de prendre des décisions cruciales telles que la date d’entrée en vigueur du HF et la question de savoir si cela doit être fait progressivement ou d’un seul coup.

Nous soulignons que le plan décrit ci-dessus est provisoire. Le but de cet article n’est pas de présenter une feuille de route finalisée et gravée dans le marbre, mais de souligner que le hard-fork 10BPS est le prochain objectif majeur de l’équipe principale et qu’un effort important sera consacré à atteindre cet objectif. Surtout, nos principes directeurs restent inchangés : sécurité et stabilité du réseau, et laisser suffisamment de temps à l’écosystème pour s’adapter. Dans le même esprit, nous notons que même si les détails ci-dessus concernent les responsabilités des développeurs principaux, l’écosystème plus large – y compris les développeurs de portefeuilles, les pools, les bourses, les explorateurs de blocs et autres – devra également procéder à des ajustements et devrait s’engager activement. dans cet effort en testant leurs composants logiciels via le testnet 10-BPS.

¹Dans notre contexte, le « hard-fork » fait référence à un changement convenu et programmé par la communauté dans le protocole de consensus, plutôt qu’à un fork controversé résultant de désaccords au sein du réseau.

²Aucun des changements inclus dans ce hard-fork n’affectera les fonds des utilisateurs ou le calendrier d’émission. L’augmentation à 10 BPS entraînera dix fois plus de récompenses, mais la récompense par bloc sera réduite du même facteur, en conservant le même taux d’émission par seconde.

³Un réseau principal axé sur le pool de mémoire candidat à la libération la version est attendue d’ici la fin de cette semaine (~25 août).