Blockchain/Niveau VIII · L’ère des memecoins/8.1 L'histoire de Solana/Leçon 1
Origines : preuve de l’histoire
L’horloge vérifiable et le matériel qui la finance
MatérielUn explorateur de blocs Solana (par exemple, Solscan ou Solana Explorer)Le livre blanc de Solana d’Anatoly Yakovenko (2017)Documentation Solana sur Turbine, Gulf Stream et Sealevel
Curiosité
- Comment les nœuds distribués peuvent-ils s’accorder sur l’ordre des événements sans une synchronisation constante ?
- Pourquoi un planning de leader déterministe permet-il l’exécution parallèle des transactions ?
- Quel est le rapport entre les temps d’exécution des blocs de quelques millisecondes et les exigences en matière de matériel pour les validateurs ?
Explorer
- Anatoly Yakovenko a publié le livre blanc de Solana en novembre 2017, présentant la preuve d’histoire (Proof of History ou PoH). La PoH génère une séquence de hachages SHA-256, chacun étant dérivé du précédent. Ce travail cryptographique fonctionne comme une horloge vérifiable. Les validateurs l’utilisent pour établir un ordre temporel sans avoir à communiquer entre eux pour chaque transaction. Ce mécanisme réduit la charge de communication par rapport aux protocoles de consensus qui dépendent du temps de latence aller-retour pour une synchronisation globale.
- Solana combine le PoH avec un système de vote par preuve d’engagement via Tower BFT. La version bêta du réseau principal a été lancée le 16 mars 2020. Les blocs sont générés à intervalles d’environ 400 millisecondes par un leader désigné à l’avance. Ce calendrier déterministe permet aux validateurs de savoir exactement quand ils devront générer un bloc. Les transactions peuvent être transmises à l’avance aux leaders suivants, en contournant ainsi le mempool global. La finalité complète est atteinte en environ 32 intervalles, soit près de 13 secondes.
- Turbine gère la propagation des blocs en les fragmentant en petits morceaux distribués en parallèle sur le réseau à l’aide d’une structure arborescente. Si la propagation est lente, le débit diminue considérablement. Gulf Stream lutte contre la congestion du mempool en acheminant directement les transactions vers les futurs leaders avant qu’elles ne soient intégrées dans un bloc. Cela permet aux validateurs de recevoir les données des transactions le plus tôt possible, réduisant ainsi la latence et évitant les goulets d’étranglement pendant les périodes à fort volume.
- Sealevel permet l’exécution parallèle des contrats intelligents, car les transactions déclarent à l’avance leurs dépendances de compte. Si deux transactions n’ont pas de dépendances de compte en commun, Sealevel les exécute simultanément sur plusieurs cœurs CPU. Cela contraste avec les modèles d’exécution séquentielle où chaque transaction attend que la précédente soit terminée, indépendamment de leur indépendance logique. L’architecture vise des milliers de transactions par seconde en maximisant l’utilisation du matériel.
- Le compromis réside dans les exigences élevées en matière de matériel de validation. Un débit élevé nécessite une puissance de traitement importante ainsi que des bande passantes réseau suffisantes pour assurer le respect des délais prévus. Un deuxième client indépendant, Firedancer de Jump Crypto, a d’abord été mis en service sur le mainnet sous forme hybride (« Frankendancer ») à partir de septembre 2024, puis en tant que client entièrement indépendant à partir de décembre 2025. Cela augmente la diversité des clients au sein du réseau, réduisant ainsi la dépendance vis-à-vis d’une seule base de code pour les logiques de consensus et d’exécution.
- Pour vérifier cette architecture, ouvrez un explorateur de blocs Solana. Sélectionnez n’importe quel slot récent. Observez la liste des transactions qu’il contient. Notez que le bloc a été généré par un validateur spécifique identifié dans les métadonnées du slot. Vérifiez le nombre de transactions qu’il contient ainsi que l’intervalle entre les slots consécutifs, qui est généralement d’environ 400 millisecondes, bien que certains slots soient sautés lorsque le leader échoue à générer un bloc.
Faits clés
- Proof of History utilise des séquences de hachage SHA-256 pour créer une horloge vérifiable permettant d’ordonner les transactions.
- La version bêta du mainnet de Solana a été lancée en mars 2020 avec des intervalles d’environ 400 millisecondes.
- Tower BFT fournit un consensus par-dessus l’horloge Proof of History.
- La turbine fragmente les blocs en morceaux afin d’en assurer une propagation parallèle à travers le réseau de validateurs.
- Le Gulf Stream transmet les transactions aux futurs leaders, en contournant le mempool mondial.
- Sealevel permet une exécution parallèle en exploitant les dépendances entre comptes déclarées à l’avance.
Exercice neuf, six, trois, un
9RassemblerÉnumérez 9 composants de l’architecture ou du mécanisme de consensus de Solana. Pour chacun, indiquez sa fonction principale et le problème spécifique qu’il résout en ce qui concerne la bande passante ou la latence.
6RegrouperGroupez les 9 composants en 6 catégories en fonction de leur étape dans le cycle de vie de la transaction : horodatage/commande, propagation, exécution, stockage, consensus ou implémentation côté client.
3DistillerRéduisez les 6 catégories en 3 principes de conception fondamentaux qui permettent au Solana d’atteindre un haut débit. Mettez l’accent sur la manière dont les coûts liés à la communication sont minimisés et comment le parallélisme est réalisé.
1CristalliserLes temps de bloc inférieurs à une seconde exigent un compromis entre la décentralisation du réseau et l’intensité matérielle requise.
Vérification des faits
Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.