Présentation générale de Solana

Introduction

Solana est une blockchain à hautes performances et à faible latence, réputée pour sa rapidité, son efficacité et l’importance qu’elle accorde à l’expérience utilisateur. Son architecture intégrée unique permet de traiter des milliers de transactions par seconde sur un réseau mondial décentralisé. Avec un temps de bloc de 400 millisecondes et des frais de transaction représentant une fraction de centime, elle offre à la fois rapidité et rentabilité. Ce rapport examine en détail la conception et le fonctionnement de Solana, ainsi que les principaux mécanismes et la topologie du réseau qui sous-tendent ses capacités.

Solana adopte une approche intégrée du développement de blockchain en s’appuyant sur les décennies d’expérience de son équipe fondatrice dans la création de systèmes distribués. L’un des principes fondamentaux de Solana veut que le logiciel ne limite jamais le matériel. Le logiciel exploite donc pleinement le matériel sur lequel il s’exécute et évolue avec lui. Dans cet écosystème unifié, toutes les applications conçues sur cette blockchain unique héritent de sa composabilité, ce qui leur permet d’interagir et de s’appuyer les unes sur les autres de manière fluide. Cette architecture garantit également une expérience utilisateur simple et intuitive, sans bridge, identifiants de chaîne distincts ni fragmentation de la liquidité.

Solana évolue rapidement. Parmi les développements récents figurent les rollups SVM et ZK Compression, deux importantes solutions de mise à l’échelle. Même si ces projets pourraient un jour façonner notre perception future de Solana, ils n’en sont actuellement qu’aux tout premiers stades de leur développement ou de leur adoption et ne seront pas abordés dans ce rapport.

Cycle de vie d’une transaction

Tout au long de ce rapport, nous étudierons principalement Solana à travers le cycle de vie d’une transaction standard. Pour établir un modèle élémentaire permettant de comprendre les transactions Solana, nous pouvons décrire le processus comme suit : 

• Les utilisateurs initient des transactions, qui sont toutes envoyées au producteur de blocs principal actuel, appelé leader. Celui-ci regroupe ces transactions dans un bloc, les exécute et met ainsi à jour son état local.
• Ce bloc de transactions est ensuite propagé sur l’ensemble du réseau afin que les autres validateurs puissent l’exécuter et le confirmer.‍

Les sections suivantes de ce rapport développeront ce modèle et examineront ce processus beaucoup plus en détail, en commençant par ses principaux participants : les utilisateurs.

Six étapes

Nous nous référerons tout au long de ce rapport au schéma en six étapes présenté ci-dessus, car il fournit un cadre cohérent pour comprendre les relations entre les éléments fondamentaux de Solana.

Les premiers chapitres sont organisés selon ces six étapes. Les derniers chapitres — Gossip, Archive, Économie et Jito — viennent compléter le tableau. Il est important de noter que certains chapitres couvrent plusieurs étapes et que certaines étapes apparaissent dans plusieurs chapitres.

Ce chevauchement est inévitable, car le cadre en six étapes a ses limites. En réalité, Solana est un système distribué complexe composé de nombreux éléments interdépendants.

Utilisateurs

Le parcours d’un utilisateur commence généralement par la configuration et l’approvisionnement d’une application de portefeuille. Plusieurs applications de portefeuille populaires sont disponibles pour Solana, sous forme d’applications mobiles natives ou d’extensions de navigateur.

Les portefeuilles génèrent par cryptographie les paires de clés des utilisateurs, composées d’une clé publique et d’une clé privée. La clé publique sert d’identifiant unique au compte et est connue de tous les participants du réseau. Sur Solana, le compte d’un utilisateur peut être considéré comme une structure de données contenant les informations et l’état liés à ses interactions avec la blockchain Solana. Une clé publique est donc comparable à un nom de fichier : de même qu’un nom de fichier identifie de manière unique un fichier dans un système de fichiers, une clé publique Solana identifie de manière unique un compte sur la blockchain Solana. Sur Solana, les clés publiques sont représentées par des chaînes de 32 octets encodées en Base58.

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

Une clé privée — également appelée clé secrète — peut être considérée comme le mot de passe ou la clé d’accès autorisant l’accès au compte et sa modification. Les blockchains gèrent les autorisations au moyen de signatures créées avec des clés privées. La connaissance de la clé privée confère une autorité absolue sur le compte. Les clés privées Solana ont également une longueur de 32 octets. Les paires de clés sont des combinaisons de 64 octets comprenant la clé publique dans la première moitié et la clé privée dans la seconde.

Exemples :

3j15jr41S9KmdfughusutvvqBjAeEDbU5sDQp8EbwQ3Hify2pfM1hiEsuFFAVq8bwGywnZpswrbDzPENbBZbd5nj

[63,107,47,255,141,135,58,142,191,245,78,18,90,162,107,197,8,33,211,15,228,235,250,30,185,122,105,23,147,115,115,86,8,155,67,155,110,51,117,0,19,150,143,217,132,205,122,91,167,61,6,246,107,39,51,110,185,81,13,81,16,182,30,71]

Les clés privées peuvent également être dérivées de phrases mnémoniques d’amorçage, généralement longues de 12 ou 24 mots. Ce format est souvent utilisé dans les portefeuilles pour simplifier la sauvegarde et la récupération. Plusieurs clés peuvent être dérivées de façon déterministe à partir d’une seule phrase d’amorçage.

Solana utilise Ed25519, un algorithme de signature numérique sur courbe elliptique largement répandu, pour ses besoins de cryptographie à clé publique. Ed25519 est apprécié pour la petite taille de ses clés et de ses signatures, la rapidité de ses calculs et sa résistance à de nombreuses attaques courantes. Chaque adresse de portefeuille Solana représente un point sur la courbe elliptique Ed25519.

