Solana: Kiến trúc mới cho blockchain hiệu suất cao

Abstract

Cet article presente une nouvelle architecture pour une blockchain haute performance. Solana implemente un mecanisme innovant de chronometrage appele Proof of History (PoH) -- une preuve permettant de verifier l'ordre et le passage du temps entre les evenements. PoH est utilise pour encoder le passage du temps de maniere trustless dans un ledger, creant un enregistrement historique qui prouve qu'un evenement s'est produit a un moment precis dans le temps.

L'innovation cle est que PoH permet aux noeuds du reseau d'etablir un ordre temporel des evenements sans avoir besoin de communiquer entre eux. En utilisant une fonction de delai verifiable implementee sous forme de chaine sequentielle de hashes, le systeme genere une horloge cryptographique qui fournit un moyen de verifier le passage du temps entre les evenements. Cela permet au reseau de traiter des milliers de transactions par seconde tout en maintenant la decentralisation et la securite.

PoH est integre a un mecanisme de consensus Proof of Stake (PoS). Cette combinaison permet une architecture blockchain hautement optimisee ou les validateurs peuvent verifier les transactions en parallele et atteindre un consensus de maniere efficace. Le systeme est concu pour evoluer avec la loi de Moore, tirant parti des ameliorations des performances materielles pour augmenter le throughput sans sacrifier les garanties de securite d'un reseau decentralise.

Introduction

Le defi fondamental des systemes blockchain est d'atteindre un debit de transactions eleve tout en maintenant la decentralisation et la securite. Les implementations blockchain actuelles sont limitees par leurs mecanismes de consensus, qui necessitent une communication extensive entre les noeuds pour s'accorder sur le temps et l'ordonnancement des evenements. Cette surcharge de coordination cree un goulot d'etranglement qui empeche les blockchains existantes de passer a l'echelle pour repondre aux demandes des applications a l'echelle mondiale.

Le probleme fondamental est le temps. Dans les systemes distribues, les noeuds ne peuvent pas se fier aux horloges externes car ils ne peuvent pas faire confiance aux horodatages des autres noeuds. Les protocoles de consensus blockchain traditionnels resolvent ce probleme en faisant communiquer extensivement les noeuds pour s'accorder sur l'etat actuel et l'ordre des transactions. Cette surcharge de communication limite fondamentalement le debit, car le reseau ne peut traiter les transactions qu'a la vitesse a laquelle les noeuds peuvent atteindre un consensus sur leur ordonnancement.

Solana introduit Proof of History comme solution a ce probleme de synchronisation. PoH fournit un moyen cryptographique de prouver qu'une certaine quantite de temps s'est ecoulee entre les evenements sans dependre d'horodatages d'acteurs potentiellement malveillants. En creant un enregistrement historique verifiable, PoH permet aux noeuds de traiter les transactions de maniere independante tout en pouvant prouver l'ordre dans lequel les evenements se sont produits. Cette percee permet au reseau de paralleliser le traitement des transactions et d'augmenter considerablement le debit.

L'idee cle est que si nous pouvons creer une source de temps sans confiance, nous pouvons supprimer le goulot d'etranglement de coordination du consensus. Avec PoH fournissant une horloge cryptographique, les validateurs peuvent traiter les transactions en parallele et n'ont besoin de communiquer que pour finaliser l'ordonnancement canonique. Ce changement architectural permet a Solana d'atteindre des niveaux de performance qui etaient auparavant consideres comme impossibles dans une blockchain decentralisee.

Outline

Ce document decrit l'architecture technique de Solana, en se concentrant sur la facon dont Proof of History permet le fonctionnement blockchain haute performance. Le document explique d'abord le mecanisme PoH lui-meme — comment une chaine de hachage sequentielle cree un ordonnancement temporel verifiable des evenements. Nous detaillons les proprietes cryptographiques qui rendent PoH securise et demontrons comment les validateurs peuvent verifier efficacement la sequence PoH.

