Introduction

“Nous savions mieux que quiconque dans le monde, plus petit, plus rapide, moins cher, et maintenant nous appliquons ces concepts à la blockchain.” — Greg Fitzgerald, co-fondateur de Solana

Solana est une blockchain haute performance et à faible latence, renommée pour sa rapidité, son efficacité et son focus sur l'expérience utilisateur. Son architecture intégrée unique permet des milliers de transactions par seconde à travers un réseau décentralisé à l'échelle mondiale. Avec un temps de bloc de 400 millisecondes et des frais de transaction qui sont des fractions de cent, elle offre à la fois rapidité et rentabilité. Ce rapport plonge dans les subtilités de la conception et du fonctionnement de Solana, explorant les mécanismes clés et la topologie du réseau qui contribuent à ses capacités.

Solana adopte une approche intégrée du développement de la blockchain, tirant parti des décennies d'expérience de l'équipe fondatrice dans la construction de systèmes distribués. L'un des principes fondamentaux de Solana est que le logiciel ne doit jamais entraver le matériel. Cela signifie que le logiciel exploite pleinement le matériel sur lequel il s'exécute et s'adapte à lui. En tant qu'écosystème unifié, toutes les applications construites sur cette blockchain unique héritent de la composition, ce qui leur permet d'interagir et de se développer de manière transparente les unes avec les autres. Cette architecture garantit également une expérience utilisateur simple et intuitive sans avoir besoin de ponts, d'identifiants de chaîne séparés ou de fragmentation de liquidités.

Solana évolue rapidement, avec des développements récents incluant des rollups SVM etCompression ZKen tant que solutions de mise à l'échelle importantes. Bien que ces projets puissent un jour façonner notre perception future de Solana, ils en sont actuellement aux tout premiers stades de développement ou d'adoption et ne seront pas couverts dans ce rapport.

Cycle de vie de la transaction

Notre principal objectif pour comprendre Solana tout au long de ce rapport sera le cycle de vie d'une transaction typique. Pour construire un modèle de base pour 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 bloc principal actuel (appelé le leader). Le leader compile ces transactions dans un bloc, les exécute et met ainsi à jour leur état local.
• Ce bloc de transactions est ensuite propagé dans tout le réseau pour que d'autres validateurs l'exécutent et le confirment.

Les sections suivantes de ce rapport développeront ce modèle et entreront dans ce processus avec beaucoup plus de détails, en commençant par les principaux participants, les utilisateurs.

Souviens-toi

Des changements substantiels apportés au protocole central Solana passent par un processus formel et transparentprocessusde soumettre un Document d'Amélioration de Solana (SIMD) que les membres de la communauté et l'ingénierie principale critiqueront publiquement. Les SIMD sont ensuite votés par le réseau.

Six étapes

Nous ferons référence à la visualisation en six étapes ci-dessus tout au long de ce rapport, car elle nous offre un cadre cohérent pour comprendre les relations entre les éléments clés de Solana.

Les premiers chapitres sont organisés selon ces six étapes. Les chapitres finaux - Potins, Archives, Économie et Jito - lient toutes les extrémités lâches. Il est important de noter que certains chapitres couvriront plusieurs étapes, et certaines étapes apparaîtront dans plusieurs chapitres.

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

Utilisateurs

"Solana a le potentiel de devenir l'Apple de la crypto" - Raj Gokal, co-fondateur de Solana

Le parcours d'un utilisateur commence généralement par la configuration et le financement d'une application de portefeuille. Plusieurs applications de portefeuille populaires sont disponibles pour Solana, que ce soit sous forme d'applications mobiles natives ou d'extensions de navigateur.

Les portefeuilles génèrent cryptographiquement des paires de clés utilisateur, composées de clés publique et privée. La clé publique agit en tant qu'identifiant unique pour leur compte et est connue de tous les participants du réseau. Le compte d'un utilisateur sur Solana peut être considéré comme une structure de données qui contient des informations et un état liés à leurs interactions avec la blockchain Solana. De cette manière, une clé publique est similaire à un nom de fichier : tout comme 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. Les clés publiques sur Solana sont représentées sous forme de chaînes encodées en Base58 de 32 octets.

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

Une clé privée — également connue sous le nom de clé secrète — peut être considérée comme le mot de passe ou la clé d'accès qui accorde la permission d'accéder et de modifier le compte. La signature avec des clés privées est la manière dont les blockchains gèrent l'autorisation. La connaissance de la clé privée donne 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 les combinaisons de 64 octets de clés publiques (première moitié) et de clés privées (deuxième moitié). 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, généralement composées de 12 ou 24 mots. Ce format est souvent utilisé dans les portefeuilles pour une sauvegarde et une récupération plus faciles. Plusieurs clés peuvent être dérivées de manière déterministe à partir d'une seule phrase mnémonique.

Solana utiliseEd25519, un algorithme de signature numérique sur courbe elliptique largement utilisé, pour ses besoins en cryptographie à clé publique. Ed25519 est apprécié pour sa petite taille de clé, sa petite taille de signature, ses calculs rapides et son immunité à 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 avec les données de la transaction et peut être vérifiée par d'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 est autorisée par le propriétaire de la clé privée correspondante. La signature sert également d'identifiant unique pour la transaction.

Transactions Solana

Envoyer une transaction est le seul moyen de muter l'état sur Solana. Toute opération d'écriture est effectuée via une transaction, et les transactions sont atomiques : soit tout ce que la transaction tente de faire se produit, 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 compte, un hachage de bloc récent et des instructions.

• En-tête : L'en-tête contient des références à la liste des adresses de compte, indiquant quels comptes doivent signer la transaction.
• Adresses des comptes : Cette liste comprend tous les comptes qui seront lus ou écrits lors de la transaction. Établir une telle liste pour chaque transaction est une exigence unique à Solana et peut être un défi pour les développeurs. Cependant, savoir à l'avance avec quels éléments de l'état une transaction interagira permet des optimisations impossibles sur de nombreuses autres blockchains.
• Blockhash récent : Cela est utilisé pour éviter les transactions en double et obsolètes. Un blockhash récent expire après 150 blocs (environ 1 minute). Par défaut, les RPC tentent de transmettre les transactions toutes les 2 secondes jusqu'à ce que la transaction soit finalisée ou que le blockhash récent expire, auquel cas la transaction est abandonnée.
• Instructions : Elles constituent la partie centrale de la transaction. Chaque instruction représente une opération spécifique (par exemple, transfert, émission, destruction, création de compte, clôture de compte). Chaque instruction spécifie le programme à exécuter, les comptes requis et les données nécessaires à l'exécution de l'instruction.

