---

---

---

Chapitre 1 : Le BlockDAG de Kaspa

DAG - Graphe orienté acyclique

Vous avez probablement déjà entendu dire que Kaspa est un BlockDAG, mais qu'est-ce que cela signifie ? Cet article est conçu de manière à ne présupposer aucune connaissance préalable, nous commencerons donc par la théorie des graphes. Nous verrons d'abord ce qu'est un Graphe, puis ce qu'est un Graphe Orienté, puis nous arriverons au Graphe Orienté Acyclique, et enfin comment cela s'applique à la fois à Bitcoin et à Kaspa.

Graphe - La théorie des graphes, un domaine des mathématiques et de l'informatique, se concentre sur l'étude des graphes, qui sont des structures représentant les relations entre des paires d'entités. Ces graphes sont constitués de sommets (également appelés nœuds ou points) connectés par des arêtes (parfois appelées liens ou lignes). Les graphes sont classés en graphes non orientés, où les connexions entre les sommets sont mutuelles, et en graphes orientés, où les connexions ont une direction spécifique. En tant que domaine clé des mathématiques discrètes, la théorie des graphes explore ces structures de manière approfondie. L'image suivante illustre un graphe non orienté simple où les connexions n'ont pas de direction.

Graphe Orienté - Un graphe orienté, souvent appelé digraphe, est une structure utilisée pour montrer des relations où les connexions entre les points ont une direction spécifique. Contrairement aux graphes réguliers où les connexions vont dans les deux sens, dans un graphe orienté, chaque arête pointe d'un sommet vers un autre. Dans sa forme la plus simple, un graphe orienté se compose de deux parties principales : une collection de sommets et un ensemble d'arêtes, où chaque arête est une paire de sommets avec une direction claire (d'un sommet à un autre, mais pas l'inverse). Par exemple, si vous avez une arête du sommet X au sommet Y, X est le point de départ et Y est le point d'arrivée. Cette arête connecte X à Y. Une arête différente pourrait aller de Y à X, mais ce serait une connexion distincte. Dans cette configuration de base, appelée graphe simple orienté, vous ne pouvez pas avoir plusieurs arêtes avec la même direction entre les mêmes deux sommets, ni avoir une arête qui commence et se termine au même sommet (appelée boucle). L'image suivante illustre un graphe orienté où les arêtes ont une direction ; notez que l'arête avec deux pointeurs représente deux arêtes, chacune avec une direction.

Graphe Orienté Acyclique - est un graphe orienté qui ne contient aucun cycle. Il est composé de sommets et d'arêtes, où chaque arête a une direction d'un sommet à un autre, garantissant que suivre les directions des arêtes ne conduit jamais à une boucle fermée. Un graphe orienté est qualifié de DAG si ses sommets peuvent être arrangés dans une séquence linéaire qui respecte la direction de toutes les arêtes, connue sous le nom d'ordre topologique. L'image suivante illustre un graphe orienté acyclique où aucun cycle (ou boucle) ne peut être trouvé.

Bitcoin et Kaspa

Bitcoin - est un DAG, même s'il est toujours appelé une Blockchain, Bitcoin utilise la structure DAG. Les blocs sont des sommets, et leur relation est celle des arêtes. Chaque bloc est connecté dans une seule direction et en suivant chaque connexion, vous ne ferez jamais de cycle, et vous reviendrez toujours à la Genèse.

Kaspa - est un DAG, Kaspa utilise la structure DAG. Les blocs sont des sommets, et leur relation est celle des arêtes. Chaque bloc est connecté dans une seule direction et en suivant chaque connexion, vous ne ferez jamais de cycle, et vous reviendrez toujours à la Genèse.

Alors, quelle est la différence si Bitcoin et Kaspa utilisent tous deux un DAG ? Bitcoin permet aux blocs de pointer vers un seul bloc précédent. Kaspa permet aux blocs de pointer vers plusieurs blocs précédents. C'est la seule différence dans la structure.

---

Chapitre 2 : Kaspa - Lier le corps à l'en-tête

Sécuriser le corps du bloc à l'en-tête - Racine de Merkle

Qu'est-ce qui sécurise le corps du bloc à l'en-tête ? La Racine de Merkle des transactions dans le corps.

Qu'est-ce que cela signifie ? Cet article est conçu de manière à ne présupposer aucune connaissance préalable, nous commencerons donc par un Arbre de Merkle. Qu'est-ce qu'un arbre de Merkle, comment il est construit et comment il empêche la falsification. Ensuite, comment il s'applique à la fois à Bitcoin et à Kaspa.

Arbre de Merkle - En cryptographie et en informatique, un Arbre de Merkle, également connu sous le nom d'Arbre de Hachage, est une structure arborescente où chaque nœud "feuille" contient le hachage cryptographique d'un bloc de données. Les nœuds non-feuilles, souvent appelés branches ou nœuds internes, contiennent le hachage cryptographique des étiquettes de leurs nœuds enfants. Cette structure permet une validation efficace et sécurisée du contenu de grands ensembles de données.

Bloc de Données - Dans un arbre de Merkle, un bloc de données est un segment de données brutes, tel qu'une transaction, qui constitue la base de la structure de l'arbre. Chaque bloc de données est haché individuellement pour produire un hachage de nœud feuille.

Feuille - Un nœud dans un arbre de Merkle qui stocke le hachage cryptographique d'un seul bloc de données. Le nœud feuille, en stockant ce hachage, agit comme une empreinte numérique du bloc de données.

Nœud Interne - Un nœud parent qui agrège les hachages de ses nœuds enfants. Ces hachages enfants sont concaténés et hachés pour produire une seule valeur de hachage qui étiquette le nœud interne.

Racine de Hachage - La valeur de hachage singulière au nœud le plus élevé, encapsulant toutes les données de l'arbre. Elle sert de résumé compact et unique de tous les blocs de données sous-jacents. Toute modification d'un seul nœud feuille altère la racine de hachage.

Bitcoin et Kaspa

Bitcoin - un Arbre de Merkle organise les données de transaction dans chaque bloc. Les transactions sont hachées en nœuds feuilles, appariées et hachées en nœuds internes, et combinées en une seule racine de hachage stockée dans l'en-tête du bloc. Cette structure permet une vérification efficace de l'intégrité des transactions.

Kaspa - un Arbre de Merkle organise les données de transaction dans chaque bloc de la même manière que Bitcoin. Cependant, Kaspa permet la coexistence de blocs parallèles, où l'ordre entre ces blocs dans le DAG ne peut être connu. Un Arbre de Merkle dépend de l'ordre. Comment Kaspa résout-il cela ? En ajoutant un Arbre de Merkle supplémentaire.

Qu'est-ce qui sécurise le corps du bloc à l'en-tête ? La Racine de Merkle des transactions dans le corps (hash_merkle_root).

Qu'est-ce qui sécurise les transactions du mergeset à l'en-tête ? La Racine de Merkle des transactions dans le mergeset (accepted_id_merkle_root). Cette deuxième racine permet de valider les transactions des blocs parallèles qui sont fusionnés, résolvant ainsi le problème de l'ordre dans un environnement DAG.

---

Chapitre 3 : Kaspa et le "Problème de Scalabilité de Bitcoin"

Kaspa a résolu le "Problème de Scalabilité de Bitcoin" - Qu'est-ce que c'est ?

Qu'est-ce que le Problème de Scalabilité de Bitcoin et comment Kaspa l'a-t-il résolu ? Par l'inclusion.

Qu'est-ce que cela signifie ? Cet article est conçu de manière à ne présupposer aucune connaissance préalable, nous commencerons donc par un Modèle Client-Serveur, puis le réseau Pair à Pair. Qu'est-ce qu'un réseau P2P, à quoi il ressemble, et comment les messages s'y propagent. Ensuite, comment cela s'applique à la fois à Bitcoin et à Kaspa.

Modèle Client-Serveur - Dans un réseau client-serveur, une architecture centralisée organise la communication et le partage des ressources via un seul ordinateur puissant appelé serveur, qui se connecte à plusieurs appareils utilisateurs appelés clients. Cette structure assure une gestion efficace mais dépend fortement du serveur, le rendant vulnérable.

Réseau Pair à Pair (P2P) - Une architecture décentralisée qui permet la communication directe et le partage de ressources entre des nœuds interconnectés. Chaque pair fonctionne à la fois comme client et comme serveur, contribuant à la résilience et à la scalabilité du réseau sans dépendre d'une autorité centrale.

Temps de Propagation - Dans un réseau P2P, le temps de propagation est la durée qu'il faut pour que les données (comme un nouveau bloc) voyagent d'un nœud à d'autres à travers le réseau. Pendant ce temps, différents nœuds peuvent avoir des vues différentes de l'état du réseau.

Bitcoin et Kaspa

Bitcoin - Utilise un réseau P2P. Cependant, sa sécurité dépend du fait que le taux de création de blocs (10 minutes) est beaucoup plus lent que le temps de propagation. Si les blocs sont créés trop rapidement, de nombreux blocs sont "orphelins" (rejetés), ce qui gaspille du travail et compromet la sécurité. C'est le "problème de scalabilité".

Kaspa - Utilise un protocole inclusif (GHOSTDAG) qui permet aux blocs de pointer vers plusieurs blocs précédents. Si des blocs parallèles sont créés pendant le temps de propagation, ils sont tous inclus dans le DAG. Il n'y a pas de blocs orphelins. Cela permet au taux de création de blocs d'être plus rapide que le temps de propagation, résolvant ainsi le problème de scalabilité tout en maintenant la sécurité.

---

Chapitre 4 : MuHash

Qu'est-ce que MuHash et comment Kaspa l'utilise-t-il ?

Une structure pour suivre les UTXO et élaguer les anciennes données de corps de bloc.

Qu'est-ce que cela signifie ? Cet article est conçu de manière à ne présupposer aucune connaissance préalable, nous commencerons donc par MuHash. Qu'est-ce qu'une structure MuHash, comment elle est calculée, et comment elle conserve les propriétés de la Multiplication. Ensuite, comment elle s'applique à la fois à Bitcoin et à Kaspa.

MuHash - Dans les systèmes cryptographiques, MuHash (Multiplicative Hash) est un algorithme de hachage spécialisé conçu pour calculer efficacement une seule valeur de hachage à partir d'un ensemble d'éléments. Il permet des mises à jour incrémentielles, ce qui signifie que des éléments peuvent être ajoutés ou supprimés sans recalculer l'intégralité du hachage, ce qui améliore les performances dans les ensembles de données dynamiques.

Numérateur et Dénominateur - MuHash utilise deux compteurs : un numérateur qui multiplie les éléments ajoutés et un dénominateur qui multiplie les éléments supprimés. L'état final est obtenu en "divisant" le numérateur par le dénominateur (via une multiplication par l'inverse modulaire). L'ordre des opérations n'a pas d'importance, ce qui est crucial pour le traitement parallèle.

Contrainte Modulo Premier - Le nombre premier modulaire agit comme une limite mathématique qui maintient à la fois le numérateur et le dénominateur dans une plage gérable pendant toutes les opérations arithmétiques. Chaque multiplication est effectuée modulo un nombre premier, ce qui signifie que peu importe le nombre d'éléments ajoutés ou supprimés, les résultats "bouclent" toujours pour rester dans le corps fini.

Inverse Modulaire - L'inverse modulaire est l'opération mathématique qui rend la division possible dans le corps fini utilisé par MuHash. Lorsque vous devez "diviser" le numérateur par le dénominateur pour obtenir le résultat de hachage final, vous multipliez en fait le numérateur par l'inverse modulaire du dénominateur.

Bitcoin et Kaspa

Bitcoin - Les nœuds complets conservent toutes les transactions, y compris les anciennes transactions dépensées. L'élagage est difficile car il n'y a pas de mécanisme efficace pour résumer l'état des transactions (l'ensemble UTXO) de manière compacte et vérifiable sans conserver les données historiques.

Kaspa - Les nœuds complets élaguent les anciennes données. Cette capacité d'élaguer les anciennes données nécessite un moyen de supprimer toutes les données de transaction de chaque bloc ET de les sécuriser cryptographiquement à chaque en-tête. Kaspa utilise MuHash pour supprimer les données de transaction des blocs (de sorte que seuls les en-têtes du DAG restent après le point d'élagage) et les sécuriser à chaque en-tête. C'est une étape essentielle pour l'élagage. Kaspa sépare les Données de Transaction (UTXO) des Données de Consensus (En-têtes), ce qui fait que Kaspa ne stocke que les Transactions Non Dépensées, au lieu de toutes les transactions jamais effectuées. Cela réduit les exigences de stockage par rapport à Bitcoin.

---

Chapitre 5 : Modèle UTXO de Kaspa

Qu'est-ce qu'un UTXO et comment Kaspa l'utilise-t-il ?

Une structure pour suivre qui peut dépenser quel Kaspa.

Qu'est-ce que cela signifie ? Cet article est conçu de manière à ne présupposer aucune connaissance préalable, nous commencerons donc par le Modèle de Compte et le modèle UTXO, puis ce qu'est un UTXO, ce qu'il contient et comment il est dépensé. Ensuite, comment cela s'applique à la fois à Bitcoin et à Kaspa.

Modèle de Compte - Le Modèle de Compte se comporte comme un compte bancaire traditionnel en maintenant un solde et en offrant des opérations familières. Tout comme la vérification de votre solde bancaire, vous pouvez interroger les avoirs actuels du compte, et de manière similaire à la façon dont les banques suivent votre historique de transactions, le Compte gère votre état financier. Le système fournit des opérations de compte standard telles que la réception de dépôts et l'exécution de virements, chaque compte ayant son propre identifiant unique et son nom pour une gestion facile. Plusieurs types de comptes sont disponibles pour répondre à différents besoins, tout comme les banques offrent divers types de comptes à des fins différentes.

Modèle UTXO - Le Modèle UTXO se comporte comme de l'argent physique ou des pièces dans votre portefeuille, où chaque pièce a une valeur spécifique et ne peut être dépensée qu'une seule fois. Tout comme vous pourriez avoir plusieurs billets et pièces de différentes dénominations dans votre portefeuille physique, un portefeuille numérique contient plusieurs UTXO de montants variables qui représentent votre solde dépensable. Lorsque vous effectuez une transaction, des UTXO spécifiques sont consommés en tant qu'entrées (comme dépenser des billets exacts), et de nouveaux UTXO sont créés en tant que sorties pour le destinataire et toute monnaie qui vous est rendue, de manière similaire à la façon dont un caissier vous rend la monnaie lorsque vous payez avec un billet plus grand. Le système suit ces "pièces" individuelles à travers toutes les transactions, en maintenant un enregistrement complet des UTXO qui existent et peuvent être dépensés, tout comme l'argent physique se déplace de personne en personne tout en conservant son identité individuelle.