Le document explore ensuite comment PoH s'integre avec le consensus Proof of Stake. Nous decrivons Tower BFT, un algorithme PoS specifiquement concu pour exploiter les proprietes temporelles de PoH. L'integration permet aux validateurs de voter sur l'etat du registre a des horodatages PoH specifiques, creant un mecanisme de consensus a la fois rapide et securise. Nous expliquons egalement les conditions de penalite qui empechent les comportements malveillants.

Ensuite, nous presentons la conception du reseau Solana et les protocoles de propagation des donnees. Le protocole Gulf Stream permet le transfert de transactions sans avoir besoin d'un mempool, permettant aux clients d'envoyer des transactions directement aux prochains leaders. Nous decrivons comment fonctionne la rotation des leaders et comment le reseau maintient un haut debit meme lorsque le leadership change.

Enfin, nous discutons de l'architecture du systeme, y compris la Transaction Processing Unit (TPU), le runtime parallele Sealevel et Proof of Replication pour la verification du stockage des donnees. Les projections de performance demontrent que Solana peut traiter plus de 700 000 transactions par seconde sur un reseau gigabit standard, avec un debit qui evolue a mesure que le materiel s'ameliore.

Network Design

La conception du reseau Solana est centree sur un systeme de leaders rotatifs ou les validateurs produisent des blocs a tour de role. Le leader est responsable de sequencer les transactions entrantes dans le flux PoH et de publier les blocs resultants sur le reseau. Les leaders sont selectionnes par un algorithme pondere par la mise, et le calendrier de rotation est connu a l'avance, permettant au reseau d'optimiser le transfert des transactions.

Le protocole Gulf Stream elimine le besoin d'un mempool traditionnel en permettant aux clients de transmettre les transactions directement aux prochains leaders. Lorsqu'un client soumet une transaction, elle est transmise au leader attendu selon le calendrier de rotation. Si le leader actuel ne peut pas traiter la transaction, elle est transmise au prochain leader attendu. Cette conception reduit la latence de confirmation et permet aux validateurs d'executer les transactions a l'avance, optimisant davantage le debit.

La propagation des transactions utilise une approche multicouche. Les clients envoient les transactions aux validateurs, qui les transmettent au leader actuel ou prochain. Le leader sequence les transactions dans le flux PoH, creant un ordonnancement total. Une fois sequencees, le leader transmet le flux PoH et les donnees de transaction aux validateurs, qui verifient la sequence PoH et executent les transactions en parallele.

La conception du reseau inclut egalement un protocole de propagation de blocs Turbine qui decoupe les blocs en paquets plus petits et les distribue a travers le reseau dans une structure arborescente. Cette approche minimise les exigences de bande passante pour les validateurs individuels tout en assurant une propagation rapide des blocs. Combinee avec la capacite de PoH a verifier l'ordonnancement des transactions, cette architecture permet a Solana d'atteindre un haut debit sans sacrifier la decentralisation.

Proof of History

Proof of History est une fonction de delai verifiable implementee sous forme de chaine de hachage sequentielle utilisant SHA-256. Le generateur PoH calcule continuellement des hachages SHA-256, utilisant chaque sortie comme entree pour le hachage suivant. Cela cree une chaine sequentielle ou chaque hachage ne peut etre calcule qu'apres le precedent, etablissant un ordonnancement temporel verifiable. L'exigence computationnelle pour generer chaque hachage impose un delai temporel minimum entre les evenements.

La propriete cle de PoH est qu'il est peu couteux a verifier mais couteux a produire. Un verificateur peut verifier l'ensemble de la sequence de hachage en parallele en la divisant en segments et en verifiant chaque segment independamment, puis en verifiant que les segments se connectent correctement. Cependant, la generation doit etre sequentielle — il n'y a aucun moyen de predire la sortie de la chaine de hachage sans calculer effectivement chaque etape intermediaire. Cette asymetrie entre generation et verification est ce qui rend PoH pratique.