Le nombre d’instructions dans une transaction est d’abord limité par sa taille, qui peut aller jusqu’à 1 232 octets. Il existe également des limites quant au nombre de comptes pouvant être référencés. Enfin, il existe des limites à la complexité d’une transaction mesurée en unités de calcul (UC). Les UC quantifient les ressources de calcul dépensées dans le traitement des transactions.

Se souvenir

La plus petite unité de SOL est connue sous le nom de "lamport," équivalant à un milliardième de SOL, similaire à un satoshi dans Bitcoin. Le lamport est nommé d'aprèsLeslie Lamport, un informaticien et mathématicien dont la recherche a posé de nombreuses bases théoriques des systèmes distribués modernes.

Le coût en SOL pour exécuter une transaction est séparé en 2 parties - des frais de base et des frais de priorisation. Les frais de base sont de 5000 lamports fixes par coût de signature, indépendamment de la complexité de la transaction—généralement, il y a 1 signature par transaction.

Les frais de priorisation sont techniquement facultatifs, mais deviennent nécessaires pendant les périodes de forte demande d'espace de bloc. Ces frais sont tarifés en micro-lamports (millionième d'un lamport) par unité de calcul. Leur objectif est d'agir comme un signal de prix, rendant les transactions plus économiquement attrayantes pour les nœuds validateurs à inclure dans leurs blocs.

frais totaux = frais de priorisation + frais de base

frais de priorisation = prix de l'unité de calcul (micro-lamports) x limite de l'unité de calcul

Actuellement, 50 % de tous les frais liés aux transactions sont brûlés, retirant définitivement ces SOL de la circulation, les 50 % restants allant au producteur de blocs. Un nouveau changement (SIMD 96) devrait bientôt être introduit, permettant que 100 % des frais de priorisation aillent au producteur de blocs. Les frais de base restent inchangés.

‍

Envoyer des transactions

Un utilisateur connecte son portefeuille à l'application, permettant à l'application de lire la clé publique de l'utilisateur. La clé privée reste chiffrée et sécurisée dans un environnement séparé 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 jetons, il spécifierait la quantité de jetons à acheter, les jetons correspondants à vendre et un glissement de transaction acceptable.

Une fois que le message de transaction est prêt, il est envoyé au portefeuille pour être signé avec la clé privée de l'utilisateur. À ce stade, l'utilisateur est invité avec une fenêtre contextuelle pour confirmer sa volonté de transiger. Cette fenêtre contextuelle peut inclure une simulation des résultats de la transaction. Une fois signé, le message de transaction et la signature sont renvoyés à l'application, qui peut ensuite transmettre la transaction à un fournisseur RPC de son choix, soit le sien, soit en utilisant le fournisseur du portefeuille.

Les fournisseurs de RPC (Remote Procedure Call) agissent en tant qu'intermédiaires entre les applications et les validateurs qui construisent des blocs. Ils sont un service essentiel qui permet aux applications desoumettreou simuler des transactions signées et récupérer efficacement des données on-chain. Les applications qui souhaitent interagir avec le réseau le font via un point de terminaison JSON-RPC ou WebSocket ( docs).

Rappelez-vous

Le terme "transaction échouée" sur Solana est trompeur et a causé une confusion considérable. Ces transactions entraînent des frais et sont exécutées avec succès par le runtime exactement comme l'a voulu le signataire. Elles "échouent" en raison de la logique propre de la transaction exigeant qu'elles le fassent. +80% des transactions "échouées" proviennent du code d'erreur 0x1771, le code pour dépassement du montant de glissement (slippage amount)donnéesNotamment, 95% de ces transactions sont soumises par seulement 0,1% des adresses Solana actives, principalement des bots automatisés tentant de profiter d'opportunités d'arbitrage de prix sensibles au temps.

Courant du Golfe

« L'objectif littéral de Solana est de traiter les transactions aussi rapidement que les nouvelles se propagent à travers le monde - donc à la vitesse de la lumière à travers la fibre. Ce avec quoi nous sommes en concurrence, ce sont le NASDAQ et la Bourse de New York. » - Anatoly Yakovenko, cofondateur de Solana

Les RPC (appels de procédure à distance) font référence aux nœuds RPC. Ces nœuds peuvent être considérés comme des passerelles pour interagir avec et lire des données à partir du réseau. Ils exécutent le même logiciel que les validateurs complets mais avec des paramètres différents, ce qui leur permet de simuler avec précision des transactions et de maintenir une vue à jour de l'état actuel. Au moment de la rédaction de cet article, il y a plus de 4 000 nœuds RPC sur le réseau Solana.

Contrairement aux nœuds de validation complets, les nœuds RPC ne détiennent aucune participation dans le réseau. Sans participation, ils ne peuvent pas voter ni construire de blocs. Cette configuration diffère de la plupart des autres blockchains, où les nœuds de validation et RPC sont généralement les mêmes. Comme les nœuds RPC ne reçoivent pas de récompenses de mise, l'économie de l'exploitation des nœuds RPC est distincte de celle des validateurs, beaucoup fonctionnant comme un service payant pour les développeurs exploitant des applications Solana.

Solana se distingue car elle a été conçue dès le départ pour fonctionner sans mempool. Contrairement aux blockchains traditionnelles qui utilisent des protocoles de propagation de rumeurs pour diffuser de manière aléatoire et large les transactions à travers le réseau, Solana transfère toutes les transactions à un validateur principal prédéterminé, appelé le leader, pour chaque créneau.

Appel

Solana exploite quatre clusters : Localnet, Testnet, Devnet et Mainnet-Beta. Lorsque les gens font référence à Solana ou au réseau Solana, ils font presque toujours référence à Mainnet-Beta. Mainnet-Beta est le seul cluster où les jetons ont une valeur réelle, tandis que les autres clusters sont utilisés uniquement à des fins de test.