Structure UTXO - Un UTXO (Unspent Transaction Output) est structuré comme un reçu numérique qui contient toutes les informations essentielles nécessaires pour le dépenser, de manière similaire à la façon dont un chèque contient le montant, les détails du destinataire et les informations d'autorisation. Chaque UTXO contient le montant de la valeur qu'il détient et définit les conditions de dépense. Tout comme une pièce physique a sa dénomination estampillée et peut être vérifiée comme authentique, chaque UTXO porte sa valeur et une preuve cryptographique de propriété, ce qui en fait une unité de valeur autonome qui peut être vérifiée et dépensée indépendamment. Le système traite chaque UTXO comme un objet discret avec son propre identifiant unique, permettant un suivi précis des unités de valeur individuelles à mesure qu'elles se déplacent à travers le réseau.

Dépenser un UTXO - Dépenser un UTXO se comporte comme l'utilisation d'argent liquide physique, où vous devez présenter le billet ou la pièce exacte pour effectuer un achat, et une fois dépensé, il ne peut plus être utilisé. Le processus commence par la localisation de l'UTXO spécifique que vous souhaitez dépenser et la vérification de son existence dans l'ensemble UTXO, de manière similaire à la vérification qu'un billet dans votre portefeuille est authentique et non dépensé. Lors de la création d'une transaction, vous référencez l'UTXO par son identifiant unique et fournissez un script de signature qui prouve que vous avez le droit de le dépenser. Le système valide que l'UTXO n'a pas déjà été dépensé (empêchant la double dépense), vérifie que vous remplissez les conditions de dépense, puis supprime l'UTXO de l'ensemble dépensable tout en créant de nouveaux UTXO en tant que sorties, complétant le transfert de valeur d'une partie à l'autre.

Bitcoin et Kaspa

Bitcoin - Utilise le modèle UTXO. Les transactions sont des collections d'UTXO consommés et créés, stockées dans le corps de chaque bloc.

Kaspa - Utilise également le modèle UTXO. La principale différence réside dans la manière dont ces UTXO sont gérés et validés dans un environnement BlockDAG, ce qui permet un traitement parallèle et des confirmations plus rapides.

---

Chapitre 6 : Parents vs Mergeset

Que sont les Parents et le Mergeset et comment Kaspa les utilise-t-il ?

Deux façons différentes de décrire les relations entre les blocs dans la structure BlockDAG de Kaspa.

Parents de Blockchain Traditionnels - Dans une blockchain linéaire comme Bitcoin, chaque bloc a exactement un parent (sauf la Genèse), créant une structure de chaîne simple. La relation parentale est simple : chaque nouveau bloc référence le hachage du bloc précédent, formant une séquence ininterrompue de la Genèse jusqu'à la pointe actuelle.

Complexité des Parents DAG - Le BlockDAG de Kaspa permet aux blocs d'avoir plusieurs parents, créant un réseau de relations plus complexe. Lorsqu'un bloc est créé, il peut référencer plusieurs blocs existants en tant que parents, permettant la création de blocs parallèles et un débit plus élevé.

Parents - Les parents sont les blocs qu'un nouveau bloc référence directement dans son en-tête. Ce sont des relations explicites déclarées par le créateur du bloc - ce sont les blocs sur lesquels ce nouveau bloc se construit directement. Lorsque vous visualisez un Visualiseur DAG de Kaspa, ces flèches représentent la relation parentale.

Comment fonctionnent les Parents - Lors de la création d'un bloc, les mineurs sélectionnent les blocs existants à référencer comme parents en fonction de ce qu'ils considèrent comme les "tips" actuels du DAG. Le système valide ces relations parentales et les utilise pour déterminer la position du bloc dans la structure du DAG. Ici, vous pouvez voir un nouveau bloc en cours de création, référençant les "tips" du DAG, les blocs trouvés sans qu'un autre bloc ne les pointe.

Mergeset - Le mergeset est l'ensemble des blocs qui se trouvent dans l'anticône du parent sélectionné d'un bloc mais qui sont toujours considérés comme faisant partie du contexte de consensus du bloc. Ici, le bloc C est dans l'anticône de B, et le bloc B est dans l'anticône de C.

Comment le Mergeset est calculé - Le mergeset est calculé en trouvant tous les blocs qui ne sont pas des ancêtres du parent sélectionné mais qui sont toujours atteignables via l'ensemble des parents du bloc. Cela crée un contexte plus large de blocs qui doivent être pris en compte pour les décisions de consensus. Dans cet exemple, si le bloc B est le parent sélectionné, le mergeset du bloc en cours de création inclurait à la fois le bloc C et le bloc D.

Mergeset dans GHOSTDAG - Le protocole GHOSTDAG traite le mergeset pour déterminer quels blocs doivent être colorés "bleu" (contribuant au consensus) ou "rouge" (valides mais ne contribuant pas). Ce processus de coloration est essentiel pour maintenir le consensus dans l'environnement de blocs parallèles.

Comment les Parents et le Mergeset fonctionnent ensemble

Sélection du Parent Sélectionné - Parmi tous les parents, le système en sélectionne un comme "parent sélectionné" - celui qui a le plus grand "blue work". Cela crée une colonne vertébrale de chaîne principale à travers le DAG tout en reconnaissant les autres relations parentales. Ici, la chaîne parentale est mise en évidence.

Traitement du Mergeset - Une fois le parent sélectionné choisi, le mergeset est calculé et traité pour déterminer les données GHOSTDAG finales. Le mergeset exclut le parent sélectionné puisqu'il est déjà pris en compte dans la chaîne principale. Ici, le mergeset inclut le bloc C, car il est dans l'anticône du bloc B (le parent sélectionné) même s'il n'est pas un parent du nouveau bloc (les parents incluent seulement le bloc B et le bloc D).

Sélection du Parent Virtuel - Lors de la création de l'état virtuel, le système utilise les deux concepts : il choisit les parents virtuels parmi les blocs candidats tout en s'assurant que le mergeset résultant ne dépasse pas les limites de taille. Cela équilibre l'inclusion de nombreux blocs parallèles tout en maintenant une complexité de consensus gérable.

Différences Pratiques

Stockage et Itération - Les parents sont stockés directement dans les en-têtes de bloc, tandis que les données du mergeset sont calculées et stockées séparément dans les structures de données GHOSTDAG. Le système fournit différents itérateurs pour accéder aux blocs du mergeset dans divers ordres (ordre de consensus, ordre de "blue work", etc.).

Impact sur le Consensus - Les parents déterminent la structure de base du DAG, mais le mergeset détermine quels blocs contribuent réellement aux calculs de consensus comme le "blue score" et le "blue work". Un bloc pourrait être un parent mais finir par être coloré en rouge dans le mergeset, ce qui signifie qu'il ne contribue pas à la chaîne de consensus principale.

Bitcoin vs Kaspa

Bitcoin - N'a qu'un seul parent par bloc (sauf la Genèse), il n'y a donc pas de distinction entre les parents et le mergeset. Le parent unique est à la fois la relation structurelle et la relation de consensus.

Kaspa - Sépare les relations structurelles (parents) des relations de consensus (mergeset). Plusieurs parents créent la structure du DAG, mais le traitement du mergeset détermine quels blocs contribuent réellement à l'état de consensus.

---

Chapitre 7 : Élément de Second Ordre

Qu'est-ce que l'élagage de second ordre et comment Kaspa l'utilise-t-il ?

L'élagage de second ordre est l'étape avancée de l'optimisation du stockage de Kaspa qui supprime les données liées au consensus tout en maintenant la capacité de valider de nouveaux blocs et de participer au consensus du réseau. Il va au-delà de l'élagage de premier ordre en supprimant sélectivement les données de structure du DAG, les relations et certains en-têtes eux-mêmes.

Pourquoi "Second Ordre" ? - Cette terminologie souligne qu'après la suppression des corps de blocs (Premier Ordre), Kaspa peut supprimer des données de consensus supplémentaires tout en conservant les capacités de validation. L'élagage de second ordre permet une efficacité de stockage maximale en supprimant les informations de consensus redondantes qui ne sont pas essentielles pour la validation continue.

Qu'est-ce que cela signifie ? - Cet article suppose une connaissance de l'élagage de premier ordre, nous commencerons donc par les données de consensus qui existent après l'élagage de premier ordre, puis nous expliquerons comment l'élagage de second ordre supprime sélectivement les structures de consensus, ce qui est conservé par rapport à ce qui est supprimé, et comment la validation continue de fonctionner avec des données de consensus réduites.

Élagage de Premier Ordre vs Élément de Second Ordre

Fondation de l'élagage de Premier Ordre - Après l'élagage de premier ordre, les nœuds conservent tous les en-têtes de bloc, les données GHOSTDAG, les relations d'accessibilité et les informations sur la structure du DAG. Cela permet une validation complète du consensus mais nécessite toujours un stockage important pour les relations complexes du DAG que Kaspa maintient.

Défi de l'élagage de Second Ordre - Le défi est de déterminer quelles données de consensus peuvent être supprimées en toute sécurité sans compromettre la capacité du nœud à valider de nouveaux blocs. Le système doit préserver suffisamment d'informations structurelles pour maintenir le consensus tout en supprimant les données redondantes.

Système de Preuve Multi-Niveaux

Classification du Niveau de Preuve - Le système d'élagage de Kaspa classe les blocs en fonction de leur importance pour différents niveaux de preuve. Les blocs affiliés à des niveaux de preuve plus élevés conservent plus de données de consensus que ceux qui ne sont nécessaires que pour des niveaux inférieurs.

Rétention des Données Basée sur le Niveau - Le système détermine quelles données de consensus conserver en fonction du niveau de preuve auquel chaque bloc appartient. Les blocs de niveau supérieur conservent plus de relations et d'informations de consensus, tandis que les blocs de niveau inférieur peuvent voir leurs données de consensus supprimées en toute sécurité.

Zones DAG Contiguës - L'élagage garantit que pour chaque niveau, les relations restantes représentent une zone DAG contiguë, maintenant l'intégrité structurelle nécessaire à la validation du consensus.

Ce qui est supprimé dans l'élagage de Second Ordre

Suppression des Données de Relations - L'élagage de second ordre supprime les données de relations spécifiques au niveau pour les blocs qui n'appartiennent qu'à des niveaux de preuve supérieurs. Cela préserve la sémantique selon laquelle les relations représentent des zones DAG contiguës tout en supprimant les données de niveau inférieur inutiles.

Suppression Sélective des Données GHOSTDAG - Le système supprime les données GHOSTDAG pour certains blocs tout en les préservant pour la validation essentielle du consensus. Les données GHOSTDAG sont supprimées au niveau 0 pour les blocs en cours d'élagage partiel.

Suppression des En-têtes - Dans la forme la plus agressive de l'élagage de second ordre, certains en-têtes de bloc eux-mêmes peuvent être supprimés tout en préservant les points d'élagage passés. Seuls les en-têtes non essentiels pour les requêtes de points d'élagage sont supprimés.

Ce qui est conservé dans l'élagage de Second Ordre

Structures de Consensus Essentielles - Les données de consensus critiques comme l'anticône du point d'élagage, les blocs de la fenêtre DAA et les blocs GHOSTDAG pour la validation essentielle sont toujours conservées. Cela garantit que les opérations de consensus peuvent continuer même avec un stockage de données réduit.

Affiliations au Niveau de Preuve - Les blocs maintiennent leur classification en fonction de l'importance du niveau de preuve, déterminant quelles données sont conservées. Le système préserve le minimum de données nécessaires à la validation du consensus en fonction de ces affiliations.

Points d'Élagage Passés - Les en-têtes pour les points d'élagage passés sont toujours conservés pour maintenir la capacité de répondre aux requêtes de points d'élagage et de prendre en charge le système de preuve d'élagage.

Comment la Validation du Consensus se Poursuit

Transitions de Statut - Les blocs subissant l'élagage de second ordre passent au statut "en-tête seulement" lorsqu'ils avaient un statut valide et appartiennent à un niveau de preuve. Cela préserve la sémantique selon laquelle un statut valide implique l'existence de données de consensus essentielles.

Validation des Données Réduites - Même avec l'élagage de second ordre, les nœuds peuvent valider de nouveaux blocs en utilisant les structures de données de consensus préservées et les relations restantes. Le système maintient suffisamment d'informations pour vérifier les règles GHOSTDAG et les relations entre les blocs.

Validation Basée sur la Preuve - Les données de niveau de preuve préservées permettent aux nœuds de valider les blocs en utilisant des preuves cryptographiques plutôt que des données de consensus historiques complètes, permettant la participation au consensus avec un stockage considérablement réduit.

Avantages en matière de Stockage et de Performance

Réduction des Données de Consensus - L'élagage de second ordre réduit considérablement les exigences de stockage pour les données liées au consensus tout en maintenant la participation au consensus du réseau. Cela va au-delà des économies de données de transaction de l'élagage de premier ordre.

Efficacité de la Validation - En supprimant les données de consensus redondantes tout en préservant les structures essentielles, l'élagage de second ordre peut améliorer les performances de validation en réduisant le traitement des données pendant les opérations de consensus.

Participation au Réseau - Les nœuds utilisant l'élagage de second ordre peuvent participer pleinement au réseau, valider de nouveaux blocs et contribuer au consensus sans nécessiter des ensembles de données de consensus historiques complets.

Nœuds d'Archivage vs Nœuds d'Élagage

Comportement du Nœud d'Archivage - Les nœuds configurés comme archivage ignorent entièrement l'élagage de premier et de second ordre, préservant toutes les données de consensus. Ces nœuds servent de registre de consensus complet du réseau mais nécessitent un stockage maximal.

Efficacité du Nœud d'Élagage - Les nœuds d'élagage réguliers utilisent l'élagage de second ordre pour atteindre une efficacité de stockage maximale tout en maintenant des capacités de validation de consensus complètes grâce au système de preuve multi-niveaux.

Note : Pour une explication détaillée de la façon dont les nœuds d'élagage restent des nœuds complets et pourquoi les nœuds d'archivage sont facultatifs pour le fonctionnement du réseau (maintenant le modèle sans confiance de Bitcoin), voir l'article étendu "Nœud d'Archivage vs Nœud Complet" qui couvre les capacités de validation, les preuves cryptographiques et la durabilité du réseau.

Bitcoin vs Kaspa : Élément des Données de Consensus

Bitcoin - Les informations de consensus sont essentielles pour la validation et ne peuvent pas être supprimées en toute sécurité.

Kaspa - La structure DAG complexe et le système de preuve multi-niveaux permettent un élagage de second ordre sophistiqué où différents niveaux de données de consensus peuvent être supprimés sélectivement en fonction de leur importance pour la validation. Cela permet une optimisation du stockage beaucoup plus agressive tout en maintenant les capacités de consensus.

---

Chapitre 8 : Kaspa GHOSTDAG simplifié

Qu'est-ce que GHOSTDAG et comment Kaspa l'utilise-t-il ?