Les evenements externes et les donnees de transaction sont inseres dans la sequence PoH en les melangeant dans la chaine de hachage. Lorsqu'une transaction arrive, son hachage est combine avec l'etat PoH actuel, creant un enregistrement qui prouve que la transaction existait a ce point de la sequence. Le generateur PoH enregistre periodiquement des points de controle, publiant la valeur de hachage actuelle ainsi que le nombre de hachages calcules depuis le dernier point de controle. Ces points de controle permettent aux validateurs de verifier efficacement la sequence PoH sans recalculer chaque hachage.

La sequence PoH sert d'horloge cryptographique pour l'ensemble du reseau. Parce que la chaine de hachage est sequentielle et verifiable, n'importe quel noeud peut prouver qu'une certaine quantite de temps s'est ecoulee entre deux evenements simplement en montrant les hachages qui ont ete calcules pendant cet intervalle. Cela elimine le besoin pour les noeuds de faire confiance aux horodatages externes ou de se coordonner entre eux pour etablir l'ordonnancement temporel, supprimant un goulot d'etranglement fondamental dans le consensus blockchain traditionnel.

Proof of History Sequence

La sequence Proof of History est une chaine continue de hachages SHA-256 ou chaque hachage depend de la sortie precedente. La sequence commence avec une valeur de graine initiale, qui est hachee pour produire la premiere sortie. Cette sortie devient l'entree pour le hachage suivant, et le processus se repete indefiniment. Le generateur maintient egalement un compteur qui suit le nombre total de hachages calcules, qui sert d'«horodatage» PoH pour les evenements dans le registre.

Lorsque des donnees doivent etre inserees dans la sequence (comme des hachages de transactions ou des signatures de validateurs), elles sont combinees avec l'etat de hachage actuel en utilisant une fonction de melange deterministe. Par exemple, si l'etat de hachage actuel est hash_n et que nous voulons inserer les donnees D, nous calculons hash_{n+1} = SHA256(hash_n || D), ou || denote la concatenation. Le point d'insertion est enregistre avec la valeur du compteur, prouvant que les donnees D existaient a ce point specifique de la sequence.

La verification de la sequence PoH peut etre parallelisee en divisant la chaine en segments. Par exemple, un validateur pourrait recevoir des points de controle PoH tous les 10 000 hachages. Pour verifier la sequence entre les points de controle, le validateur peut diviser les 10 000 hachages en 100 segments de 100 hachages chacun, verifier chaque segment independamment en parallele, puis verifier que les segments se connectent correctement. Cela permet a la verification de s'adapter horizontalement avec le nombre de coeurs CPU disponibles.

La sequence prend egalement en charge des preuves efficaces que deux evenements se sont produits dans un ordre specifique. Etant donne deux insertions de donnees aux valeurs de compteur n et m ou n m, n'importe qui peut verifier que l'evenement a n s'est produit avant l'evenement a m en verifiant la chaine de hachage entre ces points. Cette propriete permet a Solana de creer un enregistrement historique verifiable de tous les evenements du reseau sans exiger que les noeuds soient en ligne en permanence ou fassent confiance a des sources de temps externes.

Timestamp

Proof of History fonctionne comme une horloge decentralisee qui attribue des horodatages aux evenements sans dependre du temps reel. Chaque hachage PoH represente un «tick» discret de l'horloge cryptographique, et la valeur du compteur sert d'horodatage. Parce que la chaine de hachage est sequentielle et verifiable, ces horodatages sont sans confiance — n'importe quel observateur peut verifier qu'un horodatage est legitime en verifiant la chaine de hachage.

Dans Solana, chaque validateur peut generer sa propre sequence PoH lorsqu'il agit en tant que leader. Lorsque les validateurs effectuent la rotation du leadership, ils synchronisent leurs sequences PoH en utilisant le dernier point de controle confirme du leader precedent. Cela assure la continuite de l'enregistrement temporel meme lorsque differents validateurs produisent des blocs a tour de role. Le reseau etablit une chronologie canonique en atteignant un consensus sur les sequences PoH a accepter comme partie du registre officiel.