Une fois qu’un RPC reçoit un message de transaction à inclure dans un bloc, il doit être transmis à la ligne de repère. Un planning de ligne de repère est produit avant chaque époque (environ tous les deux jours). L’époque à venir est divisée en créneaux horaires, chacun fixé à 400 millisecondes, et un leader est choisi pour chaque créneau. Les validateurs avec une mise plus élevée seront choisis plus souvent pour devenir leader à chaque époque. Lors de chaque créneau, les messages de transaction sont transmis au leader, qui a la possibilité de produire un bloc. Lorsque c’est au tour d’un validateur, il passe en « mode leader », commence à traiter activement les transactions et à diffuser des blocs au reste du réseau.

Service de qualité pondéré par les stakes - SWQoS

Début 2024, Solana a introduit un nouveau mécanisme visant à prévenir le spam et à renforcer la résistance de Sybil, connu sous le nom de "Stake-Weighted Quality of Service" (SWQoS). Ce système permet aux leaders de prioriser les messages de transaction qui sont relayés par d'autres validateurs mis en jeu. Ainsi, les validateurs avec une mise plus élevée se voient accorder une capacité proportionnellement supérieure pour transmettre des paquets de messages de transaction au leader. Cette approche atténue efficacement les attaques de Sybil provenant de nœuds non mis en jeu à travers le réseau.

Dans ce modèle, les validateurs peuvent également conclure des accords pour louer leur capacité pondérée en parts aux nœuds RPC. En retour, les nœuds RPC obtiennent une bande passante accrue, ce qui leur permet d'atteindre de meilleurs taux d'inclusion des transactions dans les blocs. Notamment, 80 % de la capacité d'un leader (2 000 connexions) est réservée à SWQoS. Les 20 % restants (500 connexions) sont alloués aux messages de transaction provenant de nœuds non misés. Cette stratégie d'allocation reflète les voies prioritaires sur les autoroutes, où les conducteurs paient un péage pour éviter les embouteillages.

SWQoS a impacté l'écosystème Solana en augmentant les exigences pour transmettre les transactions au leader et en réduisant l'efficacité des attaques de spam. Ce changement a incité les applications à fort trafic à intégrer verticalement leurs opérations. En exécutant leurs propres nœuds de validation, ou en ayant accès à des connexions mises en jeu, les applications peuvent garantir un accès privilégié au leader, améliorant ainsi leurs capacités de traitement des transactions.

Une note rapide

Fin 2022, Solana a adopté leprotocole de réseau QUICpour gérer la transmission des messages de transaction au leader. Cette transition a été provoquée par des perturbations du réseau causées par des robots envoyant du spam sur les NFT on-chain. QUIC facilite la communication rapide et asynchrone.

Initialement développé parGoogleEn 2012, QUIC tente d'offrir le meilleur des deux mondes. Il facilite la communication rapide et asynchrone similaire à UDP, mais avec les sessions sécurisées et les stratégies avancées de contrôle de flux de TCP. Cela permet de limiter les sources individuelles de trafic afin que le réseau puisse se concentrer sur le traitement des transactions authentiques. Il dispose également d'un concept de flux séparés; donc si une transaction est abandonnée, elle n'a pas besoin de bloquer les autres. En bref, on peut considérer que QUIC tente de combiner les meilleures caractéristiques de TCP et UDP.

Boîte de mise en évidence

Le poids de mise en jeu est un principe récurrent que l'on retrouve dans l'ensemble des systèmes de Solana, englobant les récompenses de vote, les arbres de turbine, les calendriers des leaders, le Gulf Stream et le réseau de commérages. Les validateurs avec une mise en jeu plus importante se voient accorder une plus grande confiance et des rôles prioritaires dans le réseau.

Construction de blocs

"Nous considérons SVM (Solana Virtual Machine) comme le meilleur en termes de technologie de machine virtuelle actuellement." — Andre Cronje, Fondation Fantom

De nombreux réseaux blockchain construisent des blocs entiers avant de les diffuser, ce qui est connu sous le nom de construction de blocs discrets. Solana, en revanche, utilise une construction de blocs continue qui consiste à assembler et diffuser des blocs dynamiquement au fur et à mesure de leur création pendant une période de temps allouée, réduisant ainsi considérablement la latence.

Chaque créneau dure 400 millisecondes, et chaque leader se voit attribuer quatre créneaux consécutifs (1,6 seconde) avant de passer le relais au prochain leader. 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 d'assumer la direction, un validateur interrompt la transmission des transactions pour se préparer à sa charge de travail à venir. Pendant cette période, le trafic entrant augmente brusquement, atteignant plus d'un gigaoctet par seconde alors que l'ensemble du réseau dirige des paquets vers le leader entrant.

À réception, les messages de transaction entrent dans l'unité de traitement des transactions (TPU), la logique centrale du validateur responsable de la production de blocs. Ici, la séquence de traitement des transactions commence par la phase de récupération, où les transactions sont reçues via QUIC. Ensuite, les transactions progressent vers la phase de vérification de signature, subissant des contrôles de validation rigoureux. Ici, le validateur vérifie la validité des signatures, vérifie le nombre correct de signatures et élimine les transactions en double.

Étape bancaire

La phase bancaire peut être décrite comme la phase de construction de blocs. C'est la phase la plus importante du TPU, qui tire son nom de la « banque ». Une banque n'est rien d'autre que l'état à un bloc donné. Pour chaque bloc, Solana dispose d'une banque qui est utilisée pour accéder à l'état à ce bloc. Lorsqu'un bloc est finalisé après que suffisamment de validateurs ont voté en sa faveur, ils transfèrent les mises à jour des comptes de la banque sur le disque, les rendant ainsi permanentes. L'état final de la chaîne est le résultat de toutes les transactions confirmées. Cet état peut toujours être recréé de manière déterministe à partir de l'historique de la blockchain.

Les transactions sont traitées en parallèle et regroupées dans des "entrées" de grand livre, qui sont des lots de 64 transactions non conflictuelles. Le traitement des transactions en parallèle sur Solana est facilité car chaque transaction doit inclure une liste complète de tous les comptes auxquels elle va lire et écrire. Ce choix de conception impose un fardeau aux développeurs, mais permet au validateur d'éviter les conditions de concurrence en sélectionnant facilement uniquement les transactions non conflictuelles à exécuter dans chaque entrée. Les transactions entrent en conflit si elles tentent toutes deux d'écrire sur le même compte (deux écritures) ou si l'une tente de lire et l'autre d'écrire sur le même compte (lecture + écriture). Ainsi, les transactions en conflit vont dans des entrées différentes et sont exécutées séquentiellement, tandis que les transactions non conflictuelles sont exécutées en parallèle.