Un protocole de consensus qui ordonne les blocs dans une structure DAG tout en maintenant les propriétés de sécurité.

Qu'est-ce que cela signifie ? Cet article explique GHOSTDAG en commençant par le consensus traditionnel, puis l'approche de GHOSTDAG, comment il classe les blocs, et comment il diffère entre Bitcoin et Kaspa.

Consensus Traditionnel - Ordre de Chaîne Linéaire

Le consensus traditionnel de la blockchain fonctionne sur une chaîne linéaire où les blocs forment une séquence unique. Chaque bloc a exactement un parent (sauf la Genèse), créant un mécanisme d'ordonnancement simple. Lorsque des conflits surviennent (plusieurs blocs à la même hauteur), le réseau sélectionne un bloc et rejette les autres comme orphelins. Cette approche assure un ordonnancement clair mais limite le débit car un seul bloc peut être accepté à chaque niveau.

Protocole GHOSTDAG - Consensus DAG

GHOSTDAG étend le consensus pour fonctionner avec des structures de graphes acycliques dirigés (DAG) où les blocs peuvent avoir plusieurs parents. Le protocole traite les blocs en sélectionnant d'abord un parent avec le "Blue Work" le plus élevé, puis en examinant tous les blocs du Mergeset pour les classer comme "bleus" (honnêtes) ou "rouges" (potentiellement conflictuels). Cette classification est basée sur des contraintes mathématiques impliquant le paramètre de sécurité K, qui limite la taille des Anticones pour maintenir les propriétés de sécurité.

Règles de Classification des Blocs

GHOSTDAG classe les blocs en utilisant deux contraintes clés liées au paramètre de sécurité K. Premièrement, le nombre de blocs bleus dans l'Anticône d'un bloc candidat ne doit pas dépasser K blocs. Deuxièmement, pour chaque bloc bleu existant, l'ajout du candidat ne doit pas faire en sorte que l'Anticône d'un bloc bleu dépasse K blocs. L'algorithme maintient un suivi de la taille de l'Anticône pour valider efficacement ces contraintes pendant le traitement des blocs. Le bloc gris ici est actuellement validé par le réseau, le bloc C est son Parent Sélectionné. Si k=0, alors le bloc de chaîne C est déjà 1 bloc bleu, ce qui entraîne la classification du bloc B comme Rouge. Si k = 1 (ou plus), le bloc B est classé comme bleu, car il n'a qu'1 bloc bleu (bloc C) dans son Anticône.

Accumulation de Blue Work

Le protocole accumule la preuve de travail uniquement à partir des blocs bleus, créant la métrique "Blue Work". Les blocs bleus contribuent leur travail de calcul au score de sécurité cumulatif, tandis que les blocs rouges sont exclus de ce calcul. Cette accumulation sélective garantit que seuls les blocs valides par consensus contribuent à la sécurité du réseau, empêchant les blocs malveillants ou conflictuels de saper le système. Dans cet exemple, supposons que le bloc B est rouge (k=0), le "Blue Work" de notre bloc gris serait calculé comme le "Blue Work" hérité du bloc C, plus le "Blue Work" du bloc C. Si le bloc B est bleu, le "Blue Work" de notre nouveau bloc hériterait du "Blue Work" de son Parent Sélectionné (bloc C), puis ajouterait le "Blue Work" de son Parent Sélectionné (C) et le "Blue Work" des blocs bleus de son Mergeset (bloc B).

Sélection et Ordonnancement des Parents

GHOSTDAG détermine l'ordonnancement des blocs par la sélection des parents basée sur les valeurs de "Blue Work". Le protocole sélectionne le parent avec le "Blue Work" accumulé le plus élevé comme "Parent Sélectionné", créant une chaîne dorsale au sein de la structure DAG. L'ordonnancement des blocs utilise le "Blue Work" comme critère principal, le hachage de l'en-tête des blocs fournissant un ordonnancement déterministe en cas d'égalité. Dans notre exemple, nous supposons que le bloc C est le Parent Sélectionné et que le bloc B est bleu. L'ordonnancement pour le traitement des transactions est 1. Parent Sélectionné (C) 2. Mergeset Ordonné (B)

Stockage et Gestion des Données

Le protocole stocke les résultats de classification dans des données structurées contenant des listes de blocs bleus et rouges. Les blocs bleus sont ajoutés avec un suivi de la taille de l'Anticône pour les décisions de classification futures, tandis que les blocs rouges sont simplement ajoutés à la liste rouge. Cette organisation maintient des informations DAG complètes tout en distinguant clairement les rôles de consensus.

Bitcoin et Kaspa

Bitcoin - Utilise le consensus de chaîne linéaire traditionnel où les blocs forment une séquence unique. Les blocs conflictuels sont orphelins et ne contribuent à aucune sécurité. La chaîne la plus longue (le travail le plus accumulé) détermine le consensus par un mécanisme de comparaison simple.

Kaspa - Utilise le protocole GHOSTDAG pour gérer les structures DAG avec plusieurs blocs concurrents. Les blocs bleus contribuent à la sécurité grâce à l'accumulation de "Blue Work", tandis que les blocs rouges restent dans le DAG mais sont exclus des décisions de consensus. Le protocole maintient les deux types de blocs pour un suivi complet de l'état du réseau.

---

Chapitre 9 : Terminologie DAG

Passé, Futur, Anticône, Mergeset, paramètre K, qu'est-ce que tout cela signifie ?

Passé, Futur et Anticône sont des termes DAG, tandis que Mergeset et K sont utilisés dans GHOSTDAG.

La terminologie DAG est un vocabulaire spécialisé pour décrire les relations dans une structure BlockDAG. Nous commencerons par la chaîne linéaire, le DAG, puis une touche de GHOSTDAG.

Terminologie de la Chaîne Linéaire - Blockchain Traditionnelle

La terminologie de la chaîne linéaire utilise des concepts simples où les blocs forment une séquence unique. Chaque bloc a un parent et potentiellement un enfant, créant des relations ascendant-descendant simples. Des termes comme "hauteur", "bloc précédent" et "bloc suivant" décrivent la progression linéaire. Lorsque des conflits surviennent, les blocs sont soit "acceptés" dans la chaîne principale, soit "orphelins" et écartés.

Terminologie DAG

Permettre aux blocs d'avoir plusieurs parents crée de nouvelles relations au sein du DAG.

Relations Passé et Futur - DAG

La relation Passé définit tous les blocs accessibles en suivant les liens parents en arrière à partir d'un bloc donné. Un bloc est dans le passé d'un autre s'il existe un chemin dirigé les connectant. La relation Futur fonctionne inversement - si le bloc A est dans le passé du bloc B, alors B est dans le futur de A.

Relation Anticône - DAG

L'Anticône décrit les blocs qui ne sont ni des ancêtres ni des descendants les uns des autres - ils existent concurremment dans le DAG. Deux blocs sont dans l'Anticône l'un de l'autre si aucun ne peut atteindre l'autre par un chemin dirigé. Cette relation est cruciale pour le paramètre de sécurité K de GHOSTDAG, qui limite la taille des Anticônes pour maintenir la sécurité du consensus. Ici, le bloc B et le bloc C sont dans l'Anticône l'un de l'autre, le bloc B n'est pas atteignable depuis le bloc C, et le bloc C n'est pas atteignable depuis le bloc B.

Mergeset et Classification Bleu/Rouge - GHOSTDAG

Le Mergeset fait référence à la collection de blocs qui sont fusionnés lors de la création d'un nouveau bloc. Le Mergeset contient les parents directs d'un bloc, mais peut également contenir des blocs qui ne sont pas des parents directs. GHOSTDAG classe les blocs du Mergeset comme "Bleus" (honnêtes) ou "Rouges" (potentiellement conflictuels) en fonction des contraintes de taille de l'Anticône. Cette classification détermine quels blocs contribuent à la sécurité du réseau grâce à l'accumulation de "Blue Work". Voici un exemple du bloc B classant son Mergeset en Bleu et Rouge lorsque la contrainte de taille de l'Anticône = 0.

Paramètre K - GHOSTDAG

Le paramètre K contrôle la taille maximale autorisée de l'Anticône pour les blocs bleus. Ce paramètre est calculé en fonction du délai du réseau, du taux de production de blocs et des garanties de sécurité souhaitées. Dans cet exemple, au lieu de k = 0 comme dans l'exemple ci-dessus, k = 1, de sorte que chaque bloc bleu a 1 autre bloc bleu dans son Anticône.

Bitcoin et Kaspa

Bitcoin - Utilise une terminologie linéaire simple : "bloc précédent", "bloc suivant", "hauteur de la chaîne" et "chaîne la plus longue". Les relations sont des connexions ascendant-descendant simples. Les blocs concurrents sont "orphelins" sans états intermédiaires.

Kaspa - Utilise une terminologie supplémentaire, y compris les relations Passé/Futur/Anticône du DAG, le Mergeset de GHOSTDAG et la classification Bleu/Rouge du Mergeset. Kaspa maintient plusieurs blocs concurrents, gère leurs relations et fournit un ordonnancement cohérent.

---

Chapitre 10 : Élément de Premier Ordre

Qu'est-ce que l'élagage de premier ordre et comment Kaspa l'utilise-t-il ?

L'élagage de premier ordre est la première étape de l'optimisation du stockage multi-phases de Kaspa. Il supprime les anciennes données de transaction des blocs tout en maintenant un ensemble UTXO au point d'élagage pour la validation de l'état - mais surtout, il préserve tous les en-têtes de bloc pour maintenir l'intégrité de la blockchain.

Pourquoi "Premier Ordre" ? - Cette terminologie souligne que la suppression des corps de blocs n'est qu'un début. Bien que l'élagage de premier ordre réduise considérablement les besoins de stockage et abaisse les barrières à l'exécution d'un nœud (augmentant la décentralisation), il est suivi d'étapes d'élagage supplémentaires qui peuvent supprimer encore plus de données (élagage de second ordre). Cet article se concentre spécifiquement sur la suppression du corps de bloc - la fondation qui rend toutes les optimisations ultérieures possibles.

Qu'est-ce que cela signifie ? - Cet article ne présuppose aucune connaissance préalable, nous commencerons donc par les défis de stockage traditionnels de la blockchain, puis nous expliquerons comment l'élagage de premier ordre fonctionne en maintenant des ensembles UTXO, ce qui est supprimé par rapport à ce qui est préservé, comment l'ensemble UTXO du point d'élagage permet la validation, et comment cela crée la fondation pour le modèle de stockage évolutif de Kaspa qui permet une participation plus large au réseau.

Stockage Traditionnel vs Élément de Premier Ordre

Stockage Complet Traditionnel - Dans les implémentations de blockchain traditionnelles, les nœuds stockent des données de bloc complètes, y compris tous les détails de transaction de la Genèse à la pointe actuelle. Cela signifie que chaque entrée, sortie, signature et script de transaction est préservé pour toujours, ce qui entraîne des besoins de stockage toujours croissants qui peuvent devenir prohibitifs pour de nombreux utilisateurs.

Défi de l'élagage de Premier Ordre - Le défi est de supprimer les anciennes données de transaction tout en étant capable de valider de nouvelles transactions. Les nouvelles transactions doivent référencer des sorties précédentes (UTXO), de sorte que le système doit maintenir suffisamment d'informations pour valider ces références même après l'élagage des anciens corps de blocs.

L'ensemble UTXO comme fondation

Définition de l'ensemble UTXO - L'ensemble UTXO représente toutes les sorties de transaction non dépensées à un point spécifique de la blockchain. Un instantané de toutes les "pièces" qui existent et peuvent être dépensées à ce moment-là, similaire à un inventaire de tout l'argent en circulation.

Ensemble UTXO du Point d'Élagage - Kaspa maintient un ensemble UTXO spécial au Point d'Élagage, qui sert d'état de base pour la validation. Cet ensemble UTXO est mis à jour à mesure que le Point d'Élagage avance, garantissant qu'il reflète toujours l'état dépensable correct à ce point de contrôle.

Avancement de l'UTXO Set - Lorsque le Point d'Élagage avance, le système applique les différences UTXO des blocs de la chaîne pour mettre à jour l'ensemble UTXO du point d'élagage. Ce processus garantit que l'ensemble UTXO reste précis à mesure que les anciennes données sont élaguées.

Ce qui est élagué dans l'élagage de Premier Ordre

Suppression des Données du Corps de Bloc - L'élagage de premier ordre supprime les données de transaction réelles des anciens blocs, y compris les entrées, sorties, signatures et scripts de transaction. Cela inclut les multisets UTXO, les différences UTXO, les données d'acceptation et le magasin complet des transactions de bloc.

Préservation de l'En-tête - Bien que les données de transaction soient supprimées, les en-têtes de bloc sont préservés pour maintenir l'intégrité structurelle de la blockchain. Les blocs passent au statut "en-tête seulement", indiquant que l'en-tête existe mais que le corps a été élagué.

Rétention des Données Essentielles - Le système préserve les données critiques nécessaires à la validation du consensus, y compris l'anticône du point d'élagage, les blocs de la fenêtre DAA et les blocs GHOSTDAG. Cela garantit que les opérations de consensus peuvent continuer même après l'élagage.

Comment l'ensemble UTXO permet la validation

Processus de Validation des Transactions - Les nouvelles transactions peuvent être validées par rapport à l'ensemble UTXO du point d'élagage plus toutes les modifications UTXO ultérieures. Le système valide que les UTXO référencés existent et n'ont pas été double-dépensés, même sans les données de transaction originales.

Reconstruction de l'État - L'ensemble UTXO au point d'élagage, combiné aux différences UTXO des blocs ultérieurs, permet la reconstruction de l'état dépensable actuel. Cela permet des capacités de validation complètes sans nécessiter de données de transaction historiques complètes.

Vérification de l'Engagement - Le système peut vérifier l'intégrité de l'ensemble UTXO en utilisant des engagements cryptographiques dans les en-têtes de bloc. Cela garantit que l'ensemble UTXO élagué correspond à ce que les en-têtes de la blockchain prétendent qu'il devrait être.

Nœuds d'Archivage vs Nœuds d'Élagage

Comportement du Nœud d'Archivage - Les nœuds configurés comme archivage ignorent entièrement l'élagage de premier ordre, préservant toutes les données de transaction. Ces nœuds servent de registre historique complet du réseau mais nécessitent un stockage nettement plus important.

Efficacité du Nœud d'Élagage - Les nœuds d'élagage réguliers utilisent l'élagage de premier ordre pour maintenir un stockage gérable tout en participant pleinement à la validation du consensus. L'ensemble UTXO fournit suffisamment d'informations pour valider de nouvelles transactions sans nécessiter de données historiques complètes.

Répondre aux préoccupations concernant l'élagage et la preuve de genèse

Une préoccupation récurrente est que les lacunes dans l'historique du registre dues à l'élagage pourraient compromettre la vérifiabilité de la chaîne depuis sa création (le bloc de genèse), et notamment la preuve qu'il n'y a pas eu de pré-minage.