Le systeme gere la derive de l'horloge et la variance des performances materielles grace a une combinaison de rotation des leaders et de consensus. Si un leader malveillant ou defaillant tente de generer des horodatages PoH a un rythme incorrect (trop rapide ou trop lent), les validateurs peuvent le detecter en comparant le taux de ticks PoH avec leurs propres generateurs PoH locaux. Des ecarts significatifs par rapport au taux attendu indiquent un probleme, et les validateurs peuvent rejeter les blocs des leaders dont les sequences PoH divergent trop de la mediane du reseau.

Ce mecanisme d'horodatage resout l'un des problemes fondamentaux des systemes distribues : etablir une notion commune du temps sans autorite centrale de confiance. En utilisant PoH comme horloge decentralisee, Solana permet aux validateurs de traiter les transactions en parallele tout en maintenant un ordonnancement globalement coherent. Les horodatages fournissent egalement une base pour des fonctionnalites basees sur le temps comme l'expiration des transactions, les operations programmees et la mesure des performances.

Proof of Stake Consensus

Le mecanisme de consensus de Solana, appele Tower BFT, est un algorithme Proof of Stake specifiquement concu pour exploiter les proprietes temporelles de Proof of History. Les validateurs mettent en jeu des jetons SOL pour participer au consensus et gagner des recompenses pour la validation correcte des blocs. Le systeme de vote pondere par la mise garantit que les validateurs ayant un interet economique plus important dans le reseau ont une influence proportionnellement plus grande sur les decisions de consensus.

L'innovation centrale de Tower BFT est l'utilisation de periodes de verrouillage qui augmentent de maniere exponentielle a chaque vote consecutif. Lorsqu'un validateur vote sur un hachage PoH, il s'engage sur cette branche du registre pour un certain nombre de ticks PoH. S'il vote sur le bloc suivant de cette branche, la periode de verrouillage double. Cela cree une forte incitation economique pour les validateurs a continuer de voter sur la meme branche, car changer de branche necessiterait d'attendre l'expiration des verrouillages precedents.

Specifiquement, si un validateur vote sur un bloc a l'horodatage PoH t, il ne peut pas voter sur une branche conflictuelle tant que 2^n ticks ne se sont pas ecoules, ou n est le nombre de votes consecutifs effectues sur la branche actuelle. Ce mecanisme de verrouillage exponentiel rend le systeme securise contre les attaques a longue portee tout en permettant une finalite rapide. Une fois qu'une supermajority de la mise a vote sur un bloc avec une profondeur suffisante, ce bloc est effectivement finalise.

Les conditions de penalite imposent un comportement honnete. Si un validateur vote sur deux branches conflictuelles pendant une periode ou il devrait etre verrouille, il est penalise — ses jetons mis en jeu sont partiellement detruits et il est retire de l'ensemble des validateurs. Cela rend economiquement irrationnel de tenter l'equivocation ou tout autre comportement byzantin. La combinaison des horodatages verifiables de PoH et des verrouillages exponentiels de Tower BFT cree un mecanisme de consensus rapide et securise, atteignant la finalite en quelques secondes tout en maintenant les garanties de securite des systemes BFT traditionnels.

Streaming Proof of Replication

Proof of Replication (PoRep) est un mecanisme qui permet aux validateurs de prouver qu'ils stockent les donnees du registre sans reveler les donnees elles-memes ni necessiter de calculs intensifs. Solana implemente une version en streaming de PoRep ou les validateurs demontrent continuellement qu'ils repliquent l'etat de la blockchain. Ceci est essentiel pour la securite du reseau, car cela garantit que les donnees du registre sont correctement distribuees entre les validateurs et non concentrees en quelques emplacements.