L’utilisateur signe les transactions avec sa clé privée. Cette signature est incluse dans les données de la transaction et peut être vérifiée par les autres participants à l’aide de la clé publique de l’expéditeur. Ce processus garantit que la transaction n’a pas été altérée et qu’elle est autorisée par le propriétaire de la clé privée correspondante. La signature sert également d’identifiant unique à la transaction.

Transactions Solana‍

L’envoi d’une transaction est le seul moyen de modifier l’état sur Solana. Toute opération d’écriture passe par une transaction, et les transactions sont atomiques : soit toutes les opérations tentées par la transaction sont effectuées, soit la transaction échoue. Une transaction, plus formellement appelée « message de transaction », comprend quatre sections : un en-tête, une liste d’adresses de comptes, un hash de bloc récent et des instructions.

En-tête

L’en-tête contient des références à la liste des adresses de comptes et indique les comptes qui doivent signer la transaction.

Adresses de comptes

Cette liste comprend tous les comptes qui seront lus ou modifiés pendant la transaction. L’obligation d’établir une telle liste pour chaque transaction est propre à Solana et peut compliquer le travail des développeurs. Toutefois, connaître à l’avance les éléments d’état avec lesquels une transaction interagira permet des optimisations impossibles sur de nombreuses autres blockchains.

Hash de bloc récent

Il sert à empêcher les transactions obsolètes et en double. Un hash de bloc récent expire après 150 blocs, soit environ une minute. Par défaut, les RPC tentent de transmettre les transactions toutes les deux secondes jusqu’à ce que la transaction soit finalisée ou que le hash de bloc récent expire. Dans ce dernier cas, la transaction est abandonnée.

Instructions

Elles constituent la partie centrale de la transaction. Chaque instruction représente une opération précise, par exemple transférer, émettre, brûler, créer ou fermer un compte. Chaque instruction précise le programme à exécuter, les comptes requis et les données nécessaires à son exécution.

Le nombre d’instructions d’une transaction est d’abord limité par sa taille, qui peut atteindre 1 232 octets. Le nombre de comptes pouvant être référencés est également limité. Enfin, la complexité d’une transaction est plafonnée et mesurée en unités de calcul (CU). Les CU quantifient les ressources de calcul utilisées pour traiter les transactions.

Le coût en SOL de l’exécution d’une transaction se divise en deux parties : des frais de base et des frais de priorité. Les frais de base sont fixés à 5 000 lamports par signature, quelle que soit la complexité de la transaction. Une transaction comporte généralement une seule signature.

Les frais de priorité sont techniquement facultatifs, mais deviennent nécessaires lors des périodes de forte demande d’espace de bloc. Ils sont exprimés en micro-lamports, soit un millionième de lamport, par unité de calcul. Ils servent de signal tarifaire et incitent économiquement les nœuds validateurs à inclure les transactions dans leurs blocs. ‍

total fee = prioritization fee + base fee

prioritization fee = compute unit price (micro-lamports) x compute unit limit

À l’heure actuelle, 50 % de tous les frais liés aux transactions sont brûlés, ce qui retire définitivement ces SOL de la circulation, tandis que les 50 % restants reviennent au producteur du bloc. Une nouvelle modification, SIMD 96, sera bientôt introduite afin que 100 % des frais de priorité reviennent au producteur du bloc. Les frais de base restent inchangés.

Envoi des transactions

L’utilisateur connecte son portefeuille à l’application, ce qui permet à celle-ci de lire sa clé publique. La clé privée reste chiffrée et isolée de façon sécurisée dans un environnement distinct de l’application.

L’application construit les paramètres du message de transaction en fonction des interactions de l’utilisateur. Par exemple, si un utilisateur souhaite échanger deux tokens, il indique le nombre de tokens à acheter, les tokens correspondants à vendre et un slippage acceptable pour la transaction.

Une fois le message de transaction prêt, il est envoyé au portefeuille afin d’être signé avec la clé privée de l’utilisateur. Une fenêtre contextuelle invite alors l’utilisateur à confirmer la transaction. Elle peut inclure une simulation des résultats de la transaction. Après la signature, le message de transaction et la signature sont renvoyés à l’application, qui peut alors transmettre la transaction au fournisseur RPC de son choix : son propre fournisseur ou celui du portefeuille.

Les fournisseurs RPC (Remote Procedure Call) servent d’intermédiaires entre les applications et les validateurs qui construisent les blocs. Ce service essentiel permet aux applications de soumettre ou de simuler des transactions signées, ainsi que de récupérer efficacement les données on-chain. Les applications qui souhaitent interagir avec le réseau le font par l’intermédiaire d’un endpoint JSON-RPC ou WebSocket (documentation).

Gulf Stream

Les RPC (Remote Procedure Calls) désignent les nœuds RPC. Ces nœuds peuvent être considérés comme des passerelles permettant d’interagir avec le réseau et d’en lire les données. Ils exécutent le même logiciel que les validateurs complets, mais avec des paramètres différents, ce qui leur permet de simuler précisément les transactions et de conserver une vue à jour de l’état actuel. Au moment de la rédaction de ce rapport, le réseau Solana compte plus de 4 000 nœuds RPC.

Contrairement aux nœuds validateurs complets, les nœuds RPC ne détiennent aucun stake dans le réseau. Sans stake, ils ne peuvent ni voter ni construire de blocs. Cette configuration diffère de celle de la plupart des autres blockchains, où les nœuds validateurs et RPC sont généralement les mêmes. Comme les nœuds RPC ne reçoivent pas de récompenses de staking, leur modèle économique diffère de celui des validateurs. Beaucoup proposent ainsi un service payant aux développeurs d’applications Solana.

Solana se distingue par sa conception initiale visant à fonctionner sans mempool. Contrairement aux blockchains traditionnelles, qui utilisent des protocoles de gossip pour propager les transactions de manière aléatoire et étendue sur le réseau, Solana transmet toutes les transactions à un validateur principal prédéterminé, appelé leader, pour chaque slot.