Cette inquiétude est infondée. Voici pourquoi :

1. Le bloc de genèse est intégré au code : Le bloc de genèse lui-même est "hardcodé" dans le logiciel du nœud Kaspa. Ce bloc de genèse contient un ensemble UTXO vide, ce qui prouve qu'il n'y a eu aucun pré-minage. Tout utilisateur peut vérifier cela dans le code source public.
2. La preuve de genèse : Chaque nœud conserve une "preuve de genèse". Il s'agit d'une chaîne de données courte qui prouve cryptographiquement que l'état actuel du registre a bien évolué à partir du bloc de genèse intégré. Forger une telle preuve nécessiterait autant de travail que celui qui a été investi pour créer l'ensemble du registre. En d'autres termes, cette preuve est aussi solide que de posséder l'historique complet.
3. L'intégrité de l'historique reconstitué : Bien que des efforts soient faits pour reconstituer l'historique complet à des fins de recherche et de commodité, le processus est décentralisé. Les données sont collectées auprès de nombreux utilisateurs. Aucun acteur unique n'a le contrôle sur les "lacunes" restantes, ce qui rend impossible de "cacher" sélectivement une partie de l'historique.

En résumé, le mécanisme d'élagage de Kaspa est conçu pour que le réseau reste sûr, sécurisé et transparent, même sans aucun nœud d'archivage. La vérifiabilité de la chaîne depuis sa genèse est garantie par des preuves cryptographiques robustes, et non par la nécessité de stocker un historique complet et de plus en plus lourd.

Bitcoin vs Kaspa : Amorçage du Nœud Complet

Bitcoin - Les nœuds complets doivent télécharger et valider toutes les données de bloc de la genèse pour s'amorcer, nécessitant des données de transaction historiques complètes. Bien que Bitcoin prenne en charge un élagage simple après la synchronisation initiale, les nouveaux nœuds ont toujours besoin de l'historique complet de la blockchain pour établir l'état initial. La structure de la chaîne linéaire rend ce processus simple mais gourmand en stockage.

Kaspa - Les nœuds complets peuvent s'amorcer en utilisant des preuves d'élagage sans télécharger de données historiques complètes, grâce à l'intégration de l'élagage de premier ordre avec le protocole de consensus. Le système valide les preuves d'élagage et applique des données vérifiables cryptographiquement ("données fiables") pour établir l'état initial. Ces "données fiables" ne nécessitent aucune confiance en aucune partie - elles sont vérifiées mathématiquement par des preuves cryptographiques qui garantissent que les données correspondent aux règles de consensus. Le processus de validation prouve cryptographiquement que la preuve du point d'élagage représente un état de consensus valide, tandis que les données fiables subissent une vérification rigoureuse pour s'assurer qu'elles correspondent à l'état attendu de la blockchain. Cela permet aux nouveaux nœuds de se synchroniser efficacement tout en maintenant des capacités de validation complètes sans faire confiance à une partie externe.

---

Chapitre 11 : Nœuds d'Archivage vs Nœuds Complets

Nœuds d'Archivage de Kaspa vs Nœuds d'Élagage

Les Nœuds d'Élagage Sont des Nœuds Complets - Les nœuds d'élagage qui utilisent l'élagage de premier ordre et l'élagage de second ordre sont toujours considérés comme des Nœuds Complets car ils maintiennent des capacités de validation complètes. Ils peuvent valider tous les nouveaux blocs, participer au consensus et servir le réseau sans nécessiter de confiance en des parties externes. Le système de preuve de point d'élagage garantit que même avec des données élaguées, ces nœuds maintiennent une vérification cryptographique de l'état complet de la blockchain.

Les Nœuds d'Archivage Sont Facultatifs - Les nœuds d'archivage qui conservent toutes les données historiques ne sont pas nécessaires pour que le réseau Kaspa fonctionne indéfiniment. Le réseau peut fonctionner entièrement avec des nœuds d'élagage car les preuves de point d'élagage fournissent des garanties mathématiquement vérifiables concernant l'état élagué. Ceci est en contraste avec Bitcoin, où le réseau nécessite des Nœuds d'Archivage (qui stockent l'historique complet des transactions depuis la genèse) pour amorcer un nouveau nœud.

Aucune Exigence de Confiance Supplémentaire - Le système d'élagage maintient le modèle sans confiance de Bitcoin en utilisant des preuves cryptographiques plutôt que des parties de confiance. Les nouveaux nœuds peuvent s'amorcer à partir de preuves d'élagage et vérifier l'état complet de la blockchain sans télécharger l'intégralité des données historiques, tout en maintenant les mêmes garanties de sécurité que les nœuds qui stockent tout depuis la Genèse.

Durabilité du Réseau - Cette conception garantit que le réseau Kaspa peut évoluer de manière durable sans exiger un stockage toujours croissant de la part des participants. Les nœuds d'élagage offrent la même sécurité de consensus que les nœuds d'archivage tout en permettant une participation plus large au réseau grâce à des exigences matérielles réduites.

Comportement du Nœud d'Archivage - Les nœuds configurés comme archivage ignorent entièrement l'élagage de premier ordre et l'élagage de second ordre, préservant toutes les données de consensus (et les données d'application historiques). Ces nœuds servent de registre de consensus complet du réseau mais nécessitent un stockage maximal et sont purement facultatifs pour le fonctionnement du réseau.

Efficacité du Nœud d'Élagage - Les nœuds d'élagage réguliers (Nœuds Complets) utilisent l'élagage pour atteindre une efficacité de stockage maximale tout en maintenant des capacités de validation de consensus complètes grâce au système de preuve multi-niveaux. Ces nœuds sont indiscernables des nœuds d'archivage en termes de sécurité et de capacités de validation.

---

Chapitre 12 : Kaspa : Une Évolution dans l'Architecture Décentralisée Économe en Énergie

Introduction : La Physique de l'Argent et de l'Efficacité

Dans le monde des réseaux décentralisés, l'efficacité n'est pas seulement un luxe, c'est un trait de survie. Les cryptomonnaies fonctionnent comme des systèmes d'énergie monétaire, où l'énergie du monde réel est convertie en enregistrements de valeur sécurisés et immuables. Tout comme les systèmes physiques s'efforcent de minimiser l'énergie gaspillée et l'entropie, un réseau crypto bien conçu devrait minimiser le gaspillage et la friction. Bitcoin a été le pionnier de ce concept en liant la valeur monétaire à la dépense d'énergie de la preuve de travail, créant une forme d'"or numérique" sécurisée par le coût thermodynamique. Mais l'architecture de Bitcoin, bien que révolutionnaire, comporte des inefficacités structurelles qui limitent son débit et gaspillent une partie de l'énergie que les mineurs y consacrent.

Voici Kaspa - un réseau de preuve de travail de nouvelle génération qui redéfinit l'architecture du consensus décentralisé. Kaspa est construit sur un blockDAG (Directed Acyclic Graph) plutôt que sur une seule chaîne, permettant à plusieurs blocs d'être créés et traités en parallèle. Cette conception vise à minimiser l'entropie et l'inefficacité du système, faisant de Kaspa une sorte de "moteur efficace" pour stocker et déplacer la valeur économique.

Entropie, Énergie et Systèmes Monétaires

Pour comprendre l'importance de Kaspa, nous devons d'abord saisir comment l'énergie et l'entropie se rapportent aux systèmes monétaires. En physique, créer de l'ordre (faible entropie) à un endroit nécessite de dépenser de l'énergie et d'augmenter l'entropie ailleurs - un principe qui s'applique également à l'argent. L'argent fort comme l'or a historiquement tiré sa valeur de l'immense énergie et du travail nécessaires pour l'obtenir. Bitcoin a appliqué ce même principe numériquement, en exigeant des mineurs qu'ils effectuent des calculs coûteux (hachage) pour ajouter des blocs, garantissant ainsi que chaque pièce et chaque bloc portent une preuve d'énergie dépensée. Cependant, si une partie significative du travail est gaspillée ou si la conception du système cause des frictions inutiles, alors le "moteur monétaire" perd de l'énergie sous forme de chaleur.

Friction dans les Systèmes Économiques