Il y a six threads traitant les transactions en parallèle, dont quatre dédiés aux transactions normales et deux exclusivement aux transactions de vote qui sont essentielles au mécanisme de consensus de Solana. Toute parallélisation du traitement est réalisée à travers plusieurs cœurs de CPU; les validateurs n'ont pas besoin de GPU ( docs).

Une fois que les transactions ont été regroupées en entrées, elles sont prêtes à être exécutées par la machine virtuelle Solana (SVM). Les comptes nécessaires à la transaction sont verrouillés ; des vérifications sont effectuées pour confirmer que la transaction est récente mais n'a pas déjà été traitée. Les comptes sont chargés, et la logique de la transaction est exécutée, mettant à jour les états des comptes. Un hachage de l'entrée sera envoyé au service de Preuve de l'Histoire pour être enregistré (plus de détails à ce sujet dans la prochaine section). Si le processus d'enregistrement est réussi, tous les changements seront validés par la banque, et les verrous sur chaque compte placés lors de la première étape seront levés. L'exécution est effectuée par le SVM, une machine virtuelle construite en utilisant la version modifiée de SolanarBPF, une bibliothèque pour travailler avec la compilation JIT et des machines virtuelles pour les programmes eBPF. Notez que Solana ne dicte pas comment les validateurs choisissent d'ordonner les transactions au sein d'un bloc. Cette flexibilité est un point crucial sur lequel nous reviendrons plus tard dans la section Économie + Jito de ce rapport.

Rappeler

Le terme SVM peut être ambigu, car il peut faire référence soit à la “machine virtuelle Solana” soit à la “machine virtuelle Sealevel”. Les deux termes décrivent le même concept, Sealevel étant le nom de l'environnement d'exécution de Solana. Le terme SVM continue d'être utilisé de manière floue malgré les récents efforts pour le définir précisémentdéfinir ses limites.

Clients

Solana est un réseau composé de milliers de nœuds exploités indépendamment collaborant pour maintenir un grand livre unifié unique. Chaque nœud constitue une machine haute performance exécutant le même logiciel open source connu sous le nom de "client".

Solana a été lancée avec un logiciel client de validateur unique - initialement le client Solana Labs, maintenant connu sous le nom deClient Agave— écrit en Rust. L'expansion de la diversité des clients a été une priorité depuis le début et c'est une priorité qui se concrétisera vraiment avec le lancement de laClient FiredancerFiredancer est une réécriture complète du client original en langage de programmation C. Développé par une équipe expérimentée de la société de trading haute fréquence Jump, il promet d'être le client de validation le plus performant sur n'importe quelle blockchain.

Preuve de l'histoire

« J'ai pris deux cafés et une bière, et je suis resté éveillé jusqu'à 4h du matin. J'ai eu ce moment eurêka qu'un puzzle similaire à la preuve de travail utilisant la même fonction de hachage résistante à la préimage SHA-256... Je savais que j'avais cette flèche du temps. » — Anatoly Yakovenko, co-fondateur de Solana

La Preuve d'Histoire (PoH) est l'ingrédient secret de Solana, fonctionnant comme une horloge spéciale dans chaque validateur facilitant la synchronisation à travers le réseau. La PoH établit une source fiable de vérité pour l'ordre des événements et le passage du temps. Plus critique encore, elle garantit le respect du calendrier du leader. Malgré des noms similaires, la Preuve d'Histoire n'est pas un algorithme de consensus tel que la Preuve de Travail.

La surcharge de communication entre les nœuds augmente généralement à mesure que les réseaux se développent, et la coordination devient de plus en plus compliquée. Solana atténue cela en remplaçant la communication de nœud à nœud par un calcul local de PoH. Cela signifie que les validateurs peuvent s'engager à un bloc avec un seul tour de vote. Les horodatages de confiance dans les messages garantissent que les validateurs ne peuvent pas se chevaucher et commencer leurs blocs prématurément.

Les PoH sous-jacents sont les propriétés uniques des algorithmes de hachage, en particulierSHA256:

• Déterministe : La même entrée produira toujours le même hachage.
• Taille Fixe: Peu importe la taille de l'entrée, le hachage de sortie est toujours de 256 bits.
• Efficace : il est rapide de calculer le hachage pour n'importe quelle entrée donnée.
• Résistance à la préimage: Trouver l'entrée d'origine à partir de la sortie de hachage est informatiquement irréalisable.
• Effet Avalanche : Un petit changement dans l'entrée (même un seul bit) résulte en un hachage significativement différent, une propriété connue sous le nom d'effet avalanche.
• Résistance aux collisions: Il est impossible de trouver deux entrées différentes produisant la même sortie de hachage.

Au sein de chaque client validateur, un service dédié de « preuve d'historique » fonctionne continuellement avec l'algorithme de hachage SHA256 en créant une chaîne de hachages. L'entrée de chaque hachage est la sortie du hachage précédent. Cette chaîne agit de la même manière qu'une fonction de retard vérifiable, étant donné que le travail de hachage doit être effectué en séquence et que les résultats des hachages futurs ne peuvent pas être connus à l'avance. Si le service PoH crée une chaîne de mille hachages, nous savons que le temps s'est écoulé pour qu'il calcule chaque hachage séquentiellement - cela peut être considéré comme une « micro-preuve de travail ». Cependant, d'autres validateurs peuvent vérifier la correction des mille hachages en parallèle à un rythme beaucoup plus rapide que celui auquel ils ont été produits, puisque l'entrée et la sortie de chaque hachage ont été diffusées sur le réseau. Par conséquent, la PoH est difficile à produire mais facile à vérifier.

La gamme de performances en calcul du SHA-256 sur différents CPU est étonnamment étroite, avec seulement de petites différences parmi les machines les plus rapides. Une limite supérieure commune a déjà été atteinte, malgré le temps et les efforts importants investis dans l'optimisation de cette fonction, principalement en raison de la dépendance de Bitcoin à son égard.