Lorsqu’un RPC reçoit un message de transaction à inclure dans un bloc, il doit le transmettre au leader. Un calendrier des leaders est établi avant chaque époque, soit environ tous les deux jours. L’époque à venir est divisée en slots fixes de 400 millisecondes, et un leader est choisi pour chaque slot. Les validateurs disposant d’un stake plus élevé sont plus souvent sélectionnés comme leaders au cours de chaque époque. Pendant chaque slot, les messages de transaction sont transmis au leader, qui peut produire un bloc. Lorsque vient son tour, le validateur passe en « mode leader », commence à traiter activement les transactions et diffuse les blocs au reste du réseau.

Qualité de service pondérée par le stake — SWQoS

Début 2024, Solana a introduit un nouveau mécanisme visant à empêcher le spam et à renforcer la résistance aux attaques Sybil : la qualité de service pondérée par le stake (SWQoS). Ce système permet aux leaders de donner la priorité aux messages de transaction relayés par d’autres validateurs stakés. Les validateurs disposant d’un stake plus élevé bénéficient d’une capacité proportionnellement supérieure pour transmettre des paquets de messages de transaction au leader. Cette approche atténue efficacement les attaques Sybil provenant de nœuds sans stake sur l’ensemble du réseau.

‍Dans ce modèle, les validateurs peuvent également conclure des accords pour louer leur capacité pondérée par le stake à des nœuds RPC. En contrepartie, les nœuds RPC bénéficient d’une bande passante accrue, ce qui augmente le taux d’inclusion de leurs transactions dans les blocs. Notamment, 80 % de la capacité d’un leader, soit 2 000 connexions, est réservée à la SWQoS. Les 20 % restants, soit 500 connexions, sont alloués aux messages de transaction provenant de nœuds sans stake. Cette stratégie rappelle les voies prioritaires des autoroutes, où les conducteurs paient un péage pour éviter les embouteillages.

La SWQoS a transformé l’écosystème Solana en relevant les exigences nécessaires pour transmettre des transactions au leader et en réduisant l’efficacité des attaques par spam. Ce changement a incité les applications à fort trafic à intégrer verticalement leurs opérations. En exploitant leurs propres nœuds validateurs ou en accédant à des connexions stakées, les applications peuvent obtenir un accès privilégié au leader et ainsi améliorer leurs capacités de traitement des transactions.

Remarque sur QUIC

Fin 2022, Solana a adopté le protocole réseau QUIC pour gérer la transmission des messages de transaction au leader. Cette transition faisait suite aux perturbations du réseau causées par des bots qui saturaient les émissions de NFT on-chain. QUIC facilite une communication rapide et asynchrone.

‍Initialement développé par Google en 2012, QUIC tente de réunir le meilleur des deux approches. Il facilite une communication rapide et asynchrone, similaire à UDP, tout en offrant les sessions sécurisées et les stratégies avancées de contrôle de flux de TCP. Il permet ainsi d’imposer des limites aux différentes sources de trafic afin que le réseau puisse se concentrer sur le traitement des transactions légitimes. Il repose également sur le concept de flux distincts : si une transaction est abandonnée, elle ne bloque pas nécessairement les autres. En bref, QUIC cherche à combiner les meilleures caractéristiques de TCP et d’UDP.

Construction des blocs

De nombreux réseaux blockchain construisent des blocs entiers avant de les diffuser. C’est ce que l’on appelle la construction discrète de blocs. Solana utilise au contraire une construction continue : les blocs sont assemblés et diffusés dynamiquement à mesure de leur création pendant le slot attribué, ce qui réduit considérablement la latence.

Chaque slot dure 400 millisecondes, et chaque leader se voit attribuer quatre slots consécutifs, soit 1,6 seconde, avant que le leader suivant prenne le relais. Pour qu’un bloc soit accepté, toutes les transactions qu’il contient doivent être valides et reproductibles par les autres nœuds.

Deux slots avant de prendre le rôle de leader, un validateur cesse de transmettre des transactions afin de se préparer à la charge de travail à venir. Pendant cet intervalle, le trafic entrant monte en flèche et dépasse un gigaoctet par seconde, car l’ensemble du réseau dirige ses paquets vers le prochain leader.

À leur réception, les messages de transaction entrent dans la Transaction Processing Unit (TPU), la logique centrale du validateur responsable de la production des blocs. La séquence de traitement commence par la Fetch Stage, où les transactions sont reçues via QUIC. Elles passent ensuite à la SigVerify Stage, où elles font l’objet de contrôles de validation rigoureux. Le validateur vérifie alors la validité et le nombre des signatures, puis élimine les transactions en double.

‍Banking Stage

La Banking Stage peut être décrite comme l’étape de construction des blocs. C’est l’étape la plus importante de la TPU, dont le nom provient de la « bank ». Une bank représente simplement l’état à un bloc donné. Pour chaque bloc, Solana dispose d’une bank permettant d’accéder à l’état de ce bloc. Lorsqu’un bloc est finalisé après avoir reçu les votes d’un nombre suffisant de validateurs, les mises à jour des comptes de la bank sont écrites sur le disque, ce qui les rend permanentes. L’état final de la chaîne résulte de toutes les transactions confirmées. Cet état peut toujours être recréé de façon déterministe à partir de l’historique de la blockchain.‍

Les transactions sont traitées en parallèle et regroupées dans des « entrées » du registre, qui sont des lots de 64 transactions sans conflit. Sur Solana, le traitement parallèle des transactions est facilité par l’obligation pour chaque transaction d’inclure la liste complète de tous les comptes qu’elle lira ou modifiera. Ce choix de conception impose une contrainte aux développeurs, mais permet au validateur d’éviter facilement les conditions de concurrence en ne sélectionnant que des transactions sans conflit pour chaque entrée. Deux transactions sont en conflit si elles tentent toutes deux de modifier le même compte — deux écritures — ou si l’une tente de lire un compte tandis que l’autre le modifie — lecture + écriture. Les transactions en conflit sont donc placées dans des entrées différentes et exécutées séquentiellement, tandis que celles sans conflit sont exécutées en parallèle.

