Qu'est-ce que la qualité de service pondérée par le stake (QoS) ?
La QoS (qualité de service) pondérée par le stake est une fonctionnalité d'implémentation qui, lorsqu'elle est activée, permet aux leaders (producteurs de blocs) d'identifier et de prioriser les transactions acheminées via un validator staké, en tant que mécanisme supplémentaire de résistance aux attaques sybil. Étant donné que Solana est un réseau de preuve d'enjeu, il est naturel d'étendre l'utilité de la pondération par le stake à la qualité de service des transactions. Dans ce modèle, un validator détenant 0,5 % du stake aurait le droit de transmettre jusqu'à 0,5 % des paquets au leader et serait capable de résister aux attaques sybil provenant du reste du réseau.
Les opérateurs qui activent cette fonctionnalité amélioreront la sécurité et les performances du réseau en réduisant la probabilité que les validators à faible stake ou sans stake (de moindre qualité) soient en mesure de « noyer » les transactions émanant de validators de meilleure qualité (à stake plus élevé) (autrement dit, une résistance sybil renforcée).
Un avantage potentiel de la mise en œuvre de la QoS pondérée par le stake pourrait se concrétiser si certains accords entre les Validators et les nœuds RPC sont en place. Les nœuds RPC pourraient inclure davantage de transactions dans les blocs en acceptant de se connecter en pair avec des Validators, et les Validators pourraient vendre davantage de capacité aux nœuds RPC. Ces accords doivent être conclus directement entre les opérateurs RPC et les Validators, et comprennent la mise en œuvre des étapes décrites ci-dessous dans ce document pour finaliser le peering.
À qui profite la QoS pondérée par le stake ?
Les opérateurs d'infrastructure RPC commerciale et les plateformes d'échange figureront probablement parmi les principaux bénéficiaires de la QoS pondérée par le stake. Les opérateurs RPC seront en position idéale pour acquérir ou négocier des accords avec des validators stakés, leur permettant d'améliorer le pourcentage global de transactions incluses dans les blocs. Les plateformes d'échange (ou autres entités) qui hébergent leurs propres nœuds validator et nœuds RPC sur la même infrastructure pourront activer la fonctionnalité en interne, avec la certitude que les nœuds RPC fonctionnant sur leur propre infrastructure sont dignes de confiance.
Pourquoi la QoS pondérée par le stake est-elle importante ?
Avec la QoS pondérée par le stake activée, un validator détenant 1 % du stake aura le droit de transmettre jusqu'à 1 % des paquets au leader. Ainsi, les validators ayant un stake plus élevé bénéficient d'une qualité de service garantie supérieure, ce qui empêche les validators de moindre qualité (avec moins de stake) d'inonder malicieusement ces transactions, augmentant ainsi la résistance globale aux attaques sybil.
Autrement dit, imaginez ce que serait le monde si des voitures avec un seul passager pouvaient circuler librement dans la voie de covoiturage. Cette voie, conçue pour faire circuler davantage de personnes sur le même tronçon d'autoroute, deviendrait rapidement inutile. Le fonctionnement global de l'autoroute serait perturbé et moins de conducteurs pourraient atteindre leur destination. Cet effet est similaire à ce qui se produit lorsque des validators à faible stake sont autorisés à soumettre des transactions au Leader avec la même priorité que des validators à stake élevé.
Qui devrait activer la QoS pondérée par le stake ?
La QoS pondérée par le stake devrait être activée par les nœuds Validator associés à des nœuds RPC hautement fiables. Cela est particulièrement utile dans des situations telles que l'exploitation d'un RPC et d'un Validator sur la même infrastructure, où le niveau de confiance est déjà élevé. La QoS pondérée par le stake fonctionne mieux dans des configurations à haute confiance et nécessite que le Validator et le RPC parviennent à un accord au préalable avant d'activer la fonctionnalité. Il est fortement recommandé que les Validators n'essaient pas d'activer la QoS pondérée par le stake avec des RPC non fiables.
Le stake doit être appliqué aux validators producteurs de blocs. Il n'est ni nécessaire, ni recommandé, ni efficace de déléguer du stake à des serveurs RPC.
Comment fonctionne la QoS pondérée par le stake ?
Avec la QoS pondérée par le stake activée, les nœuds RPC associés à un validator acquièrent un stake « virtuel » concernant la manière dont ce leader traite le trafic TPU (Transaction Processing Unit) entrant provenant de ce nœud RPC, ce qui n'est normalement pas possible. Par définition, les nœuds RPC sont « non stakés » et « non votants », c'est-à-dire « hors consensus », et ne peuvent pas accéder aux avantages des transactions prioritaires via le staking de la même manière que le font les nœuds de consensus. Comment utiliser la QoS pondérée par le stake pour inclure des transactions ? L'activation de la QoS pondérée par le stake nécessite de configurer un nœud validator et un nœud RPC pour former une relation de pair de confiance. Cela implique des étapes de configuration distinctes pour le nœud validator et le nœud RPC, décrites ci-dessous. Les opérateurs souhaitant activer la QoS pondérée par le stake auront besoin des éléments suivants avant de commencer :
Un validator avec du stake actif sur le réseau ET un RPC associé en pair au validator
La QoS pondérée par le stake ne fonctionnera pas si les DEUX côtés ne sont pas correctement configurés.
Configuration du nœud Validator
Sur le validator, vous devrez activer
--staked-nodes-overrides /path/to/overrides.yml. Le flag
--staked-nodes-overrides aide le validator à prioriser les transactions
envoyées depuis des sources connues afin d'appliquer du stake à leurs transactions. Cela peut
aider un validator à prioriser certaines transactions provenant d'hôtes connus par rapport à d'autres,
permettant l'utilisation de la QoS pondérée par le stake avec des RPC. Les RPC ne doivent en aucun cas être stakés.
Aujourd'hui, la QoS pondérée par le stake attribue une priorité pondérée par le stake à 80 % de la capacité TPU d'un leader. Cependant, des options de configuration permettent d'assigner virtuellement différents poids de stake aux pairs TPU, y compris l'attribution d'un stake virtuel aux pairs non stakés.
Le fichier d'overrides pour --staked-nodes-overrides se présente comme suit :
staked_map_id:pubkey1: 1000000000000000pubkey2: 4000000000000000
staked_map_id contient une correspondance entre la clé publique d'identité et le montant du stake en
lamports à appliquer à chaque RPC. Lorsqu'il est défini, le validator priorisera les connexions QUIC
avec le RPC trouvé à cette publicKey d'identité, en assignant un montant
de stake à leurs transactions. Les 80 % de la capacité TPU du leader seront
répartis proportionnellement en fonction des montants en lamports spécifiés dans le fichier
staked-nodes-overrides et du stake existant du cluster.
Configuration du nœud RPC
Sur le RPC, vous devrez utiliser --rpc-send-transaction-tpu-peer pour transférer
les transactions vers un leader spécifique. L'utilisation exacte serait
--rpc-send-transaction-tpu-peer HOST:PORT. L'hôte est l'adresse IP du
leader sur lequel staked-nodes-overrides est activé, et le port est le port QUIC
TPU de cet hôte. Le port QUIC TPU d'un leader peut être identifié en
effectuant un appel RPC à getClusterNodes.
Le peering se présenterait comme suit :
Diagramme des RPC en peering avec le Validator pour la QoS pondérée par le stake
Conclusion
La QoS pondérée par le stake est une fonctionnalité optionnelle introduite dans la version v1.14 du client Solana, désormais connu sous le nom d'Agave. Agave est une version dérivée du client Solana Labs qui est devenue la branche active utilisée par l'équipe Anza, une organisation issue de l'ancienne équipe d'ingénierie de Solana Labs.
La fonctionnalité de QoS pondérée par le stake sera très probablement utile aux opérateurs d'infrastructure RPC qui sont en mesure d'établir des relations de confiance avec des opérateurs de nœuds stakés. Elle sera également utile aux plateformes d'échange, qui exploitent à la fois des nœuds RPC et des nœuds validator, et sont en mesure d'établir des connexions à haute confiance en interne.
Is this page helpful?