Pendant le créneau d'un leader, le service PoH recevra les nouvelles entrées traitées de l'étape bancaire. Le hachage PoH actuel plus un hachage de toutes les transactions dans l'entrée sont combinés pour former le prochain hachage PoH. Cela sert de marqueur temporel insérant l'entrée dans la chaîne de hachages, prouvant la séquence dans laquelle les transactions ont été traitées. Ce processus confirme non seulement le passage du temps, mais sert également d'enregistrement cryptographique des transactions.

Dans un seul bloc, il y a 800 000 hachages. Le flux PoH comprend également des "ticks," qui sont des entrées vides indiquant la vivacité du leader et le passage du temps approximativement une petite fraction d'une seconde. Un tick se produit toutes les 6,25 millisecondes, ce qui donne 64 ticks par bloc et un temps total de bloc de 400 millisecondes.

Les validateurs font tourner en continu l'horloge PoH même lorsqu'ils ne sont pas le leader car elle joue un rôle pivot dans le processus de synchronisation entre les nœuds.

Se souvenir

Le principal avantage de PoH est qu'il garantit que le calendrier du chef correct doit être respecté, même si un producteur de blocs est hors ligne - un état connu sous le nom de "délinquant". PoH empêche un validateur malveillant de produire des blocs avant leur tour.

Modèle de comptes

"Séparer le code et l'état dans SVM a été la meilleure décision de conception. Bénis soient les développeurs de systèmes embarqués qui ont religieusement inculqué ce concept dans mon esprit." — Anatoly Yakovenko, co-fondateur de Solana

Au sein d'un validateur Solana, l'état global est maintenu dans la base de données des comptes connue sous le nom de AccountsDB. Cette base de données est responsable de stocker tous les comptes, à la fois en mémoire et sur disque. La structure de données principale dans l'index des comptes est une hashmap, ce qui fait d'AccountsDB essentiellement un vastemagasin de clés-valeurs. Ici, la clé est l'adresse du compte, et la valeur est les données du compte.

Au fil du temps, le nombre de comptes Solana a explosé pour atteindre des centaines de millions. Ce grand nombre est en partie dû au fait que, comme le disent souvent les développeurs de Solana, "Tout sur Solana est un compte !"

comptes Solana

Un compte est un conteneur qui détient de manière persistante des données, similaire à un fichier sur un ordinateur. Ils existent sous diverses formes :

• Comptes utilisateur : Ces comptes ont une clé privée et sont généralement générés par un logiciel de portefeuille pour un utilisateur.
• Comptes de données : Ces comptes stockent des informations d'état, telles que le nombre d'un jeton spécifique qu'un utilisateur détient.
• Comptes de programme : Il s'agit de comptes plus importants contenant du bytecode exécutable, quelque peu équivalent à un fichier .exe sur Windows ou à un fichier .app sur Mac.
• Comptes de programme natifs : Il s'agit de comptes de programme pré-déployés spéciaux qui exécutent diverses fonctionnalités principales du réseau. Exemplesinclure le programme Vote et le chargeur BPF.

Tous les comptes ont les champs suivants :

Programmes

Les comptes de programme Solana ne contiennent que de la logique exécutable. Cela signifie que lorsqu'un programme est exécuté, il mute l'état d'autres comptes mais reste inchangé lui-même. Cette séparation du code et de l'état différencie Solana des autres blockchains et prend en charge bon nombre de ses optimisations. Les développeurs écrivent principalement ces programmes en Rust, un langage de programmation généraliste.connupour son fort accent sur la sécurité et les performances. De plus, plusieurs SDK en TypeScript et Python sont 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 prêtes à l'emploi par des programmes natifs. Par exemple, Solana ne nécessite pas que les développeurs déploient du code pour créer un jeton. Au lieu de cela, des instructions sont envoyées à un programme natif pré-déployé qui mettra en place un compte pour stocker les métadonnées du jeton, créant ainsi un nouveau jeton de manière efficace.

Louer

Le loyer est un mécanisme conçu pour inciter les utilisateurs à fermer les comptes et à réduire l'encombrement de l'état. Pour créer un nouveau compte, un solde minimum de SOL, appelé montant "exempté de loyer", doit être détenu par le compte. Cela peut être considéré comme un coût de stockage engagé pour maintenir le compte en vie dans la mémoire d'un validateur. Si la taille des données du compte augmente, l'exigence de loyer du solde minimum augmente proportionnellement. Lorsqu'un compte n'est plus nécessaire, il peut être fermé et le loyer est retourné au propriétaire du compte.

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

Propriété

Bien que la lecture des données de compte soit universellement autorisée, le modèle de propriété de Solana renforce la sécurité en limitant précisément qui peut modifier (écrire) les données d'un compte. Ce concept est crucial pour faire respecter les règles et les autorisations sur la blockchain Solana. Chaque compte a un "propriétaire" de programme. Le propriétaire d'un compte est responsable de sa gestion, en veillant à ce que seuls les programmes autorisés puissent modifier les données du compte. Une exception notable à cette règle est le transfert de lamports (la plus petite unité de SOL) - l'augmentation du solde en lamports d'un compte est universellement autorisée, quelle que soit la propriété.

Stockage de l'état

Les programmes Solana, étant des fichiers exécutables en lecture seule, doivent stocker leur état à l'aide des "adresses dérivées du programme" (PDAs). Les PDAs sont des types spéciaux de comptes associés à un programme et appartenant à ce dernier plutôt qu'à un utilisateur spécifique. Alors que les adresses utilisateur normales de Solana sont dérivées de la clé publique d'une paire de clés Ed25519, les PDAs n'ont pas de clé privée. Leur clé publique est plutôt dérivée d'une combinaison de paramètres, souvent des mots-clés ou d'autres adresses de compte, ainsi que de l'ID de programme (adresse) du programme propriétaire.

Les adresses PDA existent en dehors de la courbe, ce qui signifie qu'elles ne sont pas sur la courbe Ed25519 comme les adresses normales. Seul le programme propriétaire du PDA peut générer des signatures de manière programmée pour celui-ci, garantissant qu'il est le seul à pouvoir modifier l'état du PDA.

Ci-dessus: les comptes de jetons Solana sont des exemples spécifiques d'adresses dérivées de programme (PDAs). Ils sont utilisés pour contenir des jetons et vivent “hors de la courbe.” Le programme de compte de jetons associé (ATA) garantit que chaque portefeuille ne peut avoir qu'un seul compte de jetons associé pour chaque type de jeton, offrant ainsi une manière standardisée de gérer les comptes de jetons.