En économie, la friction fait référence à tout ce qui cause une perte ou une inefficacité dans le mouvement de la valeur. Bitcoin a introduit une certaine friction par nécessité : sa conception échange la vitesse contre la sécurité. Les transactions attendent environ 10 minutes en moyenne pour un nouveau bloc, et la convention est d'attendre 6 confirmations (environ 1 heure) pour une assurance élevée contre l'inversion. Cette latence et ce faible débit créent une friction économique. De plus, le processus de minage de Bitcoin produit parfois un travail gaspillé sous forme de blocs orphelins (lorsque deux mineurs trouvent un bloc valide presque au même moment, un seul bloc fait partie de la chaîne principale et l'autre est écarté). Ces blocs orphelins représentent une énergie réelle dépensée par les mineurs qui ne contribue pas durablement au registre.

Le Goulot d'Étranglement de la Chaîne Unique de Bitcoin

La blockchain de Bitcoin peut être visualisée comme une route à une seule voie pour les transactions. Un seul bloc peut être accepté à la fois, et chaque bloc doit s'aligner séquentiellement. Si deux blocs arrivent en même temps, l'un sera forcé de céder et sera effectivement écarté comme un orphelin. Cette conception a été choisie délibérément pour maintenir le système en ordre, mais au prix de graves limitations de performances. Les limitations de cette architecture à chaîne unique sont bien connues : manque d'évolutivité, susceptibilité aux attaques de minage égoïste si les temps de bloc étaient réduits, et blocs gaspillés sont des problèmes inhérents. De manière critique, le consensus de Bitcoin gaspille une partie petite mais non négligeable du travail de minage sur des blocs qui ne font jamais partie du registre. Ces blocs orphelins sont l'entropie du système - de l'énergie qui a augmenté le désordre et a été évacuée sous forme de chaleur, non stockée comme information utile. Le résultat est que l'énorme énergie de minage de Bitcoin ne produit qu'un filet de débit.

Le BlockDAG de Kaspa : Parallélisme sans Travail Gaspillé

Kaspa a abordé le problème en se demandant : et si les blocs n'avaient pas à s'aligner en file indienne ? Au lieu d'une route à une voie, Kaspa utilise une autoroute à plusieurs voies pour les blocs, où de nombreux blocs peuvent être créés en parallèle et toujours fusionner en un seul registre. L'innovation fondamentale est l'architecture blockDAG de Kaspa (Directed Acyclic Graph) combinée au protocole de consensus GHOSTDAG. Dans un blockDAG, les blocs ne pointent pas vers un seul bloc précédent (la pointe de la "chaîne la plus longue") comme dans Bitcoin ; au lieu de cela, chaque bloc peut référencer plusieurs prédécesseurs, y compris différentes "pointes" du graphe. Les blocs qui seraient considérés comme concurrents ou orphelins dans Bitcoin ne sont pas écartés dans Kaspa - ils sont incorporés dans le graphe du registre. La structure DAG permet à ces blocs simultanés de coexister et d'être finalement ordonnés de manière cohérente par l'algorithme GhostDAG. Tous les blocs valides contribuent à l'historique du registre ; aucune preuve de travail du mineur n'est gaspillée.

L'impact de cette conception sur l'efficacité est spectaculaire. Premièrement, aucune puissance de minage n'est gaspillée sur les blocs orphelins. Deuxièmement, le parallélisme de Kaspa augmente considérablement le débit. Kaspa fonctionne avec un taux de base de 1 bloc par seconde sur son réseau principal (et a récemment été mis à niveau à 10 blocs par seconde), contre 0,1 bloc par seconde pour Bitcoin. C'est une augmentation de 10 fois de la fréquence des blocs par conception, avec des plans pour encore plus. De plus, parce que chaque bloc Kaspa est plus petit (pour maintenir les exigences des nœuds faibles) mais qu'ils arrivent beaucoup plus souvent, les transactions sont réparties sur de nombreux blocs. Le résultat final est un potentiel de débit de milliers de transactions par seconde. En fait, l'algorithme GhostDAG a démontré qu'il pouvait supporter environ 3000 transactions par seconde avec 10 blocs/sec sur des réseaux de test utilisant du matériel courant. Cela a été réalisé tout en maintenant des exigences matérielles modestes. En d'autres termes, l'architecture de Kaspa n'oblige pas à un compromis entre l'évolutivité et la décentralisation - elle traite beaucoup plus de transactions sans augmenter la barrière à l'entrée pour les nœuds. Chaque participant peut toujours valider la chaîne sur des ordinateurs ordinaires, ce qui est crucial pour la décentralisation. Contrairement à de nombreux systèmes à haut débit qui s'appuient sur des nœuds de centre de données puissants ou compromettent le consensus, Kaspa reste un pur système de preuve de travail avec une large distribution de minage et de nœuds complets.

Comment Kaspa maintient-il un historique unique et convenu (une source unique de vérité) si les blocs arrivent en parallèle ? La réponse est GhostDAG, un algorithme de consensus qui ordonne les blocs dans le DAG en considérant non seulement la "chaîne la plus longue" (comme dans Bitcoin) mais le "sous-graphe le plus lourd" de blocs. GhostDAG attribue à chaque bloc une sorte de score ou d'ordonnancement basé sur la quantité d'historique validé qui le précède et la façon dont il référence d'autres blocs. Il trouve un motif appelé k-cluster - essentiellement un ensemble de blocs mutuellement conscients - et l'utilise pour décider quels blocs font partie de la structure ordonnée principale (colorés en "bleu") et quels sont hors de la structure principale ("rouge") mais toujours inclus. L'algorithme est gourmand mais converge de manière prouvable vers un historique unique similaire au consensus de Nakamoto, sauf qu'il peut le faire même lorsque de nombreux blocs sont en cours. La garantie formelle est qu'à mesure que les blocs s'accumulent, la probabilité que l'ordonnancement d'un bloc donné change (c'est-à-dire une inversion de fork) diminue de manière exponentielle, tout comme avec les confirmations de Bitcoin - mais cette assurance est obtenue à des taux de bloc beaucoup plus élevés. En termes pratiques, les transactions Kaspa sont profondément enfouies sous de nombreux blocs beaucoup plus rapidement que sur Bitcoin, ce qui les rend très sécurisées contre les réorganisations en quelques secondes. L'équipe de Kaspa note que l'ordonnancement de GhostDAG "devient exponentiellement difficile à inverser à mesure que le temps passe", même à des taux de création de blocs élevés. La finalité est rapide ; le réseau atteint ce que l'on pourrait appeler une irréversibilité thermodynamique des transactions à l'échelle humaine.

Étant donné que tous les blocs sont conservés, les mineurs de Kaspa n'ont aucune incitation à retenir ou à miner stratégiquement de manière égoïste pour orpheliner les blocs des autres - un comportement qui peut être rationnel dans des contextes de blockchain plus rapides. La stratégie de Kaspa de révélation maximale d'informations (chaque bloc référence toutes les pointes qu'il connaît) signifie que le réseau est rapidement informé de tous les blocs parallèles. Cela inonde le graphe de connaissances, réduisant l'incertitude. En termes de théorie de l'information, Kaspa minimise l'entropie de l'état du réseau en garantissant qu'aucune fourche invisible ne persiste longtemps ; tout est intégré. Le "principe de révélation maximale" vise essentiellement à réduire l'entropie (incertitude) du système en partageant les données rapidement. Cela s'aligne à nouveau sur les principes physiques : pour maintenir l'ordre, vous voulez propager l'information (ou les signaux énergétiques) aussi efficacement que possible à travers le système.

Il est important de noter que Kaspa y parvient sans compromettre la sécurité ou la décentralisation. Il utilise toujours la preuve de travail, ce qui signifie que la validité de chaque bloc est garantie par l'énergie réelle dépensée. Et parce que les blocs sont plus petits et fréquents, la bande passante et le stockage des nœuds ont été soigneusement gérés (avec des techniques comme l'élagage et la gestion efficace des UTXO) afin que même un ordinateur domestique puisse suivre. Le résultat est un réseau qui offre "une sécurité et une décentralisation de qualité preuve de travail avec des performances comparables à celles des réseaux de preuve d'enjeu de pointe". Contrairement à certains projets qui ont résolu le problème de l'évolutivité en abandonnant la PoW ou en centralisant la production de blocs, Kaspa préserve la sécurité physique de la preuve de travail du consensus de Nakamoto. Il n'y a pas de dépendance vis-à-vis de validateurs privilégiés ou de points de contrôle de comité - ce sont toujours des mineurs qui rivalisent avec des hachages - mais maintenant, le bloc de chaque mineur trouve sa place dans l'historique, et le débit du réseau n'est plus étranglé par le participant le plus lent.

Pour le dire simplement, le protocole GhostDAG de Kaspa supprime le goulot d'étranglement structurel que Bitcoin avait jugé inévitable. Le vieux trilemme "sécurité vs vitesse vs décentralisation" est, selon Kaspa, entièrement résolu en pratique. En s'écartant du modèle de chaîne linéaire, Kaspa ouvre les vannes du débit sans sacrifier la sécurité de Nakamoto - une prouesse que de nombreux chercheurs pensaient impossible pendant des années. Tout cela conduit à un système où les blocs arrivent en continu comme des gouttelettes dans une fontaine bien synchronisée, plutôt que les blocs ponctuels et intermittents de l'horloge de Bitcoin. Les transactions sur Kaspa sont confirmées en quelques secondes et finalisées (avec une probabilité de réorganisation négligeable) généralement en quelques dizaines de secondes. En fait, l'objectif de conception de Kaspa était des temps de confirmation limités uniquement par la latence du réseau - aussi rapide que l'information peut physiquement voyager sur Internet. Le réseau livre déjà des transactions entièrement confirmées en environ 10 secondes en moyenne, et ce nombre diminue à mesure que les taux de blocs augmentent. Du point de vue de l'utilisateur, cela signifie qu'envoyer de la valeur via Kaspa ressemble presque à un paiement par carte de crédit ou à un transfert d'argent liquide - le règlement est presque instantané, mais avec l'avantage supplémentaire qu'il est irréversible et sans confiance.

Atteindre le Débit à la Vitesse de la Lumière

Une façon d'apprécier l'alignement de Kaspa avec les principes physiques est d'examiner sa gestion de la latence, le délai d'un côté à l'autre du monde. Le temps d'aller-retour global d'Internet (RTT) - essentiellement le temps qu'il faut à un signal pour aller aux antipodes et revenir - est de l'ordre de 200 millisecondes (0,2 seconde) dans le meilleur des cas (limité par la vitesse de la lumière dans la fibre et les sauts de réseau). Les blockchains traditionnelles comme Bitcoin fonctionnent des ordres de grandeur plus lentement que cette limite (600 secondes par bloc), de sorte que la latence du réseau n'est pas un facteur majeur dans leur conception ; elles vivent dans un régime d'équilibre confortable et lent. Mais Kaspa s'est audacieusement aventuré dans le régime où les temps de bloc sont de l'ordre de la latence du réseau - actuellement 100 millisecondes par bloc dans la nouvelle mise à niveau (10 BPS), ce qui est en fait plus rapide que la propagation unidirectionnelle vers l'autre côté de la Terre. C'est un seuil critique. Passer d'un temps de bloc de 1 seconde à un temps de bloc de 0,1 seconde n'est pas seulement une amélioration quantitative de 10 fois ; c'est un saut qualitatif qui a nécessité de repenser le consensus.

Pourquoi ? Si vous essayez d'exécuter un consensus à chaîne unique (linéaire) avec des blocs de 100 ms dans un réseau mondial, vous auriez un chaos total - à peine un nœud a-t-il entendu parler d'un bloc que cinq autres ont déjà été trouvés. Le délai de propagation signifierait que le réseau n'est jamais synchronisé ; les forks proliféreraient et le consensus se briserait ou se centraliserait (seules les connexions les plus rapides gagneraient toujours). Kaspa est le premier système de preuve de travail à démontrer un consensus dans ce régime sub-RTT, et il peut le faire précisément parce que son GhostDAG multi-leader peut gérer de nombreux blocs simultanés avec élégance. Comme l'a noté le développeur principal Michael Sutton lors de la mise à niveau Crescendo de Kaspa (qui a fait passer le réseau principal de 1 BPS à 10 BPS), "Augmenter le taux de blocs à 10 par seconde, obtenu en réduisant le temps de bloc à 100 ms (< 200 ms ≊ RTT global), ne peut être sécurisé qu'avec un protocole de consensus qui permet intrinsèquement le parallélisme... Franchir le seuil RTT est donc un saut qualitatif, et non pas seulement quantitatif.". En d'autres termes, la conception de Kaspa est fondamentalement alignée sur les limites physiques du transfert d'informations - elle est structurée pour fonctionner à la vitesse maximale que les lois de la physique (vitesse de la lumière, bande passante du réseau) permettent, alors qu'une chaîne linéaire ne peut pas franchir cette limite en toute sécurité sans sacrifier la sécurité ou supposer un rayon de réseau plus petit.

Il convient de souligner à quel point cela est remarquable dans le contexte des systèmes distribués. Kaspa réalise un consensus mondial et asynchrone avec des temps de bloc plus courts que les délais de communication mondiaux. Et il le fait sans réduire le réseau ni nécessiter une configuration spéciale de confiance. Le réseau reste vaste et sans permission - les nœuds peuvent être n'importe où dans le monde, connectés par des liens Internet standard - et pourtant Kaspa produit et confirme des blocs plus rapidement que n'importe quelle chaîne unique ne pourrait l'imaginer dans ces conditions. Le protocole GhostDAG permet essentiellement ce que la théorie classique du consensus aurait cru impossible sous une règle stricte de la chaîne la plus longue : maintenir tout le monde en accord malgré des mini-forks constants (blocs parallèles). L'idée est qu'en permettant à ces forks d'exister et en les ordonnant ensuite de manière probabiliste, vous embrassez le chaos et l'organisez, plutôt que d'essayer de l'empêcher entièrement. Le résultat est un débit maximal.

Lors de l'activation du hard fork Crescendo, les développeurs de Kaspa ont noté que le système était conçu de telle sorte que même à 10 BPS, il n'était pas nécessaire d'avoir un superordinateur pour faire fonctionner un nœud. L'implémentation en Rust et les optimisations du protocole garantissent qu'un PC moyen avec une connexion Internet domestique peut suivre 10 blocs par seconde et des milliers de transactions par seconde. Cela témoigne d'une éthique de conception axée sur l'efficacité à tous les niveaux - non seulement le débit brut, mais aussi l'utilisation efficace des ressources de calcul et de la bande passante. Par exemple, les blocs restent compacts, et la structure DAG est élaguée et gérée de manière à ne pas devenir incontrôlable. Kaspa inclut même de nouvelles techniques (comme le prochain DAGKnight et les stratégies d'élagage) pour s'adapter aux conditions du réseau et limiter la taille de l'état. Tous ces choix reflètent un minimalisme presque physique : éliminer le gaspillage, qu'il s'agisse de puissance de hachage gaspillée, de temps gaspillé ou de stockage gaspillé. Si le minage de Bitcoin est parfois critiqué pour produire beaucoup de chaleur (énergie gaspillée par transaction), Kaspa réduit considérablement l'énergie par transaction en augmentant le débit et en utilisant un algorithme de hachage plus économe en énergie (kHeavyHash). L'équipe de Kaspa a explicitement conçu kHeavyHash pour être compatible avec le minage optique et léger en ressources, ce qui signifie qu'il pourrait potentiellement fonctionner sur du matériel spécialisé qui utilise beaucoup moins d'électricité. Combiné à la politique du DAG de "pas de blocs gaspillés", cela rend Kaspa moins énergivore que d'autres réseaux PoW par transaction ou par valeur transférée. En termes simples, Kaspa peut faire plus avec chaque joule d'énergie que les mineurs y mettent - un témoignage de son ingénierie supérieure. Même des observateurs indépendants notent cette efficacité : "L'algorithme KHeavyHash est conçu pour optimiser la consommation d'énergie, rendant [Kaspa] moins gourmand en ressources par rapport à... Bitcoin". Nous pouvons considérer cela comme une amélioration de l'efficacité thermodynamique du système : une plus grande partie de l'énergie d'entrée se transforme en transactions sécurisées et finalisées (travail utile) plutôt qu'en hachage gaspillé ou en temps d'attente.

En poussant les limites physiques de manière responsable, Kaspa se positionne comme un réseau monétaire très efficace sur le plan thermodynamique. Il aligne la cadence de production de blocs avec la communication la plus rapide possible, élimine le travail redondant et garantit que chaque bit de travail contribue à l'ordonnancement des transactions. En analogie, si Bitcoin est comme un moteur thermique ancien qui produit beaucoup de chaleur perdue et tourne à bas régime, Kaspa est comme une turbine moderne fonctionnant près de sa limite d'efficacité théorique - extrayant le plus de mouvement utile (débit de transaction) possible de chaque unité de carburant (énergie de hachage). Les lois de la physique fixent un plafond strict, et Kaspa est déterminé à atteindre ce plafond. Cet alignement avec les "flux directionnels" de l'évolution technologique (plus de rendement pour moins d'intrants) suggère que Kaspa suit une trajectoire évolutive que nous avons observée dans de nombreux autres systèmes - des processeurs monocœurs aux processeurs multicœurs et au traitement parallèle, de l'Internet commuté au haut débit, des calèches aux autoroutes à plusieurs voies. Les systèmes qui exploitent le parallélisme et réduisent la résistance interne surpassent inévitablement ceux qui restent bloqués par un seul processus séquentiel.

Moins de Friction, Meilleure Rétention de Valeur

Les vertus techniques de la conception de Kaspa ont de profondes implications économiques. Lorsque nous réduisons l'entropie et la friction dans un système monétaire, nous créons un environnement plus hospitalier pour que la valeur réside et circule. Considérons une économie comme un écosystème vivant ou peut-être un réseau électrique : si l'énergie (ou l'argent) peut circuler librement là où elle est nécessaire avec un minimum de pertes, le système prospère et grandit. Le réseau à faible latence et à haut débit de Kaspa signifie que la valeur peut être échangée rapidement et à moindre coût par n'importe qui, n'importe quand, sans être siphonnée par des intermédiaires ou des coûts d'attente élevés. Cette propriété attire naturellement l'utilisation - les utilisateurs préféreront un système où leurs paiements sont confirmés en une seconde plutôt qu'un système où ils attendent une heure, surtout lorsque la sécurité est comparable. À mesure que l'utilisation augmente, la liquidité et le capital gravitent vers le réseau, augmentant son utilité dans une boucle de rétroaction. L'économie 101 nous dit que, étant donné deux options, les gens choisiront celle avec les coûts de transaction les plus bas (toutes choses égales par ailleurs), et l'argent circulera par le canal qui offre le moins d'impédance au commerce. Kaspa se présente comme ce canal à faible impédance : "travail dissipé minimum, impédance transactionnelle minimale, clarté monétaire maximale", comme l'a décrit un observateur le point de convergence où le capital affluera. Avec Kaspa, les barrières traditionnelles - délais de confirmation, plafonds de débit, frais élevés en cas de congestion - sont considérablement minimisées, de sorte que le "tuyau" pour l'énergie monétaire est large et lisse.

Plan K, dans une interview sur l'économie de Kaspa, a utilisé une analogie biologique pour décrire comment une monnaie efficace dirige l'énergie : une bonne monnaie est comme le système vasculaire d'une plante qui canalise les nutriments (énergie) vers les feuilles qui font la photosynthèse (travail productif), plutôt que de laisser les ressources être aspirées par des parasites ou des parties inactives. Dans cette analogie, Kaspa peut être considéré comme une forme de monnaie à faible entropie qui encourage un flux d'énergie efficace. Sa vitesse et sa capacité garantissent que l'énergie économique (valeur) se déplace vers des utilisations productives (transferts réels de biens et services) au lieu d'être gaspillée dans des arriérés ou de l'arbitrage entre les couches. Pendant ce temps, sa base de preuve de travail empêche le détournement d'énergie qui se produit avec la "monnaie facile". Les monnaies fiduciaires, par exemple, ont été comparées à une vigne parasite dans l'analogie de Plan K - elles peuvent être gonflées ou copiées par les autorités centrales, siphonnant efficacement l'énergie de l'économie productive en diluant la valeur. Kaspa, comme Bitcoin, s'immunise contre une telle dilution en exigeant un travail réel pour la création de nouvelles pièces et en limitant strictement la croissance de l'offre. Comme l'a noté Plan K, "L'or, le Bitcoin et Kaspa sont similaires à [des hormones] qui ne peuvent pas être copiées, empêchant tout détournement d'énergie". En termes plus simples, ces monnaies fortes bloquent l'énergie qui a été utilisée pour les produire ; elles offrent un réservoir sécurisé pour la valeur économique sans fuite par dévalorisation.

Kaspa étend ce principe de monnaie forte au domaine de l'utilisabilité quotidienne. Bitcoin a prouvé qu'un réseau décentralisé peut stocker de la valeur en toute sécurité (faible entropie dans le temps), mais Kaspa vise également à déplacer la valeur efficacement (faible entropie dans les transactions). En mariant le coût inforgeable de Bitcoin avec une couche transactionnelle sans friction, Kaspa se positionne comme une solution complète pour l'argent : une réserve de valeur, un moyen d'échange et une unité de compte tout en un, sans les compromis habituels. Il est instructif de se rappeler pourquoi historiquement l'or avait besoin d'un substitut (comme le papier-monnaie ou la monnaie fiduciaire) pour les transactions quotidiennes - parce que l'or était lourd et lent à déplacer, introduisant des frictions. Bitcoin, étant lent et avec un débit limité, a de même invité les réseaux de couche 2 ou les pièces concurrentes à combler le vide pour les paiements rapides, cédant essentiellement le rôle de moyen d'échange à des monnaies "plus douces". Kaspa, en revanche, est suffisamment rapide et évolutif pour ne pas nécessiter un réseau monétaire secondaire pour gérer le volume. Il peut être à la fois la couche de règlement de haute intégrité et la couche de transaction à grande vitesse. Cela suggère un avenir où l'activité économique n'aura pas besoin de passer constamment d'un "réseau de réserve de valeur" à un "réseau de paiement" (avec toutes les frictions d'échange et les compromis de sécurité que cela implique) - au lieu de cela, un seul réseau peut tout faire efficacement. En effet, les partisans soutiennent que parce que Kaspa a résolu le trilemme, "il n'y a plus de lacune sur le marché monétaire que Kaspa ne comble pas", éliminant le besoin de magasins de base plus lents comme Bitcoin ou d'alternatives plus rapides mais plus faibles. Que Bitcoin reste une couche de règlement de grande valeur et Kaspa davantage pour l'échange, ou que Kaspa absorbe finalement les deux rôles, le marché décidera. Mais une chose est claire : les systèmes qui gaspillent moins et livrent plus l'emporteront sur ceux qui ne le font pas à long terme. C'est la sélection naturelle appliquée aux systèmes monétaires.

Une friction moindre signifie également que les mineurs et les utilisateurs sont mieux alignés dans l'écosystème de Kaspa. Dans Bitcoin, les utilisateurs se plaignent parfois de payer des frais élevés en cas de congestion (qui reviennent finalement aux mineurs), et les mineurs gèrent la variance et les pertes dues aux orphelins. Dans Kaspa, le débit élevé maintient les frais bas (car la capacité est abondante), et la conception sans orphelin signifie que les mineurs ne perdent pas de récompenses en raison de la latence du réseau. Les mineurs gagnent toujours leur juste récompense - en fait, la récompense de bloc de Kaspa est distribuée sur beaucoup plus de blocs par unité de temps, ce qui, paradoxalement, rend le processus de minage plus granulaire et plus juste (plusieurs mineurs par seconde peuvent gagner des récompenses, plutôt qu'un seul gagnant toutes les 10 minutes). Cela peut réduire la variance du minage et les pressions centralisatrices (car dans Bitcoin, un pool de minage qui trouve un bloc légèrement plus rapidement gagne une récompense de 100 % sur 10 minutes, tandis que dans Kaspa, de nombreux mineurs obtiennent chacun une récompense plus petite chaque seconde - un système "multi-leader" où l'avantage est moyenné). Plus de mineurs peuvent inclure des blocs presque simultanément, ce qui pourrait réduire la tendance monopolistique d'un mineur dominant une tranche de temps donnée. La "compétition accrue au sein de chaque tour de latence" a même des implications pour la réduction du MEV (valeur extractible par le mineur) et de la manipulation - car lorsque les blocs sont parallèles, il est beaucoup plus difficile pour un seul acteur de contrôler l'ordonnancement des transactions. En effet, le parallélisme de Kaspa ajoute un peu de chaos qui favorise l'équité : il devient impossible d'appliquer certaines exploitations qui nécessitent un contrôle strict de l'ordonnancement, réduisant ainsi l'entropie des résultats du marché (les prix du marché et les transactions reflètent la vraie offre et demande, et non l'interférence des mineurs). C'est un autre exemple de la façon dont l'approche de Kaspa tend à préserver la valeur au sein du système - en rendant le comportement du système plus thermodynamiquement irréversible, dans le sens où aucun acteur ne peut facilement rembobiner ou réordonner les transactions pour son profit, les changements d'état du réseau (transactions exécutées) sont authentiques et durables. Il aligne les flux économiques avec une inévitabilité presque physique : une fois que quelque chose se produit dans Kaspa, c'est essentiellement fait et ne peut pas être facilement annulé ou triché.

D'un point de vue macro, si l'on considère la concurrence mondiale des monnaies et des réseaux comme un paysage évolutif, un système comme Kaspa qui offre une faible résistance et une grande intégrité aura tendance à accumuler une "masse monétaire". Au fil du temps, la liquidité engendre la liquidité - les utilisateurs vont là où se trouvent d'autres utilisateurs et commerçants. Si Kaspa continue d'offrir une sécurité de type Bitcoin avec des performances nettement meilleures, il est raisonnable de penser qu'une plus grande activité économique se déplacera sur Kaspa. Nous avons déjà vu historiquement que les monnaies fiduciaires ont remplacé l'or pour les transactions en raison de leur friction moindre, bien que l'or soit une réserve de valeur supérieure ; et maintenant les cryptomonnaies défient la monnaie fiduciaire en combinant la dureté avec la vitesse numérique. Kaspa peut être considéré comme l'étape suivante : combiner la dureté ultime de la monnaie PoW avec la vitesse ultime des réseaux modernes. Dans le langage de la physique, Kaspa pourrait être le "point final gravitationnel" pour l'énergie monétaire - un attracteur massif qui attire le capital parce qu'il représente un état d'énergie potentielle minimale (c'est-à-dire que vous ne pouvez pas facilement trouver un système où votre argent est plus sûr et plus facile à utiliser en même temps). Lorsqu'il n'y a pas de chemin plus facile (état d'énergie plus faible) pour que la valeur s'écoule, vous avez atteint un équilibre, et Kaspa vise à être ce point d'équilibre pour la monnaie décentralisée.

Irréversibilité et la Flèche du Temps dans Kaspa vs. Bitcoin

Un aspect frappant des systèmes de preuve de travail est la façon dont ils établissent une flèche du temps. Chaque bloc est un événement irréversible ; une fois le travail effectué et le bloc accepté, l'annuler nécessiterait de dépenser une quantité d'énergie équivalente (ou supérieure). Cette fonction unidirectionnelle du travail donne aux blockchains une direction temporelle : tout comme l'entropie en physique, il est facile d'avancer (miner de nouveaux blocs, augmenter l'entropie) mais extrêmement difficile de reculer (annuler des blocs, diminuer l'entropie) sans intervention extérieure. La chaîne de blocs de Bitcoin, sécurisée par l'énergie, est souvent comparée à la flèche du temps - une séquence d'historique de plus en plus "établi". Kaspa hérite de cette propriété mais l'accélère. Parce que les blocs arrivent si vite et que GhostDAG approfondit rapidement l'historique du registre, l'irréversibilité des transactions se compose plus rapidement dans Kaspa que dans Bitcoin. La probabilité d'inverser une transaction dans Kaspa diminue exponentiellement à chaque seconde qui passe, car de multiples nouveaux blocs cimentent l'ordre. Dans Bitcoin, six blocs (environ une heure) sont généralement référencés pour une grande confiance ; dans Kaspa, un niveau de sécurité similaire pourrait être atteint en peut-être une douzaine de blocs, ce qui à 1 bloc/sec était d'environ 12 secondes (et à 10 blocs/sec, c'est un peu plus d'une seconde, bien que d'autres facteurs de latence entrent en jeu).

Cela signifie que la finalité du registre de Kaspa approche quelque chose de très proche de l'irréversibilité en temps réel. Le comportement du système reflète un processus thermodynamique irréversible qui atteint très rapidement un point de non-retour. Par exemple, si deux transactions conflictuelles (tentatives de double dépense) sont émises, l'inclusion et l'ordonnancement rapides des blocs de Kaspa décideront du gagnant et empileront les confirmations dessus en quelques secondes, rendant la tentative d'inversion du perdant de plus en plus futile. Dans Bitcoin, cette période d'incertitude (entropie) pourrait durer de nombreuses minutes et même alors peut être exploitée par un attaquant avec suffisamment de puissance de hachage dans un état de faible entropie (avant que de nombreuses confirmations ne s'accumulent). Kaspa réduit cette fenêtre, rendant le coût d'inversion de l'historique extrêmement élevé presque immédiatement. Nous pouvons considérer cela comme Kaspa augmentant le gradient thermodynamique qu'un attaquant doit gravir - une colline plus raide qui devient plus raide plus rapidement. Cela est à nouveau lié à l'efficacité : le réseau ne perd pas de temps à transformer la puissance de hachage en sécurité (ordre), de sorte qu'un attaquant n'a pas le "luxe" d'une longue fenêtre de vulnérabilité à exploiter. L'entropie de l'incertitude est rapidement expulsée du système, laissant un état très ordonné (transactions confirmées) qui est stable.

Une autre perspective est celle du principe de Landauer, un concept de la physique qui stipule que l'effacement d'un bit d'information a un coût énergétique irréductible (dissipation de chaleur). Dans les blockchains, "effacer" une transaction (via une réorganisation qui supprime une transaction confirmée de l'historique) est extrêmement coûteux en énergie - c'est pourquoi les grandes réorganisations sont infaisables si les mineurs honnêtes contrôlent la majorité de la puissance de hachage. Kaspa garantit que les bits de données de transaction sont incorporés dans de nombreux blocs (bits d'information) presque immédiatement, de sorte que l'information s'enracine et devient thermodynamiquement coûteuse à effacer. Essentiellement, Kaspa aligne la théorie de l'information avec la thermodynamique : l'information (l'état du registre) acquiert une permanence résistante à l'entropie rapidement, ancrée par la preuve de travail. Et parce que Kaspa utilise son énergie d'entrée plus efficacement (pas de blocs gaspillés, plus de confirmations par unité de temps), elle atteint sans doute une "irréversibilité par unité d'énergie" plus élevée que Bitcoin. Chaque joule de minage dans Kaspa contribue à la finalité de nombreuses transactions, tandis que dans Bitcoin, chaque joule sécurise moins de transactions (et certains joules sont dépensés sur des blocs qui pourraient même ne pas compter).

La métaphore de la flèche du temps est appropriée : la flèche de Bitcoin avance lentement mais inexorablement, prenant plus de temps pour établir fermement l'histoire, tandis que la flèche de Kaspa vole à grande vitesse, fixant rapidement les événements dans le temps. Les deux flèches pointent dans la même direction - imposée par la deuxième loi de la thermodynamique (consommation d'énergie) - mais celle de Kaspa couvre plus de distance (profondeur du registre) par unité de temps. Cela n'a pas seulement des avantages pratiques (expérience utilisateur, débit), mais cela indique philosophiquement que la conception de Kaspa est en harmonie avec la direction "naturelle" des systèmes complexes : vers plus d'ordre atteint en moins de temps en dépensant de l'énergie. Si Bitcoin a montré que énergie + temps = sécurité, Kaspa montre qu'avec une meilleure conception, vous pouvez obtenir une sécurité équivalente avec la même énergie en beaucoup moins de temps, simplement en éliminant les inefficacités internes. Il ne viole aucune loi fondamentale ; il ne fait que ne pas gaspiller les opportunités que Bitcoin laisse sur la table.