Le mecanisme PoRep fonctionne en faisant chiffrer par les validateurs des segments du registre en utilisant le chiffrement en mode CBC (Cipher Block Chaining) avec une cle specifique au validateur derivee de son identite. Le processus de chiffrement est tel que chaque bloc chiffre depend du bloc precedent, creant une chaine unique a chaque validateur. Cela empeche les validateurs de simplement copier les donnees chiffrees les uns des autres — chaque validateur doit stocker et traiter les donnees originales du registre pour generer sa version chiffree unique.

Periodiquement, le reseau emet des defis aux validateurs leur demandant de fournir des blocs chiffres specifiques. Parce que le chiffrement est enchaine, le validateur doit avoir stocke tous les blocs precedents pour generer la reponse correcte. Le validateur soumet son bloc chiffre accompagne d'une preuve de Merkle montrant sa position dans son registre chiffre. Le reseau peut verifier cette preuve rapidement sans avoir besoin de dechiffrer ou rechiffrer les donnees.

Cette approche en streaming de PoRep a une faible surcharge comparee aux systemes traditionnels de preuve de stockage. Les validateurs peuvent chiffrer les donnees a mesure qu'elles arrivent et repondre aux defis avec une latence minimale. Le systeme permet egalement la recuperation en cas de perte de donnees — si un validateur perd une partie du registre, il peut le retelecharger aupres d'autres validateurs et le rechiffrer. La combinaison de PoRep avec les horodatages PoH cree un systeme de responsabilite complet ou le reseau peut verifier a la fois quand les donnees ont ete creees et qu'elles sont correctement stockees a travers le reseau de validateurs.

System Architecture

L'architecture systeme de Solana est concue comme un pipeline ou differentes etapes du traitement des transactions se deroulent en parallele. La Transaction Processing Unit (TPU) est le composant central responsable du traitement des transactions entrantes. La TPU comprend plusieurs etapes : fetch (collecte des transactions), verification des signatures, banking (execution des transactions) et write (ecriture dans le stockage). Chaque etape opere en parallele sur differentes transactions, similaire au pipeline d'un CPU.

La verification des signatures est acceleree a l'aide de GPUs, qui sont tres efficaces pour les operations de cryptographie sur courbes elliptiques necessaires a la verification des signatures de transactions. En deleguant cette tache computationnellement intensive aux GPUs, Solana peut verifier les signatures a des taux depassant 900 000 par seconde sur du materiel standard. Cette verification parallele des signatures empeche la validation cryptographique de devenir un goulot d'etranglement meme a des taux de transactions tres eleves.

Le runtime Sealevel est le moteur d'execution parallele des contrats intelligents de Solana. Contrairement aux blockchains traditionnelles qui executent les transactions sequentiellement, Sealevel analyse les transactions pour identifier quels comptes elles accedent et execute les transactions non conflictuelles en parallele sur plusieurs coeurs CPU. Les transactions accedant aux memes comptes sont executees sequentiellement pour maintenir la coherence, mais les transactions accedant a des comptes differents peuvent s'executer simultanement. Ce parallelisme est possible parce que PoH etablit un ordonnancement global — les validateurs peuvent executer les transactions dans n'importe quel ordre tant qu'ils les appliquent a l'etat dans la sequence specifiee par PoH.

L'architecture inclut egalement des composants optimises pour la propagation et le stockage des blocs. Le protocole de propagation de blocs Turbine utilise le codage a effacement pour decouper les blocs en paquets plus petits distribues a travers le reseau dans une structure arborescente, minimisant les exigences de bande passante. Le reseau d'Archivers fournit un stockage decentralise pour les donnees historiques du registre, utilisant PoRep pour assurer la disponibilite des donnees. Ensemble, ces composants creent un systeme capable de traiter des centaines de milliers de transactions par seconde tout en maintenant les proprietes de decentralisation et de securite d'une blockchain.

Performance