Turbine

« La partie la plus intéressante de Solana n'est pas la parallélisation, le SVM, ou les tweets de Toly. C'est quelque chose dont vous n'avez probablement pas entendu parler : Turbine. » — Mert Mumtaz, Helius

Pendant la phase bancaire, les transactions sont organisées en entrées et envoyées au flux de Preuve d'Histoire pour l'horodatage. La banque du bloc est mise à jour, et les entrées sont maintenant prêtes pour la phase suivante - Turbine.

La turbine est le processus par lequel le leader propage son bloc au reste du réseau. Inspiré parBitTorrent, il est conçu pour être rapide et efficace, réduisant les frais de communication et minimisant la quantité de données qu'un leader doit envoyer.

Turbine y parvient en décomposant les données de transaction en « lambeaux » grâce à un processus appelé « déchiquetage ». Les déchiquets sont de petits paquets de données, jusqu’à 1280 octets, similaires aux images individuelles d’un flux vidéo. Lorsqu’ils sont réassemblés, ces lambeaux permettent aux validateurs de rejouer l’intégralité du bloc. Les lambeaux sont envoyés sur Internet entre les validateurs utilisant UDP et utilisent le codage d’effacement pour gérer la perte de paquets ou la perte malveillante de paquets.Codage d'effacement, unpolynôme-basé sur un schéma de détection et de correction d'erreurs, garantit l'intégrité des données. Même si certaines miettes sont perdues, le bloc peut toujours être reconstruit.

Les lambeaux sont regroupés en lots connus sous le nom de lots de correction d'erreurs avant (FEC). Par défaut, ces lots se composent de 64 lambeaux (32 lambeaux de données + 32 lambeaux de récupération). La récupération des données se produit par lot FEC, ce qui signifie que jusqu'à la moitié des paquets d'un lot peuvent être perdus ou corrompus, et toutes les données peuvent encore être récupérées. Chaque lot de 64 lambeaux est merkelisé avec la racine signée par le leader, et enchaîné au lot précédent. Ce processus garantit que les lambeaux peuvent être obtenus en toute sécurité à partir de n'importe quel nœud du réseau qui les possède, car la chaîne de racines de Merkle fournit un chemin vérifiable d'authenticité et d'intégrité.

Le leader diffuse initialement vers un seul nœud racine, qui dissémine les fragments à tous les autres nœuds de validation. Ce nœud racine change à chaque fragment. Les validateurs sont organisés en couches, formant l'“Arbre de la Turbine.” Les validateurs avec une plus grande quantité de mise sont généralement positionnés vers le haut de l'arbre, tandis que ceux avec des mises plus faibles sont placés vers le bas.

L'arbre s'étend généralement sur deux ou trois sauts, en fonction du nombre de validateurs actifs. Pour des raisons de simplicité visuelle, un éventail de 3 est représenté ci-dessus, mais la valeur effective de l'éventail de Solana est actuellement fixée à 200. Pour des raisons de sécurité, l'ordre de l'arbre est tourné pour chaque nouveau lot de fragments.

L'objectif principal d'un tel système est de soulager la pression de sortie des données sur les nœuds leader et racine. En utilisant un système de transmission et de retransmission, la charge est répartie entre le nœud leader et les retransmetteurs, réduisant la contrainte sur un nœud unique.

Consensus

"Certains gens intelligents me disent qu'il y a une communauté de développeurs intelligents sérieux sur Solana... J'espère que la communauté aura sa chance équitable de prospérer" — Vitalik Buterin, co-fondateur d'Ethereum

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

Ce processus est géré par l'Unité de validation des transactions (TVU), qui est analogue à l'Unité de traitement des transactions (TPU) du leader, servant de logique centrale responsable du traitement des fragments et de la validation des blocs. Comme le TPU, le flux TVU est divisé en plusieurs étapes, commençant par l'étape de récupération des fragments où les fragments sont reçus via Turbine. Dans l'étape suivante de vérification de la signature du leader des fragments, les fragments font l'objet de plusieurs vérifications de cohérence, notamment la vérification de la signature du leader, qui garantit que les fragments reçus proviennent du leader.

Dans la phase de retransmission, le validateur, en fonction de son emplacement dans l'arbre Turbine, transfère les fragments aux validateurs aval appropriés. Dans la phase de rejeu, le validateur recrée chaque transaction exactement et dans le bon ordre tout en mettant à jour sa version locale de la banque.

La scène de rejeu est analogue à la scène bancaire dans le TPU; c'est la scène la plus importante et peut être plus directement décrite comme la scène de validation de bloc. Le rejeu est une boucle de processus à un seul thread qui orchestre de nombreuses opérations clés, y compris le vote, la réinitialisation de l'horloge PoH et le changement de banques.

Ci-dessus : la scène de rejeu est responsable de basculer le validateur en mode leader et de commencer la production de blocs. Visuel original : Justin Starry, Anza

Consensus

Pour parvenir à un consensus, Solana utilise Tower BFT (TBFT), une implémentation personnalisée du célèbre PracticalByzantine FaultL'algorithme de tolérance aux pannes byzantines (PBFT), couramment utilisé 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 dans le réseau, de sorte que le système doit non seulement résister aux défaillances des nœuds, mais aussi à certains niveaux d'attaques.

Tower BFT se différencie des autres chaînes en tirant parti de l'horloge synchronisée fournie par la Preuve de l'Histoire. Alors que le PBFT traditionnel nécessite plusieurs rounds de communication pour se mettre d'accord sur l'ordre des transactions, les nœuds Solana utilisent l'ordre préétabli des événements, réduisant ainsi considérablement la surcharge de messages.

Vote

Pour participer au consensus et gagner des récompenses, les validateurs soumettent des votes 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. Les validateurs paient des frais de transaction pour ces votes, qui sont traités par le leader et inclus dans un bloc avec les transactions régulières des utilisateurs. C'est pourquoi les transactions Solana sont souvent catégorisées en transactions de vote et non de vote. Lorsque les validateurs soumettent un vote correct et réussi, ils gagnent un crédit. Ce mécanisme incite les validateurs à voter pour la branche qu'ils estiment avoir la meilleure chance d'être incluse, c'est-à-dire la branche la plus “pesante”.

Fourches

