Auteur : Pavel Paramonov Source : X, @paramonoww Traduction : Jinse Finance

Au cours des six derniers mois, j'ai lu d'innombrables articles et documents sur la conception et l'architecture du mécanisme Solana. J'ai résumé les informations les plus importantes dans un long article. Le contenu couvre des sujets tels que la conception du mécanisme, le marché des frais, le MEV, etc.

Voici les réponses à toutes les questions:

Le modèle de consensus de Solana :

‣ Le modèle de consensus de Solana, Preuve de l'historique (Proof of History, PoH), est essentiellement un mélange de "Preuve d'enjeu (Proof of Stake) + variable temporelle".

‣ PoH est essentiellement l'horloge du réseau, utilisée pour suivre les événements et leur ordre (temps nécessaire pour parvenir à un consensus sans validateurs).

‣ Solana n'a pas de pool de mémoire (mempool).

Actuellement, la plupart des validateurs utilisent le planificateur dans le client Solana fourni par @solanalabs. Cependant, les validateurs peuvent également choisir d'exécuter un algorithme de construction de blocs différent.

‣ Les variables de temps permettent d'attribuer un leader à chaque rotation, qui sera responsable de la production de blocs.

Mécanisme détaillé :

• Lorsqu'un validateur est sélectionné en tant que leader, il est responsable de la production de nouveaux blocs et de leur proposition au réseau.
• Le leadership tourne à intervalles réguliers (appelés fentes, slots) entre les validateurs.
• Chaque créneau dure 400 millisecondes, pendant cette période, les validateurs peuvent générer un Bloc. Les créneaux sont traités les uns après les autres dans l'ordre.
• Chaque fente est assignée à un validateur leader, qui propose un nouveau bloc, les autres validateurs votent pour la validité du bloc, et le bloc est finalement confirmé.
• Si les validateurs manquent le créneau qui leur a été attribué, le réseau passera au créneau suivant.

Caractéristiques et processus：

• Solana utilise un mécanisme de vote basé sur la fork, plutôt qu'un vote par bloc individuel. Les validateurs génèrent en continu des blocs et ajoutent en temps réel les votes valides.
• Les validateurs et les délégués peuvent stake ou retirer leur stake de SOL Jeton au cours d'un cycle (epoch).
• En fonction du nombre de SOL pris dans le pieu, la participation des validateurs au processus de Consensus sera déterminée en début de cycle.

Modèle de mise en jeu de Solana :

‣ Solana traite les mises à jour de stake à la fin de chaque époque (epoch), chaque époque dure environ 2 à 3 jours et est composée de 432 000 Bloc (slots).

‣ Le prochain tableau de validation du cycle est déterminé en fonction des informations de mise à jour de stake.

Les trois principales sources de revenus de validateurs sont :

• Frais de transaction
• récompenses de protocole (inflation)
• valeur extractible maximale（MEV）

‣ Les récompenses de Bloc reçues par les leaders comprennent 50% des frais de base et des frais de priorité (les 50% restants sont détruits).

‣ Une durée de bloc plus longue pourrait réduire les récompenses annuelles en raison de la diminution du nombre de cycles, ce qui affecte la répartition globale de $SOL.

‣ Solana calcule un pool de récompenses SOL générées par l'inflation pour chaque cycle et distribue les récompenses aux validateurs et aux stakers en fonction des votes et de l'état de mise en jeu du cycle précédent.

Modèle de mise en jeu de Solana :

‣ Solana traite les mises à jour de stake à la fin de chaque époque (epoch), chaque époque dure environ 2 à 3 jours et est composée de 432 000 Bloc (slots).

‣ Le prochain tableau de validation du cycle est déterminé en fonction des informations de mise à jour de stake.

Les trois principales sources de revenus de validateurs sont :

• Frais de transaction
• récompenses de protocole (inflation)
• valeur extractible maximale（MEV）

‣ Les récompenses de Bloc reçues par les leaders comprennent 50% des frais de base et des frais de priorité (les 50% restants sont détruits).

‣ Une durée de bloc plus longue pourrait réduire les récompenses annuelles en raison de la diminution du nombre de cycles, ce qui affecte la répartition globale de $SOL.

‣ Solana calcule un pool de récompenses SOL générées par l'inflation pour chaque cycle et distribue les récompenses aux validateurs et aux stakers en fonction des votes et de l'état de mise en jeu du cycle précédent.

Modèle de vote Solana :

‣ Solana 对validateurs没有严格的最低 SOL 要求，但参与Consensus需要一个投票compte。

‣ Les validateurs votent sur les propositions des chefs de fente, ce qui nécessite un compte de vote et le paiement de Blanchiment de capitaux à chaque vote.

Le mécanisme de vote hors chaîne de Solana facture Blanchiment de capitaux à chaque fois qu'un vote est effectué. Le coût de fonctionnement des validateurs augmentera en raison des frais de transaction plus élevés associés à une valeur $SOL plus élevée.

Détails des frais :