Conclusion : Kaspa comme Frontière Efficace des Réseaux Monétaires

En examinant Kaspa à travers les doubles lentilles de la physique et de l'économie, nous voyons un thème émerger : les systèmes évoluent vers une efficacité optimale dans le traitement de l'énergie et de l'information. En économie, l'argent a évolué des marchandises encombrantes à l'or, au papier adossé à l'or, aux réseaux numériques - chaque étape visant à réduire la friction tout en préservant la confiance et la valeur. En informatique et en réseau, nous sommes passés du traitement série au parallèle, des retards analogiques aux signaux quasi-lumineux. Kaspa représente la convergence de ces chemins évolutifs dans le domaine de la monnaie décentralisée. Il prend la dureté et la finalité de la preuve de travail soutenue par l'énergie - l'aspect qui fait de Bitcoin une forme d'"or numérique" - et suralimente l'efficacité du système qui utilise cette énergie. Le résultat est un réseau que l'on peut décrire comme un moteur de valeur : il convertit l'énergie électrique (travail de hachage) en valeur économique numérique (transactions sécurisées et émission de pièces) avec un minimum de gaspillage, canalisant cette valeur rapidement là où elle doit aller.

En positionnant Kaspa par rapport à Bitcoin, il ne s'agit pas de rivalité mais de progrès dans l'architecture décentralisée. Bitcoin a été le prototype qui a prouvé qu'une approche thermodynamique de l'argent fonctionnait. Kaspa est une évolution qui affine l'architecture pour minimiser le gaspillage (entropie) et maximiser le débit (travail utile) sans perdre l'essence de ce qui a fait la grandeur de Bitcoin (décentralisation et sécurité via la preuve de travail). Nous n'avons comparé Kaspa qu'à Bitcoin car les deux partagent le fondement fondamental de la PoW et une politique monétaire saine, différant principalement par la conception structurelle. Et cette différence - un blockDAG vs une blockchain - a fait toute la différence. Le blockDAG de Kaspa est une solution naturelle aux goulots d'étranglement de Bitcoin, presque évidente rétrospectivement : si une voie est trop lente, ajoutez plus de voies ; si l'abandon des blocs gaspille de l'énergie, trouvez un moyen de les conserver tous ; si l'attente d'une synchronisation globale entraîne de la latence, autorisez une certaine asynchronie et résolvez-la ensuite algorithmiquement. Ce sont, en un sens, des optimisations de bon sens une fois que la technologie a permis de les mettre en œuvre. La brillante idée de GhostDAG a été de trouver un moyen de faire travailler de nombreux leaders (mineurs) ensemble à la fois sans chaos - comme une symphonie bien orchestrée plutôt qu'une performance solo. Cela montre que l'ordre peut émerger d'un chaos apparent avec les bonnes règles, faisant écho à la façon dont les systèmes physiques s'auto-organisent lorsque des contraintes sont sagement appliquées.