Une partie de la conception de Solana, qui le rend si rapide, est que le réseau n'attend pas que tous les validateurs soient d'accord sur un nouveau bloc produit avant de produire le suivant. Par conséquent, il n'est pas rare que deux blocs différents soient liés au même bloc parent, créant des fourches.

Les validateurs de Solana doivent voter sur ces forks et utiliser un algorithme de consensus pour déterminer lequel adopter. Lorsque des forks concurrents existent, un seul fork sera finalement finalisé par le réseau, tandis que les blocs des forks abandonnés sont abandonnés.

Chaque créneau a un leader prédéterminé pour lequel seul le bloc de ce leader sera accepté ; il ne peut pas y avoir deux blocs proposés pour un seul créneau. Par conséquent, le nombre de fourchettes potentielles est limité à une liste de sauts "là/pas là" de fourchettes qui peuvent émerger aux limites des créneaux de rotation des leaders. Une fois qu'un validateur choisit une fourchette, il s'engage à cette fourchette jusqu'à ce qu'un temps d'exclusion expire, ce qui signifie qu'il doit rester fidèle à son choix pendant une période minimale.

Le taux de saut de Solana - le pourcentage de créneaux dans lesquels un bloc n'a pas été produit - varie de 2% à 10%, les fourchettes étant la principale raison de ces créneaux sautés. D'autres raisons possibles pour les créneaux sautés incluent le début d'une nouvelle époque, un leader hors ligne, ou la production d'un bloc invalide.

Rappeler

Le statut d'une transaction sur Solana varie en fonction de son stade actuel dans le processus de consensus :

• Traité : la transaction a été incluse dans un bloc.

• Confirmé : Le bloc de la transaction a été voté par une majorité qualifiée des deux tiers.

• Finalisé : Plus de 31 blocs ont été construits au-dessus du bloc de la transaction.

À ce jour, il n'y a jamais eu de cas dans l'histoire de Solana où un bloc confirmé (de manière optimiste) n'est pas devenu finalisé.

Pour chaque bloc, Solana utilise une banque pour accéder à l'état de ce bloc. Lorsqu'une banque est finalisée, les mises à jour des comptes de cette banque et de ses ancêtres sont écrites sur le disque. De plus, toutes les mises à jour des comptes des banques antérieures qui ne sont pas des ancêtres de la banque finalisée sont élaguées. Ce processus permet à Solana de maintenir efficacement plusieurs états potentiels.

Gossip + Archive

«Une blockchain nécessite une combinaison astucieuse de cryptographie, de systèmes distribués, de systèmes d'exploitation et de langages de programmation. La superpuissance de Solana était la volonté de fuir en hurlant face aux problèmes les plus intéressants de chaque discipline.» — Greg Fitzgerald, co-fondateur de Solana

Potins

Le réseau de ragots peut être considéré comme leplan de contrôlepour le 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 cruciales sur l'état de la blockchain, telles que les informations de contact, la hauteur du grand livre et les informations de vote. Sans le gossip, les validateurs et les RPC ne sauraient pas quelles adresses et quels ports sont ouverts pour la communication entre divers services. Les nouveaux nœuds dépendent également du gossip pour rejoindre le réseau.

Le protocole de commérage de Solana utilise une communication informelle de pair à pair avec une approche de diffusion en arborescence inspirée par un algorithme PlumTree modifié. Cette méthode propage efficacement les informations sans dépendre d'une source centrale.

Les potins fonctionnent quelque peu comme un système isolé, indépendant de la plupart des autres composants du validateur. Les validateurs et les RPC partagent des objets de données signés toutes les 0,1 secondes via UDP via les potins, assurant la disponibilité des informations à travers le réseau. Tous les messages de potins doivent être inférieurs ou égaux à l'unité de transmission maximale (MTU) de 1280 octets, appelée le «packet struct» dans le code source.

Les enregistrements de potins sont les objets de données réels partagés entre les nœuds. Il existe environ 10 types différents d'enregistrements, chacun servant à des fins différentes. Les enregistrements de potins sont signés, versionnés et horodatés pour garantir l'intégrité et la devise.

Il existe quatre types de messages de commérages:

• Pousser : Les messages les plus courants, partageant des informations avec un sous-ensemble de « pairs de poussée ».
• Tirer & Réponse au tir: Vérifie périodiquement les messages manqués, avec les réponses au tir renvoyant les informations que les nœuds n'ont pas.
• Élaguer : Permet aux nœuds de réduire sélectivement le nombre de connexions qu'ils maintiennent.
• Ping & Pong: Vérifications de santé pour les nœuds - si un ping est envoyé, un pong est attendu en retour, indiquant que le nœud pair est toujours actif.

Les données de commérages sont stockées dans un magasin de données répliqué en grappe (CrdsTable). Cette structure de données peut devenir très volumineuse et doit être périodiquement élaguée.

Archive

Solana se distingue des autres blockchains en ne nécessitant pas l'ensemble de l'historique pour déterminer l'état actuel d'un compte. Le modèle de compte de Solana garantit que l'état à n'importe quel slot donné est connu, permettant aux validateurs de stocker l'état actuel de chaque compte sans traiter tous les blocs historiques. Les RPC et les validateurs, par conception, ne conservent pas l'ensemble du grand livre historique. Au lieu de cela, ils stockent généralement seulement 1 ou 2 époques (2-4 jours) de données de transaction, ce qui est suffisant pour valider le sommet de la chaîne.

Les archives sont actuellement gérées par des « nœuds d'entrepôt », exploités par des fournisseurs de services RPC professionnels, la Fondation Solana et d'autres participants de l'écosystème intéressés à garantir que l'historique des transactions est disponible. Les nœuds d'entrepôt maintiennent généralement l'un ou l'autre des éléments suivants :

1. Archive Ledger : télécharge des instantanés bruts du grand livre et de la base de données des comptes adaptés pour être rejoués à partir de zéro.

2. Instance Google Bigtable : Stocke les données de bloc à partir du bloc genesis, formatées pour répondre aux demandes RPC.

Economics + Jito

Les gens réalisent que Solana est la seule chaîne disponible aujourd'hui qui soutiendra les applications grand public. - Ted Livingston, fondateur Code