L'architecture de Solana est concue pour atteindre des niveaux de performance qui evoluent avec les ameliorations materielles, suivant la loi de Moore. Sur une connexion reseau gigabit standard, le debit theorique maximal est d'environ 710 000 transactions par seconde, en supposant 176 octets par transaction (signatures et metadonnees incluses). Ce calcul est base sur la bande passante reseau comme goulot d'etranglement principal, les goulots d'etranglement computationnels etant elimines par la parallelisation.

La verification des signatures, souvent un facteur limitant dans les performances blockchain, est acceleree par la parallelisation GPU. Un seul GPU peut verifier plus de 900 000 signatures ed25519 par seconde, ce qui depasse la limite de debit du reseau. Cela signifie que la verification des signatures ne contraint pas les performances du systeme — le goulot d'etranglement se deplace vers la bande passante reseau et l'execution des transactions. Pour les transactions simples qui ne font que transferer de la valeur sans logique complexe de contrats intelligents, l'etape de banking peut traiter les transactions a des taux correspondant au taux d'entree du reseau.

Le generateur PoH fonctionne sur un coeur CPU dedie, produisant environ 4 000 hachages par milliseconde sur un processeur a 4 GHz. A ce rythme, la sequence PoH fournit des horodatages avec une granularite de 0,25 microseconde, ce qui est suffisant pour ordonner des millions de transactions par seconde. La nature sequentielle de la generation PoH signifie que ce composant ne peut pas etre parallelise, mais le debit est suffisamment eleve pour ne pas limiter les performances globales du systeme.

A mesure que le materiel s'ameliore, le debit de Solana evolue en consequence. Des reseaux plus rapides, des GPUs plus puissants et des CPUs ameliores contribuent tous a des taux de transactions plus eleves. Le systeme est concu pour tirer parti de ces ameliorations sans necessiter de modifications du protocole. Cette approche d'evolutivite contraste avec les blockchains fondamentalement limitees par des mecanismes de consensus sequentiels, permettant a Solana d'atteindre des niveaux de performance precedemment consideres comme impossibles dans un systeme decentralise tout en maintenant les garanties de securite et de decentralisation.

Conclusion

Proof of History represente une percee fondamentale dans l'architecture blockchain en resolvant le probleme de synchronisation qui a limite l'evolutivite des registres distribues. En creant une horloge cryptographique verifiable, PoH permet aux validateurs d'etablir un ordonnancement temporel des evenements sans la surcharge de communication extensive requise par les mecanismes de consensus traditionnels. Cette innovation supprime un goulot d'etranglement critique et permet au traitement des transactions d'etre parallelise a travers le reseau.

L'integration de PoH avec des composants systeme optimises — verification des signatures acceleree par GPU, execution parallele des transactions via Sealevel et protocoles efficaces de propagation des blocs — cree une blockchain capable de traiter des centaines de milliers de transactions par seconde sur du materiel standard. Plus important encore, l'architecture est concue pour evoluer avec les ameliorations materielles, ce qui signifie que les performances continueront d'augmenter a mesure que les processeurs deviendront plus rapides et les reseaux plus performants.

La conception de Solana demontre que haute performance et decentralisation ne sont pas mutuellement exclusives. En tirant parti de PoH comme fondation pour le consensus et la coordination du systeme, le reseau atteint des niveaux de debit comparables aux bases de donnees centralisees tout en maintenant les proprietes de securite et de resistance a la censure d'une blockchain decentralisee. Le mecanisme de consensus Tower BFT pondere par la mise garantit que le reseau reste securise contre les acteurs byzantins tout en atteignant une finalite rapide.

L'implementation de cette architecture fournit un chemin pratique pour que la technologie blockchain evolue vers une adoption mondiale. Les applications necessitant un haut debit de transactions — comme les echanges decentralises, les plateformes de jeux et les systemes financiers — peuvent desormais etre construites sur une infrastructure veritablement decentralisee sans compromettre les performances. Proof of History ouvre la porte a une nouvelle generation d'applications blockchain qui etaient auparavant irrealisables en raison des contraintes d'evolutivite.