Six threads traitent les transactions en parallèle : quatre sont consacrés aux transactions normales et deux exclusivement aux transactions de vote, qui font partie intégrante du mécanisme de consensus de Solana. Toute la parallélisation du traitement repose sur plusieurs cœurs de CPU ; les validateurs n’ont pas besoin de GPU (documentation).‍

Une fois les transactions regroupées en entrées, elles peuvent être exécutées par la Solana Virtual Machine (SVM). Les comptes nécessaires à la transaction sont verrouillés, puis des vérifications confirment que la transaction est récente et qu’elle n’a pas déjà été traitée. Les comptes sont chargés et la logique de la transaction est exécutée, ce qui met à jour leur état. Un hash de l’entrée est envoyé au service Proof of History pour être enregistré — nous y reviendrons dans la section suivante. Si l’enregistrement réussit, toutes les modifications sont appliquées à la bank et les verrous placés sur chaque compte lors de la première étape sont levés. L’exécution est assurée par la SVM, une machine virtuelle créée à l’aide du fork Solana de rBPF, une bibliothèque dédiée à la compilation JIT et aux machines virtuelles pour les programmes eBPF. Notez que Solana n’impose pas aux validateurs la façon d’ordonner les transactions dans un bloc. Cette flexibilité est essentielle et nous y reviendrons dans la section Économie + Jito de ce rapport.‍

Clients

Solana est un réseau composé de milliers de nœuds exploités indépendamment, qui collaborent pour maintenir un registre unique et unifié. Chaque nœud est une machine à hautes performances qui exécute le même logiciel open source, appelé « client ».

Lors de son lancement, Solana ne disposait que d’un seul logiciel client pour validateurs : initialement appelé client Solana Labs, il est désormais connu sous le nom de client Agave et est écrit en Rust. Depuis, la diversification des clients constitue une priorité qui se concrétisera véritablement avec le lancement du client Firedancer. Firedancer est une réécriture complète du client d’origine, réalisée à partir de zéro en langage C. Développé par une équipe expérimentée de Jump, société spécialisée dans le trading à haute fréquence, il ambitionne de devenir le client pour validateurs le plus performant de toutes les blockchains.

Preuve d’histoire

La preuve d’histoire (PoH) est l’ingrédient secret de Solana. Elle fonctionne comme une horloge spéciale dans chaque validateur, facilitant la synchronisation à l’échelle du réseau. La PoH établit une source de vérité fiable pour l’ordre des événements et l’écoulement du temps. Surtout, elle garantit le respect du calendrier des leaders. Malgré leurs noms similaires, la preuve d’histoire n’est pas un algorithme de consensus comme la preuve de travail.

‍La surcharge de communication entre les nœuds augmente généralement à mesure que les réseaux s’étendent, ce qui complexifie toujours plus la coordination. Solana atténue ce problème en remplaçant la communication de nœud à nœud par un calcul PoH local. Les validateurs peuvent ainsi s’engager sur un bloc avec un seul tour de vote. Les horodatages fiables dans les messages empêchent les validateurs de se devancer et de commencer leurs blocs prématurément.

La PoH repose sur les propriétés uniques des algorithmes de hachage, en particulier SHA256 :

• Déterministe : une même entrée produit toujours le même hachage.
• Taille fixe : quelle que soit la taille de l’entrée, le hachage de sortie comporte toujours 256 bits.
• Efficace : le hachage de n’importe quelle entrée se calcule rapidement.
• Résistance à la préimage : retrouver l’entrée d’origine à partir du hachage de sortie est irréalisable sur le plan informatique.
• Effet d’avalanche : une petite modification de l’entrée, même d’un seul bit, produit un hachage très différent. Cette propriété est appelée effet d’avalanche.
• Résistance aux collisions : il est irréalisable de trouver deux entrées différentes produisant le même hachage de sortie.

Dans chaque client de validateur, un « service de preuve d’histoire » dédié exécute continuellement l’algorithme de hachage SHA256 pour créer une chaîne de hachages. L’entrée de chaque hachage correspond à la sortie du précédent. Cette chaîne agit comme une fonction de délai vérifiable, car le travail de hachage doit être effectué séquentiellement et les résultats des futurs hachages ne peuvent pas être connus à l’avance. Si le service PoH crée une chaîne de mille hachages, nous savons que du temps s’est écoulé puisqu’il a dû calculer chaque hachage l’un après l’autre. On peut considérer cela comme une « micro-preuve de travail ». Pourtant, les autres validateurs peuvent vérifier en parallèle l’exactitude des mille hachages, bien plus rapidement qu’ils n’ont été produits, puisque l’entrée et la sortie de chacun ont été diffusées sur le réseau. La PoH est donc difficile à produire, mais facile à vérifier.

Les écarts de performances entre les différents processeurs pour le calcul de SHA-256 sont étonnamment faibles, même parmi les machines les plus rapides. Une limite supérieure commune a déjà été atteinte, malgré le temps et les efforts considérables consacrés à l’optimisation de cette fonction, principalement en raison de son utilisation par Bitcoin.

‍Pendant le slot d’un leader, le service PoH reçoit les entrées nouvellement traitées par l’étape bancaire. Le hachage PoH actuel et un hachage de toutes les transactions de l’entrée sont combinés pour former le hachage PoH suivant. Celui-ci sert d’horodatage et insère l’entrée dans la chaîne de hachages, prouvant l’ordre dans lequel les transactions ont été traitées. Ce processus confirme non seulement l’écoulement du temps, mais constitue aussi un enregistrement cryptographique des transactions.

