|
Getting your Trinity Audio player ready...
|
Dernière modification effectuée le 17.08.2023 05:37
Souvent critiqué pour ses pannes à répétitions et ses performances bien en dessous des attentes, le réseau Solana continue de travailler d'arrache-pied avec des objectifs toujours aussi ambitieux. Dans cette optique, Solana a appliqué 3 changements principaux à son réseau afin d'assurer sa stabilité et sa résilience. Revenons ensemble sur ces 3 nouveautés en détail dans cet article.
Ces mesures visent le trafic intense responsable des différentes pannes du réseau Solana.
Bien que les changements proposés par les développeurs de Solana soient considérés comme abstraits ou profondément techniques pour la partie générale de la communauté, les concepts ne sont pas complètement nouveaux, étant importés d'autres systèmes déjà matures. Dans cet article, nous allons essayer de décomposer les aspects techniques et de les expliquer en termes simples.
Disclaimer : cet article a été initialement publié en anglais par Thalita @ethalita_ sur Medium pour l'entreprise Chorus One. Chorus One est une entreprise spécialisée dans les infrastructures de sécurisation de réseaux blockchains en Proof of Stake. Nous avons obtenu l'accord de Thalita pour la publication de cet article, car nous pensons qu'il peut être intéressant de comprendre ce qui est fait au niveau du protocole Solana pour que le réseau ne subisse plus de panne dans le futur.
Article original : 3 Major Upcoming Upgrades on Solana That Will Improve Network Performance
L'article original a été posté le 15 juin 2022, depuis cette date, 2 des 3 mises à jour pour ajouter ces fonctionnalités ont été effectuées sur le réseau respectivement :
1. Intégration du protocole QUIC : le protocole QUIC est à présent le protocole par défaut sur Solana depuis le 19 septembre 2022. Vous pouvez retrouver la release sur Github ici.
2. Intégration du QoS : maintenant que le protocole QUIC a été intégré au réseau de validateurs sur Solana, l'équipe de Solana va pouvoir se concentrer sur l'intégration du QoS, c'est la seule des 3 fonctionnalités qui n'a pas encore été totalement implémentée.
3. Amélioration du système de frais : le nouveau système de frais a été intégré fin juin 2022, il est possible d'analyser en détail les données de ce nouveau modèle de frais sur DuneAnalitycs ici. Vous pouvez également utiliser le fee tracker du block explorer Solscan.
Solana avait l'habitude d'adopter le protocole UDP (User Datagram Protocol) pour transmettre les transactions entre les nœuds du réseau. Les nœuds envoient les transactions par UDP directement au leader (le nœud validateur responsable de la proposition du bloc dans un slot particulier) sans qu'une connexion préalable soit établie.
UDP ne gère pas la congestion du trafic ni la confirmation de la livraison des données. En cas d'encombrement du réseau, le leader n'est pas en mesure de gérer le volume du trafic entrant, ce qui signifie que certains paquets sont abandonnés. Même en période de calme, un certain niveau de perte de paquets est normal. En envoyant plusieurs fois la même transaction, les utilisateurs ont plus de chances qu'au moins une de leurs tentatives arrive.
Fig. 1 : Illustration du protocole UDP, qui présente de multiples transferts de données susceptibles de surcharger le récepteur et de perdre des paquets en cours de route.
À l'opposé d'UDP se trouve le protocole de contrôle de transmission (TCP). Le protocole TCP comprend des fonctionnalités plus sophistiquées mais pour qu'il fonctionne, il faut une session (c'est-à-dire qu'une connexion connue a été établie au préalable entre le client et le serveur).
Le récepteur accuse réception (“acks”) des paquets et l'expéditeur sait quand arrêter d'envoyer des paquets en cas de trafic intense. Le TCP permet de retransmettre les paquets perdus. Lorsque l'expéditeur cesse de recevoir des accusés de réception (acks), l'interprétation est que quelque chose a été perdu et que l'expéditeur doit ralentir.
Le protocole TCP n'est cependant pas idéal pour certains cas d'utilisation. En particulier, il séquence tout le trafic. Si une partie des données est perdue, tout ce qui suit doit attendre. Ce n'est pas idéal pour les transactions Solana, qui sont indépendantes.
Fig. 2 : Illustration du protocole TCP, avec transfert de données en série. Les paquets perdus affectent les paquets suivants puisque l'expéditeur attend l'accusé de réception du serveur.
QUIC est un protocole polyvalent qui est utilisé par plus de la moitié des connexions du navigateur Web Chrome aux serveurs de Google. QUIC est le nom du protocole et non un acronyme.
QUIC est une alternative au TCP avec des caractéristiques similaires : une session, qui permet ensuite la rétropression pour ralentir l'expéditeur, mais il a également un concept de flux séparés ; ainsi, si une transaction est abandonnée, il n'est pas nécessaire de bloquer les autres.
Fig. 3 : Illustration du protocole QUIC, représentant un mélange de caractéristiques de TCP et UDP.
Solana est un réseau sans permission. Toute personne exécutant un client Solana est un “nœud” dans le réseau et est capable d'envoyer des messages au leader. Les nœuds peuvent fonctionner comme des validateurs lorsqu'ils signent et envoient des votes et ils peuvent exposer leur interface RPC (Remote Procedure Call) pour recevoir des messages d'applications telles que des portefeuilles et des DEX et les envoyer au leader.
Le leader (validateur du bloc) écoute sur un port UDP et les RPCs écoutent sur un port TCP.
Étant donné que l'horaire du leader est public, les joueurs sophistiqués ayant des stratégies algorithmiques (bots) sont en mesure d'envoyer des transactions au leader directement, en contournant tout nœud RPC supplémentaire qui ne ferait qu'augmenter la latence.
Lorsque le leader est beaucoup sollicité, le réseau est encombré, ce qui détériore les performances. Sur Solana, le port UDP utilisé par le leader va être remplacé par un port QUIC.
La qualité de service (“QoS”) est la pratique consistant à donner la priorité à certains types de trafic lorsque le trafic est supérieur à ce que le réseau peut gérer.
(Par exemple sur un ordinateur gamer la QoS est utilisée pour que la carte réseau priorise le jeu plutôt qu'un téléchargement en tâche de fond afin de maintenir un ping stable.)
En janvier dernier, après que Solana ait été confronté à des problèmes de performance lorsque des stratégies de trading automatisées (alias “bots liquidateurs”) ont inondé le réseau de plus de 2 millions de paquets par seconde, principalement des messages en double, Anatoly Yakovenko, le fondateur de Solana, a indiqué dans un tweet que son équipe et lui allaient introduire le concept de QoS dans Solana.
Jusqu'à présent, le Leader essayait de traiter les transactions dès qu'elles arrivent.
Mais grâce au protocole QUIC, les IP sont maintenant vérifiables, les validateurs seront en mesure de hiérarchiser et de limiter le trafic pour des connexions spécifiques. Au lieu que les validateurs et les RPC envoient des transactions au leader aussi vite qu'ils le peuvent, ce qui constitue un DoS'ing pour le leader, ils auront une connexion QUIC persistante.
Si le réseau (IP) est encombré, il sera possible d'identifier et d'appliquer des politiques aux connexions à fort trafic, en limitant le nombre de messages que le nœud peut envoyer (“throttle”). Ces politiques sont connues sous le nom de QoS.
En interne, la QoS pondérée par les stakers signifie la mise en file d'attente des transactions dans différents canaux en fonction de l'expéditeur, pondérée par la quantité de SOL stakés.
Les nœuds qui ne sont pas validateurs seront alors incités à envoyer des transactions aux nœuds validateurs d'abord, au lieu d'envoyer directement au leader, pour avoir une meilleure chance de trouver une exécution, puisque les messages excédentaires des nœuds qui ne sont pas des validateurs seront très probablement abandonnés par le leader.
Selon Anatoly, les validateurs seront responsables de la mise en forme de leur propre trafic et de l'application de politiques visant à éviter la vulnérabilité. Par exemple, si un nœud particulier envoie d'énormes quantités de transactions, même s'il est validateur, les autres validateurs pourront prendre des mesures en ignorant les connexions établies avec ce nœud afin de protéger les performances du réseau.
Les frais Solana sont actuellement fixes et facturés pour chaque signature requise dans une transaction (5000 lamports = 0,000005 SOL). Si la concurrence est forte sur un marché spécifique, les utilisateurs courent le risque de ne pas voir leurs transactions exécutées. Avec des frais de transaction fixes, il n'y a aucun moyen de communiquer la priorité ou de rivaliser en payant plus pour obtenir la priorité de leur transaction.
En l'absence d'alternatives, les utilisateurs (généralement des robots) envoient des transactions par spam au leader (et aux futurs leaders) dans l'espoir qu'au moins l'une d'entre elles aboutisse. Dans de nombreuses situations, ce comportement génère plus de trafic que ce que le réseau peut traiter.
Un mécanisme de frais additionnels a été ajouté à Solana en juin 2022, permettant aux utilisateurs de spécifier des frais supplémentaires arbitraires à percevoir lors de l'exécution de la transaction et de son inclusion dans un bloc. Ce mécanisme aide non seulement le réseau à donner la priorité aux transactions sensibles au temps, mais il tend également à réduire la quantité de messages invalides ou dupliqués envoyés par les algorithmes, puisque les opérations spéculatives peuvent devenir non rentables avec une augmentation du coût total.
Le rapport entre ces frais et les unités de calcul demandées (le coût de calcul du programme pour effectuer toutes les opérations) servira de poids à la priorité d'exécution d'une transaction. Ce rapport sera utilisé par les nœuds pour classer par ordre de priorité les transactions qu'ils envoient au leader. Les frais supplémentaires seront traités de la même manière que les frais de base actuels : 50% des frais payés seront collectés par le leader et 50% seront brûlés.
À ce stade, on pourrait imaginer que plusieurs blocs soient remplis uniquement de transactions visant une monnaie NFT. Cependant, il y a un temps limite pour que chaque compte soit bloqué pour l'écriture sur un seul emplacement (600 à 800 millisecondes). L'espace de bloc restant peut être rempli par des transactions écrivant sur des comptes différents, même s'ils offrent un droit de priorité plus faible. Les transactions à haute priorité essayant d'écrire sur un compte qui a déjà atteint sa limite seront incluses dans le bloc suivant.
Chaque transaction Solana spécifie les comptes accessibles en écriture – la partie de l'état qui sera modifiée. Cela permet d'exécuter des transactions en parallèle, tant que les transactions sont indépendantes, c'est-à-dire qu'elles n'accèdent pas aux mêmes comptes. Si deux transactions écrivent ou lisent sur le même compte, ces deux transactions ne peuvent pas être traitées en parallèle, car elles affectent le même état.
L'équipe Solana soutient que les frais de priorité se comporteront alors comme des enchères parallèles, n'affectant que le “marché chaud” au lieu du prix global, permettant aux frais d'augmenter pour une file spécifique de transactions essayant d'écrire dans ce compte uniquement.
Comment l'utilisateur connaît-il le tarif à adopter pour mint son NFT ? Les nœuds RPC devront estimer des frais additionnels adaptés, très probablement en utilisant une méthode statistique simple, par exemple en faisant la moyenne du coût réel de transactions similaires dans les N blocs précédents. La méthode optimale dépendra du marché, et du fait que les frais pour des transactions similaires sont plus volatiles (forte demande) ou stables (moindre demande).
En pratique, les frais additionnels peuvent avoir un effet global, si les enchères parallèles ne sont pas implémentées sur le client validateur. Les RPC et les utilisateurs étant responsables de sa fixation arbitraire, lors d'un trafic intense, les applications essaieront probablement d'obtenir la priorité même si elles n'interagissent pas avec le “marché chaud”, ce qui entraînera une augmentation du prix des frais pour d'autres dApps moins solicitées.
Le présent article a couvert les trois éléments sur lesquels Solana travaille activement pour traiter les problèmes de congestion, qui comprennent le changement du protocole de communication de UDP à QUIC, l'ajout d'une QoS pondérée par les stakers pour la priorisation des transactions et un marché des frais qui augmente les frais en cas de forte demande.
Nous espérons qu'il a été possible de clarifier ces concepts et de comprendre les motivations et les choix effectués. L'exploration du code source de Solana serait une prochaine étape essentielle pour étudier les mesures exactes mises en œuvre dans QoS pour sélectionner ou abandonner des transactions ou le mécanisme derrière l'augmentation (et la diminution) des frais et d'autres questions qui restent sans réponse.
Merci particulier à Thalita @ethalita_ et Chorus One pour la rédaction de cet article. Vous pouvez retrouver l'article original sur Medium : ici.