Solana utilise l'inflation pour distribuer les récompenses de jalonnement en générant de nouveaux jetons SOL à chaque époque. Ce processus entraîne une diminution de la part du réseau des non-jalonneurs par rapport aux jalonneurs, ce qui conduit à un transfert de richesse des non-jalonneurs aux jalonneurs. L'inflation a commencé au début de 2021 à un taux initial de 8 %, qui diminue de 15 % par an jusqu'à ce qu'elle se stabilise à un taux à long terme de 1,5 %.

Tout détenteur de jeton SOL peut gagner des récompenses et aider à sécuriser le réseau en misant des jetons sur un ou plusieurs validateurs. L'attribution de jetons à un validateur est appelée délégation. Déléguer des jetons à un validateur indique une confiance envers celui-ci. Cependant, cela ne donne pas au validateur la propriété ou le contrôle des jetons. Toutes les actions de mise en jeu, de retrait et de délégation sont exécutées au début de la prochaine nouvelle époque.

‍

Récompenses de vote

Lorsqu'un validateur soumet un vote, il gagne un crédit si le vote est précis et réussi. Les transactions de vote coûtent 0,000005 SOL et sont exemptes de frais de priorité. Les dépenses liées au vote s'élèvent à environ 1 SOL par jour et par validateur, ce qui en fait le coût opérationnel principal de l'exploitation d'un validateur. Tout au long d'une époque, les validateurs accumulent des crédits de vote, qu'ils peuvent échanger contre une part de l'inflation à la fin de l'époque.

Les validateurs les plus performants votent avec succès sur environ 90 % des créneaux horaires. Notez que le pourcentage de créneaux horaires sans blocs (taux de créneaux horaires sautés) varie de 2 % à plus de 10 % et que ces créneaux horaires ne peuvent pas être votés. En moyenne, le validateur vote avec succès sur environ 80 % des créneaux horaires, gagnant 345 600 crédits dans une époque de 432 000 créneaux horaires.

Le pot total d'inflation est d'abord divisé en fonction des crédits gagnés pour l'époque. La part d'un validateur des crédits totaux (leurs crédits divisés par la somme de tous les crédits des validateurs) détermine leur récompense proportionnelle. Cela est ensuite pondéré par la participation.

Par conséquent, un validateur possédant 1 % de l'enjeu total devrait gagner environ 1 % de l'inflation totale s'ils ont un nombre moyen de crédits. S'ils ont un nombre de crédits supérieur ou inférieur à la moyenne, leurs récompenses fluctueront en conséquence.

Les différences de performance en matière de vote sont une des raisons pour lesquelles les rendements (mesurés en APY) offerts aux déposants varient. Un autre facteur est le taux de commission facturé par les validateurs, qui est un pourcentage des récompenses totales d'inflation dirigées vers leur validateur. De plus, le fait qu'un validateur soit hors ligne ou désynchronisé par rapport à la blockchain (connu sous le nom de négligence) impacte significativement les rendements.

Récompenses de bloc

Les validateurs désignés comme le leader pour un bloc spécifique 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 dans le bloc, les frais restants étant brûlés. Seul le validateur qui a produit le bloc reçoit ces récompenses. Contrairement aux récompenses de mise, qui sont distribuées par époque, les récompenses de bloc sont instantanément créditées sur le compte d'identité du validateur lorsque le bloc est produit.

Liquid staking

Le staking liquide est devenu une alternative populaire au staking natif. Les participants reçoivent un jeton, appelé jeton de staking liquide (LST) ou dérivé de staking liquide (LSD), en échange de leur SOL mis en jeu, généralement dans un pool de mise qui délègue leurs jetons à plusieurs validateurs. Les jetons LST nouvellement reçus représentent la part de SOL mis en jeu de l'utilisateur. Ces jetons peuvent être échangés, utilisés dans des applications ou transférés à d'autres tout en continuant à gagner des récompenses de staking. L'avantage majeur de ce système est qu'il améliore significativement l'efficacité du capital.

Prix du LST = (SOL total misé dans le pool * prix du SOL) / total LST émis

Avec le jalonnement natif traditionnel, au fil du temps, le staker accumulera directement plus de SOL. Alors qu'avec le jalonnement liquide, les récompenses sont réinvesties dans le pool augmentant la juste valeur du LST. Tant qu'il existe un mécanisme pour échanger les LST contre les SOL mis en jeu sous-jacents, les traders d'arbitrage veilleront à ce que le prix du token reste rationnel.

Jito

Au moment de l'écriture, plus de 80% (source) de l'enjeu sur Solana utilise le logiciel de validation client Jito. Ce client, un fork du client Agave d'origine, introduit une vente aux enchères de l'espace de blocs en dehors du protocole qui fournit aux validateurs des incitations économiques supplémentaires sous forme de pourboires. Cet incitatif supplémentaire est un facteur majeur dans l'adoption généralisée du client Jito parmi les validateurs.

Lorsque les leaders utilisent le client validateur Jito, leurs transactions sont initialement dirigées vers le Jito-Relayer. Ce logiciel open-source fonctionne comme un routeur proxy de transaction. Les autres nœuds du réseau restent inconscients de l'existence du Jito-Relayer, car ils envoient simplement des transactions à l'adresse et au port configurés que le leader a annoncés sur le réseau de diffusion comme leur ingress_socket, en supposant qu'il s'agit du leader.

Le relais retient toutes les transactions pendant 200 millisecondes avant de les transmettre au leader. Ce mécanisme de "ralentisseur" retarde les messages de transaction entrants, offrant une courte période pour la tenue d'enchères. Après 200 millisecondes, le relais libère de manière optimiste les transactions indépendamment des résultats des enchères.

Les enchères d'espace de bloc se déroulent hors chaîne via le moteur de bloc Jito, permettant aux chercheurs et aux applications de soumettre des groupes de transactions exécutées de manière atomique appelées bundles. Ces bundles contiennent généralement des transactions sensibles au temps telles que des arbitrages ou des liquidations. Jito facture des frais de 5% sur tous les pourboires, avec un pourboire minimum de 10 000 lamports. Les pourboires fonctionnent entièrement en dehors du protocole, séparément des frais de priorité et de base du protocole. Auparavant, Jito exploitait un service de mémoire tampon memp-pool canonique hors protocole, qui a maintenant été obsolète.

Avertissement：

1. Cet article est repris de [helius]. Tous les droits d'auteur appartiennent à l'auteur original [Lostin]. If there are objections to this reprint, please contact the Apprendre Gateéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.