Un bloc contient 800 000 hachages. Le flux PoH comprend également des « ticks », des entrées vides qui indiquent que le leader est actif et matérialisent l’écoulement d’une petite fraction de seconde. Un tick se produit toutes les 6,25 millisecondes, soit 64 ticks par bloc et une durée totale de bloc de 400 millisecondes.

Les validateurs exécutent continuellement l’horloge PoH, même lorsqu’ils ne sont pas leaders, car elle joue un rôle essentiel dans la synchronisation entre les nœuds.

Modèle de comptes

Dans un validateur Solana, l’état global est conservé dans la base de données des comptes appelée AccountsDB. Cette base de données stocke tous les comptes, à la fois en mémoire et sur disque. La principale structure de données de l’index des comptes est une table de hachage, ce qui fait essentiellement d’AccountsDB un vaste magasin clé-valeur. La clé est l’adresse du compte et la valeur correspond aux données du compte.

Au fil du temps, le nombre de comptes Solana a atteint plusieurs centaines de millions. Ce chiffre élevé s’explique en partie par une formule chère aux développeurs Solana : « Sur Solana, tout est un compte ! »

Comptes Solana

Un compte est un conteneur qui conserve durablement des données, à l’image d’un fichier sur un ordinateur. Il en existe plusieurs formes :

• Comptes utilisateur : ces comptes possèdent une clé privée et sont généralement générés pour un utilisateur par un logiciel de portefeuille.
• Comptes de données : ces comptes stockent des informations d’état, comme la quantité d’un token donné détenue par un utilisateur.
• Comptes de programme : il s’agit de comptes plus volumineux contenant du bytecode exécutable, plus ou moins équivalent à un fichier .exe sous Windows ou .app sous Mac.
• Comptes de programme natif : il s’agit de comptes de programme spéciaux, prédéployés, qui assurent différentes fonctionnalités essentielles du réseau. Le Vote Program et le BPF Loader en sont des exemples.

Tous les comptes comportent les champs suivants :

Programmes‍

Les comptes de programme Solana contiennent uniquement de la logique exécutable. Lorsqu’un programme s’exécute, il modifie donc l’état d’autres comptes, mais reste lui-même inchangé. Cette séparation du code et de l’état distingue Solana des autres blockchains et permet bon nombre de ses optimisations. Les développeurs écrivent principalement ces programmes en Rust, un langage de programmation généraliste réputé pour l’importance qu’il accorde à la sécurité et aux performances. Plusieurs SDK en TypeScript et Python sont également disponibles pour faciliter la création d’interfaces d’application et permettre l’interaction programmatique avec le réseau.

De nombreuses fonctionnalités courantes sont fournies nativement par des programmes natifs. Par exemple, Solana n’oblige pas les développeurs à déployer du code pour créer un token. Des instructions sont plutôt envoyées à un programme natif prédéployé, qui configure un compte afin de stocker les métadonnées du token et crée ainsi un nouveau token.

Loyer

Le loyer est un mécanisme conçu pour inciter les utilisateurs à fermer les comptes et à limiter le gonflement de l’état. Pour créer un compte, celui-ci doit détenir un solde minimal de SOL, appelé montant « exempt de loyer ». On peut le considérer comme le coût de stockage nécessaire pour maintenir le compte actif dans la mémoire d’un validateur. Si la taille des données du compte augmente, le solde minimal requis pour le loyer augmente proportionnellement. Lorsqu’un compte n’est plus nécessaire, il peut être fermé et le loyer est restitué à son propriétaire. 

Par exemple, si un utilisateur détient un stablecoin libellé en dollars, cet état est stocké dans un compte de token. Actuellement, le montant exempt de loyer d’un compte de token est de 0,002 SOL. Si l’utilisateur transfère l’intégralité de son solde de stablecoins à un ami, le compte de token peut être fermé et l’utilisateur récupère ses 0,002 SOL. Les programmes gèrent souvent automatiquement la fermeture des comptes pour les utilisateurs. Plusieurs applications permettent de nettoyer les anciens comptes inutilisés et de récupérer les petites quantités de SOL qui y sont stockées.

Propriété

Bien que tout le monde puisse lire les données d’un compte, le modèle de propriété de Solana renforce la sécurité en limitant précisément les entités autorisées à modifier, ou écrire, les données d’un compte. Ce concept est essentiel pour faire respecter les règles et les autorisations sur la blockchain Solana. Chaque compte a un programme « propriétaire ». Le propriétaire d’un compte est chargé de le régir et veille à ce que seuls les programmes autorisés puissent modifier ses données. Le transfert de lamports, la plus petite unité de SOL, constitue une exception notable à cette règle : tout le monde peut augmenter le solde en lamports d’un compte, quel qu’en soit le propriétaire.

Stockage de l’état

Comme les programmes Solana sont des fichiers exécutables en lecture seule, ils doivent stocker leur état à l’aide de « Program Derived Addresses » (PDA). Les PDA sont des types de comptes spéciaux associés à un programme et détenus par celui-ci plutôt que par un utilisateur donné. Alors que les adresses utilisateur Solana normales sont dérivées de la clé publique d’une paire de clés Ed25519, les PDA n’ont pas de clé privée. Leur clé publique est dérivée d’une combinaison de paramètres — souvent des mots-clés ou d’autres adresses de compte — et de l’ID de programme (adresse) du programme propriétaire.

Les adresses PDA se trouvent « hors courbe », ce qui signifie qu’elles ne sont pas situées sur la courbe Ed25519 comme les adresses normales. Seul le programme propriétaire du PDA peut générer des signatures pour celui-ci de manière programmatique, ce qui garantit qu’il est le seul à pouvoir modifier l’état du PDA.

Turbine

Pendant l’étape bancaire, les transactions sont organisées en entrées et envoyées au flux de preuve d’histoire pour être horodatées. La banque du bloc est mise à jour et les entrées sont alors prêtes pour la phase suivante : Turbine.