• Le coût de chaque vote est de 0,000005 SOL, les validateurs dépensent environ 2 à 3 SOL pour voter à chaque cycle.
• Un cycle dure 2 à 3 jours et coûte environ 300 à 350 SOL par an, soit environ 1 SOL par jour.

Le marché des frais de Solana :

‣ Le mécanisme de frais de Solana comprend deux parties : les frais de base et les frais prioritaires.

‣ Les frais sont répartis entre les validateurs et une partie est détruite, mais le mécanisme actuel présente certaines limitations:

• Il n'a pas réussi à stimuler une utilisation efficace des ressources ou à aligner les incitations de toutes les parties.

‣ La création d'un nouveau compte nécessite le paiement de frais (frais de location exonérés).

• Les frais sont calculés selon un taux fixe, vous devrez payer 6,96 SOL par Mo de stockage.
• Les frais sont répartis dans le compte nouvellement créé, et peuvent être récupérés si le compte est supprimé.

Limitations:

ce qui entraîne un gaspillage des ressources Ils ne sont efficaces que lors des embouteillages incitations insuffisantes (subvention dépendante de l'inflation)

Qualité de service basée sur le poids de mise (SWQoS) :

‣ Le mécanisme SWQoS peut être utilisé pour donner la priorité au traitement de certains types de transactions en cas de congestion du réseau.

‣ SWQoS traite en priorité le trafic réseau en fonction de la quantité de stake des validateurs, afin d'éviter que les validateurs à faible stake ne submergent le réseau avec des transactions de spam.

Type de connexion :

• Connexion ouverte : utilisation publique
• Connexion basée sur le poids de stake : réservée à une utilisation par les validateurs, les nœuds RPC peuvent se connecter aux validateurs via des relations de confiance.

Avantages:

• Améliorer les performances des transactions avec des validateurs de mise en jeu
• Renforcer la résilience du réseau
• Améliorer la résistance aux attaques Sybil

Défi :

• Risque de centralisation de stake
• Problème de confiance entre les validateurs et les nœuds RPC
• Barrières à l'entrée des validateurs de petite taille

‣ SWQoS prioritise l'accès au réseau plutôt que l'ordre des transactions prioritaire en termes de coût

À propos de Nœud et de validateurs :

‣ Tous les validateurs sont des Nœud, mais tous les Nœud ne sont pas des validateurs.

‣ Type de nœud :

• VérificationNœud：负责签名和投票
• RPC Nœud：处理Portefeuille和 DEX 请求

‣ Le compte de trading sera spécifié comme compte：

• Les transactions affectant le même compte sont traitées dans l'ordre ;
• Les transactions affectent les comptes différents可顺序或并行处理。

Liquid Staking de Solana :

‣ Solana adopte le mécanisme de preuve d'enjeu déléguée (DPoS).

‣ Les utilisateurs peuvent stake SOL dans le pool de validateurs et obtenir LST (Jeton de stake liquide).

‣ Les récompenses de mise en jeu rivalisent directement avec les revenus de prêt :

• Si les revenus du prêt sont supérieurs aux récompenses de stake, les validateurs peuvent retirer des fonds, ce qui pourrait avoir un impact sur la sécurité du réseau.

Deux types de Jeton LST :

1. Jeton de récompense ou Jeton de base à nouveau.

• L'utilisateur stake 10 SOL dans le pool de stake et reçoit 10 Jetons LST.
• Le pool de staking répartit ces SOL entre plusieurs validateurs pour obtenir des vSOL.
• Ces vSOL représentent les récompenses de mise des validateurs.
• LST Jeton est soutenu par ces vSOL.

• validateurs LST Jeton（专属Jeton）。

• L'utilisateur stake 10 SOL sur les validateurs LST et reçoit des jetons v_lstSOL, représentant ses droits de participation au stake SOL.
• Les validateurs stake le SOL dans le pool de stake sur le réseau Solana pour obtenir du sSOL.
• Ces sSOL représentent les validateurs qui font staker SOL et bénéficier des récompenses associées.

MEV de Solana：

‣ Les leaders actuels du Bloc ont un contrôle total sur la production et la planification du Bloc.

‣ Les leaders sont encouragés à traiter les transactions en priorité, mais cela n'est pas obligatoire.

‣ L'impact négatif de MEV sur Solana :

• Plus de 50% des ressources de calcul sont gaspillées dans des tentatives d'arbitrage infructueuses.

‣ Solana n'a pas de pool de mémoire public (mempool), les transactions sont directement transmises au leader actuel et au prochain.

La différence entre Ethereum MEV et Solana MEV :

Mode de production Bloc :

• Les validateurs par défaut de Solana continuent de produire des Bloc, traitant et incluant les transactions de manière fluide.
• Ethereum traite les transactions par lots de 12 secondes.

L'impact de MEV :

• ETH坊：

• frais du réseau高
• Réduction de l'espace Bloc
• Les utilisateurs sont pris en sandwich et s'enfuient

• Solana :

• Les chercheurs tentent de s'infiltrer dans les transactions par des transactions de spam.
• Les transactions échouées gaspillent des ressources de calcul.
• Les quelques chercheurs obtiennent la majorité des bénéfices.