Le résultat final des choix de conception de Kaspa est un système qui, selon certains, constitue un aboutissement naturel dans le calcul monétaire à valeur efficace. Il est aussi rapide que la physique le permet, aussi sécurisé que la preuve de travail peut l'être, et aussi décentralisé qu'un réseau globalement inclusif devrait l'être. Pourrions-nous aller plus vite ou être plus efficaces sans rompre le lien fondamental entre l'argent et la thermodynamique ? Probablement pas beaucoup - pas sans une nouvelle physique ou sans compromettre la confiance. Kaspa vise déjà 100 blocs par seconde à l'avenir, approchant un flux de blocs presque continu, et ses développeurs intègrent des fonctionnalités adaptatives (comme DAGKnight) qui ajustent la vitesse de confirmation aux conditions. Nous approchons des limites pratiques de la mise à l'échelle on-chain dans un contexte décentralisé. Tout gain significatif supplémentaire nécessiterait probablement des approches fondamentalement différentes (ou l'acceptation de la centralisation). En ce sens, Kaspa est la frontière efficace - vous ne pouvez pas obtenir un débit significativement plus élevé ou une latence plus faible à l'échelle sans encourir plus de gaspillage ou de risque que Kaspa. Il a trouvé un équilibre qui utilise les ressources de manière optimale.

Pour les professionnels et les chercheurs avertis en crypto, Kaspa offre une étude de cas fascinante où les principes de la thermodynamique, de la théorie de l'information et de l'économie convergent. Il valide l'idée qu'un réseau financier décentralisé peut être analysé de la même manière qu'un système physique - avec des entrées d'énergie, des sorties de travail et des inefficacités comme entropie. En réduisant ces inefficacités, Kaspa ne se contente pas de mieux fonctionner ; il crée fondamentalement un système économique plus durable et plus attractif. Un système avec moins de gaspillage signifie que le travail des mineurs va plus loin, les frais des utilisateurs restent plus bas, et plus de valeur circule plutôt que d'être brûlée en frais généraux. Au fil du temps, cela attire plus de participation, plus d'investissements et renforce les effets de réseau. C'est analogue à la façon dont un moteur efficace non seulement économise du carburant, mais permet de nouvelles capacités - des trajets plus longs, des charges plus lourdes - de sorte qu'une blockchain efficace permet plus d'activité économique et de cas d'utilisation qui étoufferaient une chaîne plus lente.

En conclusion, Kaspa peut être considéré comme l'aboutissement de plus d'une décennie de recherche sur la mise à l'échelle de l'invention de Nakamoto sans en perdre l'âme. Il montre que les lois de la physique et une économie saine ne sont pas des ennemis de la décentralisation, mais des guides pour l'améliorer. Le succès de Kaspa signifierait que le système monétaire qui suit le plus fidèlement le chemin de la moindre résistance et de la moindre production d'entropie prévaudra - un résultat très aligné sur la physique. En termes pratiques, Kaspa représente un réseau à haut débit, à faible friction et sécurisé qui pourrait transporter la valeur des nations dans un seul protocole, accessible à tous, et limité uniquement par la vitesse de la lumière et l'honnêteté de la majorité. Si Bitcoin a ouvert la porte à une ère financière thermodynamique, Kaspa y accélère, rendant le flux d'énergie économique aussi efficace que le flux d'électrons. Dans le grand récit de la technologie et de l'argent, Kaspa se distingue comme une preuve convaincante que l'efficacité est le destin : étant donné deux systèmes, celui qui minimise le mieux le gaspillage et maximise le travail utile attirera l'avenir. Et Kaspa présente un argument persuasif et techniquement fondé selon lequel il est ce système - un saut évolutif vers un réseau monétaire sans friction, préservant la valeur et finalement plus aligné sur l'humain.

---

Chapitre 13 : Ordonnancement Kaspa vs Bitcoin

Sélection et Ordonnancement des Blocs : Chaîne la Plus Lourde vs Blue Work

Règle de la Chaîne la Plus Lourde de Bitcoin - Sélection Séquentielle

Le mécanisme de consensus de Bitcoin fonctionne sur un principe linéaire où le réseau maintient une seule chaîne de blocs. Lorsque les mineurs créent de nouveaux blocs simultanément, le réseau est confronté à un choix entre des chaînes concurrentes. La règle de la chaîne la plus lourde résout ce problème en sélectionnant la chaîne avec la preuve de travail accumulée la plus importante, choisissant ainsi le chemin qui représente le plus grand investissement computationnel. Cette approche crée un scénario où le gagnant prend tout, où une seule chaîne survit tandis que tous les blocs concurrents deviennent orphelins. Les blocs orphelins, bien que contenant des transactions valides et représentant un travail de calcul réel, ne contribuent en rien à la sécurité du réseau ou à la capacité de traitement des transactions. Cette conception assure un ordonnancement clair mais limite intrinsèquement le débit car un seul bloc peut être accepté à chaque niveau de hauteur. Dans cet exemple, vous pouvez voir comment les blocs sont écartés par Bitcoin.

Sélection du Blue Work de Kaspa - Intégration Parallèle

Le protocole GHOSTDAG de Kaspa étend cette approche en opérant au sein d'une structure de Graphe Acyclique Dirigé (DAG) où plusieurs blocs peuvent coexister et contribuer à la sécurité du réseau. Au lieu d'écarter les blocs concurrents, GHOSTDAG les classe comme "bleus" (honnêtes, contribuant au consensus) ou "rouges" (potentiellement conflictuels mais toujours maintenus). La métrique "blue work" représente la preuve de travail accumulée uniquement à partir des blocs bleus dans le DAG. Cette accumulation sélective garantit que seuls les blocs valides par consensus contribuent au calcul de la sécurité, tout en préservant le travail et les transactions des blocs rouges au sein de la structure globale. Dans cet exemple, vous pouvez voir que le bloc qui a été écarté par Bitcoin est inclus dans le DAG de Kaspa, même lorsque k = 0.

Sélection des Parents et Formation de la Chaîne Principale

Lorsqu'un nouveau bloc entre dans le DAG, GHOSTDAG doit sélectionner un "Parent Sélectionné" parmi plusieurs candidats parents possibles. Ce processus de sélection examine la valeur de "blue work" de chaque parent potentiel et choisit celui qui a la valeur de "blue work" accumulée la plus élevée à partir des blocs honnêtes. Voici le bloc B, sélectionnant le meilleur parent (le parent avec le plus de travail) parmi ses parents.

Ce parent sélectionné devient la base de l'établissement d'une chaîne principale au sein du DAG. La chaîne principale fournit un mécanisme d'ordonnancement déterministe similaire à la chaîne linéaire de Bitcoin, mais opère dans l'environnement DAG plus complexe. Après avoir sélectionné le parent principal, le protocole traite tous les blocs restants dans ce qu'on appelle le "Mergeset" - les blocs qui sont inclus dans le DAG mais n'ont pas été choisis comme Parent Sélectionné. Après avoir sélectionné un parent, nous pouvons suivre les Parents Sélectionnés à travers le DAG, cela crée une chaîne que vous pouvez voir dans l'image ici.

Ordonnancement et Traitement des Transactions

La chaîne principale créée par la sélection du "blue work" sert de mécanisme d'ordonnancement principal pour le traitement des transactions. Les transactions sont traitées d'abord à partir du Parent Sélectionné, puis à partir des blocs du Mergeset dans un ordre convenu par consensus. Cela crée une séquence déterministe que tous les nœuds peuvent reproduire, garantissant un ordonnancement cohérent des transactions sur le réseau.

Différences Architecturales Fondamentales

Approche de Bitcoin : Crée une séquence linéaire unique où chaque bloc a exactement un parent. Les conflits entraînent l'exclusion permanente des blocs concurrents, seule la chaîne gagnante contribuant à la sécurité du réseau.

Approche de Kaspa : Maintient une structure DAG où les blocs peuvent avoir plusieurs parents et enfants. Les conflits sont résolus par classification plutôt que par exclusion, permettant à plusieurs blocs de contribuer à la sécurité du réseau tout en maintenant le consensus via la chaîne principale.

Implications sur le Débit et la Sécurité

L'approche linéaire de Bitcoin offre de solides garanties de sécurité mais limite le débit à environ un bloc toutes les 10 minutes. L'orphaning des blocs concurrents représente un gaspillage de ressources de calcul et une perte de capacité de transaction.

Le système de "blue work" de Kaspa permet un débit beaucoup plus élevé tout en maintenant les propriétés de sécurité. En préservant à la fois les blocs bleus et rouges dans le DAG, le système capture une plus grande partie du travail de calcul et de la capacité de traitement des transactions du réseau. La chaîne principale assure un ordonnancement déterministe malgré la complexité accrue, permettant la création de blocs parallèles sans sacrifier la fiabilité du consensus.

Le retour en arrière de Bitcoin en 2013 : Une leçon de finalité

En mars 2013, le réseau Bitcoin a connu un événement critique qui a contredit son principe fondamental selon lequel "la chaîne la plus longue est la chaîne valide".

1. Une division de la chaîne : Un mineur utilisant la version 0.8 de Bitcoin Core a produit un bloc incompatible avec les anciennes versions (0.7). Cela a provoqué une division de la chaîne (fork).
2. La coordination sociale a primé sur le protocole : Bien que la chaîne 0.8 soit devenue plus longue, les développeurs principaux et les grands pools de minage se sont socialement coordonnés pour abandonner cette chaîne et revenir à la chaîne 0.7, plus courte mais compatible.
3. La finalité a été rompue : 24 blocs de la chaîne 0.8 ont été orphelins. Les transactions qu'ils contenaient, autrefois considérées comme valides, ont été effacées de l'histoire canonique de Bitcoin.

Cet événement a prouvé que le consensus de Bitcoin n'est pas purement déterministe et peut nécessiter une intervention humaine. Dans Kaspa, de telles divisions sont impossibles. Tous les blocs, même s'ils sont minés simultanément, sont inclus dans le DAG, et GHOSTDAG sélectionne un historique ordonné de manière cohérente et algorithmique. Il n'y a pas besoin de retour en arrière ou de coordination sociale ; la finalité est déterministe.

---

Chapitre 14 : La Vision de Kaspa pour la Couche 2 : ZK Rollups et Pontage

Le besoin de solutions de couche 2

Bien que Kaspa offre une scalabilité impressionnante au niveau de sa couche de base (Layer 1), l'avenir des applications décentralisées complexes (DeFi, jeux, etc.) repose sur des solutions de couche 2 (Layer 2). Celles-ci permettent d'exécuter des calculs complexes hors de la chaîne principale, tout en bénéficiant de sa sécurité. Kaspa se concentre sur les "Based ZK-Rollups", où la couche 1 (Kaspa) sert de couche de séquençage, de disponibilité des données et de règlement.

Le défi : Preuve au moment de l'inclusion vs. Incertitude d'exécution

Les L1 parallélisées comme Kaspa introduisent une "incertitude d'exécution" : les transactions sont incluses dans le DAG avant que leur ordre global final ne soit déterminé. C'est un avantage pour la résistance au MEV, car cela empêche les mineurs de prédire la séquence exacte.

Cependant, cela crée un conflit avec les ZK-Rollups, qui, idéalement, nécessiteraient une "preuve au moment de l'inclusion". Pour générer une preuve ZK, l'état précédent (pre-state) doit être connu et sans ambiguïté. Mais dans Kaspa, cet état est indéfini au moment de l'inclusion en raison du traitement parallèle.

La solution de Kaspa est d'opter pour le consensus multi-leaders et son incertitude d'exécution. Par conséquent, les preuves ZK doivent être différées et soumises à la L1 seulement après que l'ordre des transactions a convergé et qu'un état clair est établi. Cela introduit un nouveau défi : que se passe-t-il si la preuve requise n'arrive jamais ?

Règlement des preuves à durée limitée (Timebound Proof Settlement)

Le modèle proposé est le "règlement des preuves à durée limitée".

1. Les données de la transaction sont d'abord publiées sur la L1 (disponibilité des données).
2. Le règlement final de ses effets sur la L1 dépend de la soumission et de la vérification d'une preuve ZK dans une fenêtre de temps définie (T).
3. Si une partie impliquée dans une opération ne fournit pas sa preuve dans ce délai, l'opération échoue, avec des pénalités pour garantir la responsabilité.

Ce modèle permet des confirmations optimistes rapides du côté de l'utilisateur, bien avant le règlement final sur la L1, car chaque rollup a un intérêt direct à soumettre sa preuve pour maintenir sa propre "vivacité".

KIP-15 et les Nœuds d'Archivage des Transactions Acceptées (ATANs)

Un problème fondamental pour les L2 sur Kaspa est l'élagage. Comment une L2 peut-elle se référer à des données de transaction qui ont été élaguées de la L1 ? Les preuves ZK sont la solution à long terme, mais une solution intermédiaire est nécessaire.

C'est le but de KIP-15 : introduire les Nœuds d'Archivage des Transactions Acceptées (ATANs). Un ATAN se situe entre un nœud complet élagué et un nœud d'archivage complet.

• Il ne stocke pas les données complètes des transactions.
• Il stocke les en-têtes de la chaîne sélectionnée et les hachages de toutes les transactions.

Le hachage d'une transaction ne fait que 32 octets, ce qui représente une compression massive par rapport à la transaction elle-même. Un ATAN peut stocker des années d'historique de hachages de transactions avec des besoins en stockage raisonnables (estimés à environ 3-5 To par an à pleine capacité). Cela permet à une L2 de prouver l'existence et l'ordre de n'importe quelle transaction passée sans avoir besoin d'un nœud d'archivage complet, résolvant ainsi le problème de la disponibilité des données dans un environnement élagué.

Conception du Pont Canonique L1<>L2

Pour permettre aux fonds (KAS) de circuler entre la L1 et la L2, un "pont canonique" est nécessaire.

• Entrée (L1 vers L2) : Un utilisateur envoie des KAS à une adresse de délégation statique sur la L1. Cette opération est validée immédiatement par la L1, et les fonds sont utilisables quasi instantanément sur la L2.
• Sortie (L2 vers L1) : Une sortie nécessite une autorisation interne à la L2. Sa validité doit être confirmée sur la L1 par la soumission d'une preuve ZK.

Pour ce faire, Kaspa utilise des scripts de "délégation". Au lieu d'envoyer des fonds à l'adresse de l'état du rollup (qui est dynamique), les utilisateurs envoient à des adresses statiques qui délèguent leur autorisation de dépense à la preuve ZK fournie par le rollup. Cela simplifie l'expérience utilisateur et la gestion des fonds du pont.

---

Chapitre 15 : Le Réseau Igra : Un Cas d'Étude du Rollup ZK Compatible EVM de Kaspa

Présentation d'Igra

Igra Network est un excellent exemple pratique de la vision de Kaspa pour la couche 2. Il s'agit d'un rollup ZK compatible EVM qui utilise de manière unique le BlockDAG de Kaspa comme séquenceur décentralisé et couche de règlement.

Cette architecture vise à combiner la sécurité de type Bitcoin avec la vitesse et la polyvalence des chaînes programmables modernes, en résolvant les limitations critiques des solutions de couche 2 actuelles.

Composants Clés

• Couche de base (Kaspa) : Sert de séquenceur décentralisé. L'ordre des transactions d'Igra est fixé sur le BlockDAG de Kaspa par ses nœuds de minage.
• Nœud Igra : Maintient l'état complet de la L2 et exécute les transactions EVM. Il extrait les transactions séquencées de la L1 et les exécute.
• Relais Igra / RPC : Fournit le pont entre les utilisateurs et le réseau. Il expose des interfaces RPC Ethereum standard, permettant aux utilisateurs d'interagir avec Igra en utilisant des portefeuilles comme MetaMask.

Mécanisme de Pontage et Déploiement

Igra utilise une approche de pontage en plusieurs phases pour son token natif, $iKAS, qui est une version enveloppée du KAS.

1. Phase 1 (Pont Communautaire) : Initialement, le pontage repose sur un portefeuille multisig (m-sur-n) contrôlé par des signataires choisis par la communauté. C'est un modèle de confiance similaire à celui utilisé pour les fonds communautaires de nombreuses cryptomonnaies. Pour retirer des fonds, les signataires sont tenus de traiter les demandes, avec des garanties pour assurer une transition vers un système sans confiance.
2. Phase 2 (Pont MPC/ZK) : À l'avenir, ce pont sera remplacé par une solution sans confiance.
   • Pont MPC (Multi-Party Computation) : Utilise des techniques cryptographiques comme FROST pour permettre à un ensemble de validateurs de signer des transactions sans qu'aucun d'entre eux ne détienne la clé secrète complète. Cela permet un pontage permissionless.
   • Pont ZK : La solution ultime. Un utilisateur peut soumettre une preuve ZK à la L1 prouvant qu'il a brûlé des $iKAS sur la L2. Un script sur la L1 vérifiera cette preuve et débloquera le montant correspondant de KAS.

Le Testnet Caravel

Le déploiement d'Igra se fait par étapes, en commençant par le testnet "Caravel". Ce lancement se déroule en plusieurs phases :

1. Activation : Le réseau est activé sur le testnet de Kaspa.
2. Testeurs Communautaires : Le logiciel de nœud est distribué à un groupe limité de testeurs pour augmenter progressivement l'activité du réseau.
3. Accès Public : Le logiciel est rendu public, permettant à quiconque de faire tourner un nœud et de participer.

Ce processus de déploiement prudent est essentiel, car Caravel apporte le protocole Ethereum complet au consensus de Kaspa, qui fonctionne à des vitesses encore inexplorées dans le monde EVM. Des tests intensifs et plusieurs itérations sont nécessaires pour assurer la stabilité et la performance.

---

Chapitre 16 : Débit des Transactions et Collisions dans le BlockDAG de Kaspa

Le Défi des Collisions de Transactions

Ce qui rend les DAG incroyablement rapides, c'est la capacité de paralléliser : puisque les blocs créés en parallèle sont tous considérés comme valides, l'augmentation des taux de blocs parallèles ne nuit pas à la sécurité. Cependant, une question se pose : si nous créons 10 blocs par seconde, notre débit de transactions est-il vraiment 10 fois supérieur ?

Pas tout à fait. La nuance est que les blocs parallèles peuvent contenir la même transaction, et il n'est pas juste de compter la même transaction plusieurs fois. Nous devrions nous intéresser au TPS effectif, c'est-à-dire au nombre de transactions uniques incluses en moyenne.

Analyse de la Sélection Aléatoire

En supposant que les mineurs choisissent les transactions à inclure de manière aléatoire (ce qui est une approximation raisonnable, comme nous le verrons), nous pouvons analyser le TPS effectif.

L'analyse mathématique montre que même dans le pire des cas (où la capacité des blocs correspond exactement au nombre de transactions disponibles dans le mempool), le réseau inclut au moins (1 - 1/e) ≈ 62,3% de transactions uniques. C'est un plancher ; en pratique, lorsque le mempool est plus grand que la capacité des blocs, l'efficacité tend vers 100%.

Le résultat est que le TPS effectif augmente de manière quasi-linéaire avec le taux de blocs. Une augmentation de 10x du taux de blocs se traduit par une augmentation de 8-9x du TPS effectif, ce qui est une amélioration considérable.

Qu'en est-il des Mineurs Malhonnêtes ?

On pourrait craindre que des mineurs "cupides" essaient de manipuler la sélection des transactions pour maximiser leurs profits, par exemple en choisissant tous les mêmes transactions à frais élevés, ce qui augmenterait les collisions et réduirait le TPS effectif.

La théorie des jeux nous montre que ce n'est pas une stratégie optimale. La sélection aléatoire est un "équilibre faible". Cela signifie que si un seul mineur s'écarte de cette stratégie, il peut obtenir un léger avantage. Cependant, si de nombreux mineurs s'écartent et choisissent tous les mêmes transactions à frais élevés, ils se retrouvent en concurrence directe pour les mêmes frais, et leur profit attendu diminue. À la fin, la stratégie la plus rationnelle pour un mineur (qui ne peut pas prédire ce que feront les autres) est de diversifier ses choix, ce qui se rapproche d'une sélection aléatoire.

Solutions Potentielles pour les Collisions Élevées

Si, en pratique, on observait un taux de collision élevé, plusieurs solutions pourraient être mises en œuvre :

1. Compartimentage des transactions (Bucketing) : On pourrait exiger que les blocs n'incluent que des transactions dont le hachage correspond à certains chiffres du hachage du bloc lui-même. Cela diviserait les transactions en "seaux", et les blocs ne seraient en concurrence que pour les transactions du même seau.
2. Mécanisme d'enchères monopolistique : Un mécanisme où les mineurs peuvent inclure les transactions qu'ils veulent, mais les frais pour toutes les transactions du bloc sont fixés au niveau des frais les plus bas parmi les transactions incluses. Cela incite les mineurs à inclure plus de transactions (pour augmenter le volume) plutôt que de se concentrer uniquement sur celles qui paient le plus, ce qui encourage naturellement la diversification.

En conclusion, bien que les collisions de transactions soient une considération dans les BlockDAGs, l'architecture de Kaspa et la dynamique de la théorie des jeux garantissent que le débit effectif reste élevé et évolue de manière robuste avec le taux de blocs.

---

Chapitre 17 : Le Marché des Frais de Kaspa : Une Perspective Théorique des Jeux

L'Importance du Marché des Frais

Le marché des frais d'une cryptomonnaie est extrêmement important pour sa sécurité à long terme. Une fois que les récompenses de bloc deviennent négligeables, les frais de transaction restent la principale subvention pour la sécurité du réseau. Il est donc crucial de comprendre la dynamique du marché des frais qu'un protocole induit.

Les Trois Maux du Marché des Frais de Bitcoin

Le marché des frais de Bitcoin, en raison de son consensus "un seul leader par tour", présente des propriétés que l'on peut qualifier de "trois maux" :

1. Course vers le bas (Race-to-the-bottom) : Lorsque le réseau n'est pas congestionné, la demande est inférieure à l'offre d'espace de bloc. Les utilisateurs n'ont aucune incitation à payer des frais élevés, car leurs transactions seront incluses de toute façon. Les frais tendent vers le minimum, ce qui peut rendre le minage non rentable et menacer la sécurité du réseau.
2. Aberration des prix : Lorsque le réseau est congestionné, une très petite augmentation des frais peut faire passer une transaction de "jamais incluse" à "incluse dans le prochain bloc". Le prix ne reflète pas un service graduel.
3. Famine (Starvation) : Dans un réseau congestionné, les transactions à faibles frais peuvent être perpétuellement exclues, car elles ne pourront jamais surenchérir sur les transactions à frais élevés. Cela crée une barrière à l'entrée et soulève des questions sur l'éthos égalitaire de la blockchain.

Ces dynamiques sont une conséquence directe du fait qu'un seul mineur remporte tout le pot à chaque tour.

Comment le BlockDAG Multi-Leaders de Kaspa Améliore le Marché des Frais

Dans Kaspa, plusieurs mineurs créent des blocs en parallèle à chaque tour (multi-leaders). Si plusieurs mineurs incluent la même transaction, ils se partagent la récompense de manière probabiliste. Cela change radicalement la dynamique du jeu pour les mineurs et les utilisateurs.

• Contre la course vers le bas : Parce que les mineurs sont en concurrence, il devient rationnel pour eux d'inclure des transactions même si le réseau n'est que partiellement utilisé, afin de diversifier leurs sources de revenus et d'éviter la concurrence directe. L'analyse montre que le marché des frais s'active dès que le réseau atteint 1/k de sa capacité (où k est le nombre de leaders par tour), au lieu de 100% pour Bitcoin. Avec 10 leaders par tour, le marché s'active dès que 10% de la capacité est utilisée.
• Contre la famine et l'aberration : Les mineurs ont une incitation à inclure un mélange de transactions, y compris celles à frais plus faibles. Il n'est pas toujours optimal de se battre pour les quelques transactions les plus rémunératrices, car la probabilité de gagner ces frais est réduite par la concurrence. Cela crée une courbe de service beaucoup plus douce : une légère augmentation des frais entraîne une légère augmentation de la probabilité d'inclusion, plutôt qu'un changement brutal. Les transactions à faibles frais ont toujours une chance (même si elle est faible) d'être incluses, ce qui évite la famine. Une faible probabilité d'inclusion dans un tour se traduit par un temps d'attente moyen raisonnable, plutôt qu'une attente infinie.

En conclusion, l'architecture multi-leaders de Kaspa, une conséquence directe de son BlockDAG à haute fréquence, crée un marché des frais intrinsèquement plus sain, plus stable et plus équitable. En lissant les dynamiques extrêmes de "tout ou rien" des blockchains à leader unique, Kaspa construit une base économique plus robuste pour sa sécurité à long terme.

---

Conclusion

---

Annexe A : Ressources Supplémentaires

Pour ceux qui souhaitent approfondir leur compréhension de Kaspa, voici une liste de ressources essentielles, allant des articles d'introduction aux documents de recherche fondamentaux.

Articles de Démarrage

• Kaspa 101: Un excellent point de départ pour comprendre le fonctionnement de GHOSTDAG. Lire ici
• Scaling Bitcoin with BlockDAG: Explique pourquoi le BlockDAG est une solution viable aux limitations de Bitcoin. Lire ici
• Kaspa Pruning Primer: Une introduction au mécanisme d'élagage de Kaspa. Lire ici
• Kaspa GhostDAG 101 (Vidéo): Une couverture vidéo complète des concepts techniques. Regarder ici

Documents de Recherche (Plongée en Profondeur)

• PHANTOM et GHOSTDAG: Le document académique qui a jeté les bases du consensus de Kaspa. Lire le PDF
• The DAGKnight Protocol: Le protocole de consensus de nouvelle génération de Kaspa, conçu pour une finalité rapide et une résistance aux attaques. Lire le PDF
• Prunality: Le document détaillant la théorie derrière le mécanisme d'élagage de Kaspa. Lire le PDF
• Bitcoin Whitepaper: Le document original de Satoshi Nakamoto, pour un contexte historique. Lire le PDF

Code et Développement

• Rusty-Kaspa (Dépôt Principal): Le code source du nœud Kaspa, écrit en Rust. Voir sur GitHub
• Kaspa Improvement Proposals (KIPs): Le dépôt contenant toutes les propositions d'amélioration de Kaspa. Voir sur GitHub

Communauté et Discussion

• Discord: Le lieu principal pour les discussions techniques et communautaires. Canaux recommandés : #research-general, #development. Rejoindre le Discord
• Telegram (R&D): Un groupe où les développeurs et chercheurs collaborent. Rejoindre sur Telegram
• Forum de Recherche: Pour les discussions approfondies sur les KIPs et les nouveaux concepts techniques. Visiter le forum

---

Annexe B : Analyse Mathématique des Collisions de Transactions (Simplifiée)

Ce chapitre explore la question du TPS (transactions par seconde) effectif dans un BlockDAG. Lorsque plusieurs blocs sont créés en parallèle, ils peuvent contenir les mêmes transactions, ce qui réduit le débit unique. L'analyse montre que même avec une sélection aléatoire des transactions par les mineurs, le débit effectif reste élevé.

L'idée clé est que la probabilité que deux mineurs choisissent la même transaction diminue à mesure que le pool de transactions en attente (mempool) augmente. L'analyse mathématique (utilisant la théorie des probabilités et les séries de Taylor) montre que même dans un scénario où la capacité des blocs correspond exactement au nombre de transactions disponibles, le réseau inclut au moins (1 - 1/e) ≈ 62,3% de transactions uniques. Ce chiffre représente un minimum ; en pratique, l'efficacité est souvent bien plus élevée.

De plus, la théorie des jeux suggère que les mineurs n'ont pas d'incitation significative à s'écarter de cette sélection quasi-aléatoire. Si tous les mineurs essaient de choisir les transactions les plus rémunératrices, ils finissent par se faire concurrence pour les mêmes frais, ce qui diminue leur profit attendu. Une stratégie de diversification (sélection aléatoire) est donc un équilibre stable (un "équilibre faible").

En résumé, le parallélisme de Kaspa ne nuit pas significativement au débit effectif, qui augmente de manière quasi-linéaire avec le taux de blocs.

---

Annexe C : Analyse Mathématique du Marché des Frais (Simplifiée)

Ce chapitre analyse la dynamique du marché des frais en utilisant la théorie des jeux, comparant le modèle "un seul leader" de Bitcoin au modèle "multi-leaders" de Kaspa.

Les Trois Maux du Marché des Frais de Bitcoin :

1. Course vers le bas (Race-to-the-bottom): Lorsque le réseau n'est pas congestionné, les utilisateurs n'ont aucune incitation à payer des frais élevés, car leurs transactions seront incluses de toute façon. Les frais tendent vers le minimum, ce qui menace la sécurité à long terme du réseau.
2. Aberration des prix: Lorsque le réseau est congestionné, une très petite augmentation des frais peut faire passer une transaction de "jamais incluse" à "incluse dans le prochain bloc". Le prix ne reflète pas un service graduel.
3. Famine (Starvation): Dans un réseau congestionné, les transactions à faibles frais peuvent être perpétuellement exclues, créant une barrière à l'entrée pour les utilisateurs moins fortunés.

Comment le BlockDAG de Kaspa résout ces problèmes :

Dans Kaspa, plusieurs mineurs créent des blocs en parallèle (multi-leaders). Si plusieurs mineurs incluent la même transaction, ils se partagent la récompense (de manière probabiliste). Cela change radicalement la dynamique :

• Contre la course vers le bas: Parce que les mineurs se font concurrence, il devient rationnel d'inclure des transactions même si le réseau n'est que partiellement utilisé. L'analyse montre que le marché des frais s'active dès que le réseau atteint 1/k de sa capacité (où k est le nombre de leaders par tour), au lieu de 100% pour Bitcoin. Avec 10 leaders par tour, le marché s'active dès que 10% de la capacité est utilisée.
• Contre la famine et l'aberration: Les mineurs ont une incitation à inclure un mélange de transactions, y compris celles à frais plus faibles. Il n'est pas toujours optimal de se battre pour les quelques transactions les plus rémunératrices, car la probabilité de gagner ces frais est réduite par la concurrence. Cela crée une courbe de service plus douce : une légère augmentation des frais entraîne une légère augmentation de la probabilité d'inclusion, plutôt qu'un changement brutal. Les transactions à faibles frais ont toujours une chance d'être incluses, ce qui évite la famine.

En conclusion, l'architecture multi-leaders de Kaspa crée un marché des frais plus sain, plus stable et plus équitable, ce qui est essentiel pour la sécurité et la viabilité à long terme du protocole.