Turbine est le processus par lequel le leader propage son bloc au reste du réseau. Inspiré de BitTorrent, il est conçu pour être rapide et efficace, réduire la surcharge de communication et limiter la quantité de données que le leader doit envoyer.

‍Turbine y parvient en divisant les données de transaction en « shreds » au moyen d’un processus appelé « shredding ». Les shreds sont de petits paquets de données pouvant atteindre 1 280 octets, comparables aux images individuelles d’un flux vidéo. Une fois réassemblés, ils permettent aux validateurs de rejouer le bloc entier. Les shreds sont transmis sur Internet entre les validateurs via UDP et utilisent un code d’effacement pour gérer la perte ou la suppression malveillante de paquets. Le code d’effacement, un mécanisme de détection et de correction des erreurs basé sur des polynômes, garantit l’intégrité des données. Même si certains shreds sont perdus, le bloc peut encore être reconstruit.

Les shreds sont regroupés en lots appelés lots de correction d’erreur sans voie de retour (FEC). Par défaut, ces lots comprennent 64 shreds (32 shreds de données + 32 shreds de récupération). La récupération des données s’effectue pour chaque lot FEC : jusqu’à la moitié des paquets d’un lot peuvent donc être perdus ou corrompus sans empêcher la récupération de toutes les données. Chaque lot de 64 shreds est organisé en arbre de Merkle, dont la racine est signée par le leader, puis chaîné au lot précédent. Ce processus permet d’obtenir les shreds en toute sécurité depuis n’importe quel nœud du réseau qui les possède, car la chaîne de racines de Merkle fournit une preuve vérifiable d’authenticité et d’intégrité.

Le leader diffuse d’abord les données vers un seul nœud racine, qui distribue les shreds à tous les autres nœuds validateurs. Ce nœud racine change à chaque shred. Les validateurs sont organisés en couches qui forment l’« arbre Turbine ». Ceux dont le stake est le plus élevé se trouvent généralement vers le sommet de l’arbre, tandis que ceux dont le stake est plus faible sont placés vers le bas.

‍L’arbre s’étend généralement sur deux ou trois sauts, selon le nombre de validateurs actifs. Pour simplifier la visualisation, un fanout de 3 est représenté ci-dessus, mais la valeur réelle du fanout de Solana est actuellement fixée à 200. Pour des raisons de sécurité, l’ordre de l’arbre change à chaque nouveau lot de shreds.

L’objectif principal de ce système est de réduire la pression exercée par les données sortantes sur le leader et les nœuds racines. Grâce à un mécanisme de transmission et de retransmission, la charge est répartie entre le leader et les retransmetteurs, ce qui limite la pression sur chaque nœud.

Consensus

Lorsqu’un validateur reçoit un nouveau bloc du leader via Turbine, il doit valider toutes les transactions de chaque entrée. Cela implique de rejouer le bloc entier, de valider les hachages PoH en parallèle, de recréer les transactions dans l’ordre dicté par la PoH et de mettre à jour sa banque locale. 

‍Ce processus est pris en charge par la Transaction Validation Unit (TVU), analogue à la Transaction Processing Unit (TPU) du leader. Elle constitue la logique centrale responsable du traitement des shreds et de la validation des blocs. Comme pour la TPU, le flux de la TVU est divisé en plusieurs étapes. Il commence par la Shred Fetch Stage, au cours de laquelle les shreds sont reçus via Turbine. Lors de la Shred Verify Leader Signature Stage suivante, les shreds font l’objet de plusieurs contrôles de cohérence, notamment la vérification de la signature du leader, qui garantit que les shreds reçus proviennent bien de celui-ci. ‍

Lors de la Retransmit Stage, le validateur transmet les shreds aux validateurs appropriés situés en aval, selon sa position dans l’arbre Turbine. Lors de la Replay Stage, il recrée chaque transaction à l’identique et dans le bon ordre, tout en mettant à jour sa version locale de la banque.

La Replay Stage est analogue à l’étape bancaire de la TPU. C’est l’étape la plus importante, que l’on peut décrire plus directement comme celle de la validation du bloc. Replay est une boucle de traitement monothread qui orchestre de nombreuses opérations essentielles, notamment le vote, la réinitialisation de l’horloge PoH et le changement de banque. 

Consensus

Pour parvenir au consensus, Solana utilise Tower BFT (TBFT), une implémentation personnalisée du célèbre algorithme de tolérance pratique aux pannes byzantines (PBFT), couramment employé par la plupart des blockchains pour s’accorder sur l’état de la chaîne. Comme toutes les blockchains, Solana suppose la présence de nœuds malveillants sur le réseau. Le système doit donc résister non seulement aux défaillances de nœuds, mais aussi à certains niveaux d’attaque.

Tower BFT se distingue des autres chaînes en exploitant l’horloge synchronisée fournie par la preuve d’histoire. Alors que le PBFT traditionnel exige plusieurs tours de communication pour convenir de l’ordre des transactions, les nœuds Solana utilisent l’ordre préétabli des événements, ce qui réduit considérablement la surcharge liée aux messages.

Vote

‍Pour participer au consensus et obtenir des récompenses, les validateurs votent pour les blocs qu’ils estiment valides, c’est-à-dire exempts de problèmes tels que les doubles dépenses ou les signatures incorrectes, et qui devraient être considérés comme canoniques. Ils paient des frais de transaction pour ces votes, qui sont traités par le leader et inclus dans un bloc avec les transactions ordinaires des utilisateurs. C’est pourquoi les transactions Solana sont souvent classées en transactions de vote et hors vote. Lorsqu’un validateur soumet un vote correct et réussi, il obtient un crédit. Ce mécanisme incite les validateurs à voter pour la branche qui, selon eux, a les meilleures chances d’être retenue, c’est-à-dire la branche la « plus lourde ».

Branches

Solana est notamment rapide parce que, par conception, le réseau n’attend pas que tous les validateurs s’accordent sur un bloc nouvellement produit avant de produire le suivant. Il n’est donc pas rare que deux blocs différents soient liés au même bloc parent, créant ainsi des branches.

Les validateurs Solana doivent voter sur ces branches et utiliser un algorithme de consensus pour déterminer laquelle adopter. Lorsque plusieurs branches sont en concurrence, une seule est finalement validée par le réseau, tandis que les blocs des branches écartées sont abandonnés.

Chaque slot possède un leader prédéfini et seul le bloc de ce leader est accepté : deux blocs ne peuvent pas être proposés pour un même slot. Le nombre de branches potentielles est donc limité à une liste de branches avec ou sans bloc, susceptible d’apparaître aux limites des slots de rotation des leaders. Lorsqu’un validateur choisit une branche, il y reste engagé jusqu’à l’expiration d’une période de verrouillage. Il doit donc conserver son choix pendant une durée minimale.

‍Le « taux de slots ignorés » de Solana — le pourcentage de slots pendant lesquels aucun bloc n’a été produit — varie de 2 % à 10 %, les branches étant la principale cause de ces slots ignorés. Le début d’une nouvelle époque, la mise hors ligne d’un leader ou la production d’un bloc invalide peuvent également entraîner l’omission de slots.

À retenir :

Le statut d’une transaction sur Solana varie selon son étape actuelle dans le processus de consensus :

• Traitée : la transaction a été incluse dans un bloc.
• Confirmée : le bloc de la transaction a recueilli les votes d’une supermajorité des deux tiers.
• Finalisée : plus de 31 blocs ont été construits au-dessus du bloc de la transaction.

À ce jour, aucun bloc confirmé de manière optimiste dans l’histoire de Solana n’a jamais échoué à être finalisé.‍

Pour chaque bloc, Solana utilise une banque afin d’accéder à l’état correspondant à ce bloc. Lorsqu’une banque est finalisée, les mises à jour de comptes provenant de cette banque et de ses ancêtres sont écrites sur disque. De plus, toutes les mises à jour de comptes issues de banques antérieures qui ne sont pas des ancêtres de la banque finalisée sont supprimées. Ce processus permet à Solana de gérer efficacement plusieurs états potentiels.

Gossip + Archivage

Gossip

Le réseau gossip peut être considéré comme le plan de contrôle du réseau Solana. Contrairement au plan de données, qui gère les flux de transactions, le plan de contrôle diffuse des métadonnées essentielles sur l’état de la blockchain, comme les coordonnées de contact, la hauteur du registre et les informations de vote. Sans gossip, les validateurs et les RPC ne sauraient pas quelles adresses et quels ports sont ouverts pour la communication entre les différents services. Les nouveaux nœuds dépendent également de gossip pour rejoindre le réseau.

Le protocole gossip de Solana utilise une communication informelle pair à pair avec une méthode de diffusion en arbre inspirée d’un algorithme PlumTree modifié. Cette méthode propage efficacement les informations sans dépendre d’une source centrale.

Gossip fonctionne en quelque sorte comme un système isolé, indépendant de la plupart des autres composants du validateur. Toutes les 0,1 seconde, les validateurs et les RPC partagent des objets de données signés via UDP et gossip, ce qui garantit la disponibilité des informations sur l’ensemble du réseau. Tous les messages gossip doivent être inférieurs ou égaux à l’unité de transmission maximale (MTU) de 1 280 octets, appelée « packet struct » dans la base de code.

Les enregistrements gossip sont les objets de données effectivement partagés entre les nœuds. Il en existe environ 10 types, chacun ayant une fonction différente. Ils sont signés, versionnés et horodatés afin de garantir leur intégrité et leur actualité.

Il existe quatre types de messages gossip :‍

1. Push : les messages les plus courants, qui partagent des informations avec un sous-ensemble de « pairs push ».
2. Pull et Pull Response : recherche périodiquement les messages manqués, les réponses pull renvoyant les informations que les nœuds ne possèdent pas.
3. Prune : permet aux nœuds de réduire sélectivement le nombre de connexions qu’ils maintiennent.
4. Ping et Pong : contrôles d’état des nœuds. Lorsqu’un ping est envoyé, un pong est attendu en retour pour indiquer que le nœud pair est toujours actif.

Les données gossip sont stockées dans un Cluster Replicated Data Store (CrdsTable). Cette structure de données peut devenir très volumineuse et doit être régulièrement élaguée.

Archivage

Solana se distingue des autres blockchains, car elle ne nécessite pas l’intégralité de l’historique pour déterminer l’état actuel d’un compte. Le modèle de comptes de Solana garantit que l’état de chaque slot est connu, ce qui permet aux validateurs de stocker l’état actuel de chaque compte sans traiter tous les blocs historiques. Par conception, les RPC et les validateurs ne conservent pas l’intégralité du registre historique. Ils ne stockent généralement que les données de transaction de 1 ou 2 époques, soit 2 à 4 jours, ce qui suffit pour valider la tête de la chaîne.

Les archives sont actuellement gérées par des « nœuds d’entrepôt », exploités par des fournisseurs professionnels de services RPC, la Solana Foundation et d’autres participants de l’écosystème soucieux d’assurer la disponibilité de l’historique des transactions. Les nœuds d’entrepôt conservent généralement l’un des éléments suivants, ou les deux :

1. Archive du registre : téléverse le registre brut et des instantanés d’AccountsDB permettant une relecture depuis zéro.
2. Instance Google Bigtable : stocke les données des blocs depuis le bloc de genèse dans un format permettant de répondre aux requêtes RPC.

Économie + Jito

Solana utilise l’inflation pour distribuer les récompenses de staking en générant de nouveaux tokens SOL à chaque époque. Ce processus réduit la part du réseau détenue par les non-stakers par rapport à celle des stakers, ce qui entraîne un transfert de richesse des premiers vers les seconds. L’inflation a débuté au début de l’année 2021 à un taux initial de 8 %, qui diminue de 15 % par an jusqu’à se stabiliser à long terme à 1,5 %.

‍Tout détenteur de tokens SOL peut obtenir des récompenses et contribuer à sécuriser le réseau en stakant ses tokens auprès d’un ou de plusieurs validateurs. L’attribution de tokens à un validateur est appelée délégation. Déléguer des tokens à un validateur indique qu’on lui fait confiance. Cela ne lui confère toutefois ni la propriété ni le contrôle de ces tokens. Toutes les opérations de staking, d’unstaking et de délégation sont exécutées au début de l’époque suivante.

Récompenses de vote

‍Lorsqu’un validateur soumet un vote, il obtient un crédit si celui-ci est exact et réussi. Les transactions de vote coûtent 0,000005 SOL et sont exemptées de frais de priorité. Les frais de vote représentent environ 1 SOL par jour et par validateur, ce qui en fait le principal coût d’exploitation d’un validateur. Au cours d’une époque, les validateurs accumulent des crédits grâce aux votes et peuvent les échanger contre une part de l’inflation à la fin de l’époque.

Les validateurs les plus performants votent correctement sur environ 90 % des slots. Notez que le pourcentage de slots sans bloc, ou taux de slots ignorés, varie de 2 % à plus de 10 %, et qu’il est impossible de voter sur ces slots. Un validateur moyen vote correctement sur environ 80 % des slots et obtient 345 600 crédits au cours d’une époque de 432 000 slots.

La réserve totale issue de l’inflation est d’abord répartie selon les crédits obtenus pendant l’époque. La part d’un validateur dans le total des crédits, soit ses crédits divisés par la somme des crédits de tous les validateurs, détermine sa récompense proportionnelle. Celle-ci est ensuite pondérée par le stake.

Ainsi, un validateur détenant 1 % du stake total devrait recevoir environ 1 % de l’inflation totale s’il possède un nombre moyen de crédits. Si son nombre de crédits est supérieur ou inférieur à la moyenne, ses récompenses varient en conséquence.‍

Les différences de performances de vote expliquent en partie pourquoi les rendements, mesurés en APY, proposés par les validateurs aux stakers varient. Le taux de commission prélevé par les validateurs constitue un autre facteur. Il correspond à un pourcentage de l’ensemble des récompenses issues de l’inflation attribuées à leur validateur. Enfin, la mise hors ligne ou la désynchronisation d’un validateur par rapport à la blockchain, appelée défaillance, affecte considérablement les rendements.

Récompenses de bloc

Les validateurs désignés comme leaders d’un bloc donné reçoivent des récompenses de bloc supplémentaires. Ces récompenses comprennent 50 % des frais de base et 50 % des frais de priorité de toutes les transactions du bloc, les frais restants étant brûlés. Seul le validateur ayant produit le bloc reçoit ces récompenses. Contrairement aux récompenses de staking, distribuées à chaque époque, les récompenses de bloc sont immédiatement créditées sur le compte d’identité du validateur lors de la production du bloc.

Staking liquide

Le staking liquide est devenu une alternative populaire au staking natif. En échange du staking de leurs SOL, les participants reçoivent un token appelé Liquid Staking Token (LST) ou Liquid Staking Derivative (LSD), généralement dans un pool de staking qui délègue leurs tokens à plusieurs validateurs. Les nouveaux tokens LST reçus représentent la part de SOL stakés de l’utilisateur. Ils peuvent être négociés, utilisés dans des applications ou transférés à d’autres personnes tout en continuant à générer des récompenses de staking. Le principal avantage de ce système est l’amélioration considérable de l’efficacité du capital.

Price of LST = (total staked SOL in pool * price of SOL) / total LST minted

Avec le staking natif traditionnel, le staker accumule directement davantage de SOL au fil du temps. Avec le staking liquide, les récompenses sont réinvesties dans le pool, ce qui augmente la juste valeur du LST. Tant qu’un mécanisme permet d’échanger les LST contre les SOL stakés sous-jacents, les traders d’arbitrage veillent à ce que le prix du token reste cohérent.

Jito

À l’heure où nous écrivons ces lignes, plus de 80 % du stake sur Solana (source) utilise le logiciel client de validation Jito. Ce client, un fork du client Agave d’origine, introduit une enchère d’espace de bloc hors protocole qui offre aux validateurs des incitations économiques supplémentaires sous forme de pourboires. Cette incitation constitue un facteur majeur de l’adoption généralisée du client Jito par les validateurs.

Lorsque les leaders utilisent le client de validation Jito, leurs transactions sont d’abord dirigées vers le Jito-Relayer. Ce logiciel open source sert de routeur proxy pour les transactions. Les autres nœuds du réseau ignorent l’existence du Jito-Relayer : ils envoient simplement les transactions à l’adresse et au port que le leader a annoncés sur le réseau gossip comme son ingress_socket, en supposant qu’ils appartiennent au leader.

‍Le relais conserve toutes les transactions pendant 200 millisecondes avant de les transmettre au leader. Ce mécanisme de « ralentisseur » retarde les messages de transaction entrants et offre une courte fenêtre pour organiser les enchères. Après 200 millisecondes, le relais libère les transactions de manière optimiste, quel que soit le résultat des enchères.

Les enchères d’espace de bloc se déroulent hors chaîne via le Jito Block Engine. Elles permettent aux chercheurs et aux applications de soumettre des groupes de transactions exécutées de manière atomique, appelés bundles. Ces bundles contiennent généralement des transactions sensibles au facteur temps, comme des arbitrages ou des liquidations. Jito prélève 5 % sur tous les pourboires, avec un pourboire minimal de 10 000 lamports. Les pourboires fonctionnent entièrement hors protocole, séparément des frais de priorité et de base intégrés au protocole. Jito proposait auparavant un service canonique de mempool hors protocole, désormais obsolète.