Nous sommes fiers de présenter Alpenglow, le nouveau protocole de consensus de Solana. Alpenglow est un protocole de consensus conçu pour une blockchain mondiale à haute performance basée sur le proof-of-stake. Nous croyons que le lancement d'Alpenglow sera un tournant pour Solana. Alpenglow n'est pas seulement un nouveau protocole de consensus, mais le plus grand changement apporté au protocole central de Solana depuis, eh bien, toujours.

En passant à Alpenglow, nous disons adieu à un certain nombre de composants hérités du protocole de base, en particulier TowerBFT et Proof-of-History. Nous introduisons plutôt Votor, qui prend en charge la logique de vote et de finalisation des blocs. De plus, plutôt que de s'appuyer sur le gossip, Alpenglow adopte un primitive de communication directe plus rapide.

Bien qu'il s'agisse d'un grand changement, Alpenglow s'appuie sur les plus grandes forces de Solana. Turbine a joué un rôle crucial dans le succès du réseau Solana, car il aborde l'aspect important de la diffusion des données. Dans les blockchains du passé, le leader était souvent le goulot d'étranglement du système. En revanche, Turbine présente une technique où chaque bloc est codé par effacement en de nombreux morceaux plus petits qui peuvent être diffusés rapidement. Il est crucial que la bande passante de tous les nœuds soit utilisée dans ce processus. Rotor, qui est le protocole de diffusion de données d'Alpenglow, adopte l'approche de Turbine et l'affine.

Avec ces changements, nous porterons Solana à un niveau de performance sans précédent. Avec TowerBFT, Solana avait environ 12,8 secondes entre la création de bloc et la finalité du bloc. Pour réduire la latence à un domaine sous la seconde, Solana a introduit le concept de "confirmation optimiste". Alpenglow va briser ces deux limites de latence. Nous nous attendons à ce qu'Alpenglow puisse atteindre une finalité réelle en environ 150 ms (médiane). Parfois, la finalité peut être atteinte aussi rapidement que 100 ms, ce qui est un chiffre incroyablement bas pour un protocole de blockchain L1 mondial. (Ces chiffres de latence sont basés sur des simulations avec la distribution de mise actuelle du mainnet, sans compter les frais de calcul.)

Une latence médiane de 150 ms ne signifie pas seulement que Solana est rapide — cela signifie que Solana peut rivaliser avec l'infrastructure Web2 en termes de réactivité, rendant potentiellement la technologie blockchain viable pour de nouvelles catégories d'applications qui exigent des performances en temps réel.

Le graphique ci-dessus montre la répartition de la latence des différentes parties d'Alpenglow avec le leader à Zurich, en Suisse. Nous avons choisi Zurich comme exemple car c'était notre emplacement lors du développement d'Alpenglow. Chaque barre montre les délais moyens de la distribution mondiale actuelle des nœuds Solana, triés par distance de Zurich. Les latences simulées pour atteindre les différentes étapes du protocole Alpenglow sont tracées par rapport à la fraction du réseau qui est arrivée à cette étape.

Les barres vertes montrent la latence du réseau. Avec la distribution actuelle des nœuds de Solana, environ 65 % du capital de Solana se trouve à moins de 50 ms de latence réseau par rapport à Zurich. La longue traîne du capital a plus de 200 ms de latence réseau par rapport à Zurich. La latence du réseau sert de limite inférieure naturelle pour notre graphique, par exemple, si un nœud est à 100 ms de Zurich, alors tout protocole a besoin d'au moins 100 ms pour finaliser un bloc à ce nœud.
Les barres jaunes montrent le retard encouru par Rotor, la première étape de notre protocole.
Les barres rouges indiquent le moment où un nœud a reçu des votes de notarisation d'au moins 60 % de la mise.
Enfin, les barres bleues montrent le temps de finalisation.

D'où vient cette haute performance ?

Le composant de vote de Votor d'Alpenglow finalise les blocs en un temps record lors d'un seul tour de vote si 80 % du capital est participant, et en deux tours si seulement 60 % du capital est réactif. Ces deux modes de vote sont intégrés et exécutés simultanément, de sorte que la finalisation se produit dès que le chemin le plus rapide se termine.

Rotor, qui est le sous-protocole de diffusion de données d'Alpenglow, adopte l'approche de Turbine et l'affine. Comme Turbine, Rotor utilise la bande passante des nœuds participants proportionnellement à leur mise, atténuant le goulot d'étranglement du leader pour un débit élevé. En conséquence, la bande passante totale disponible est utilisée de manière asymptotiquement optimale. L'une des idées qui ont influencé la conception de Rotor est que la vitesse de la lumière est encore trop lente, et que le retard dans la dispersion de l'information est dominé par la latence du réseau, plutôt que par le retard de transmission ou de calcul. Rotor dispose d'une seule couche de nœuds relais, contrairement à l'arbre multi-couches de Turbine. De cette manière, Rotor minimise le nombre de sauts dans le réseau. De plus, Rotor introduit de nouvelles techniques pour déterminer les nœuds relais, ce qui améliore la résilience.

Alpenglow est construit sur des recherches de pointe, combinant la distribution de données codées par effacement avec les dernières avancées en matière de consensus. Il introduit des innovations, telles que ses modes de vote intégrés en une/deux rondes, entraînant une latence de finalisation sans précédent. La résilience distinctive "20+20" permet au protocole de fonctionner efficacement même dans des conditions réseau difficiles, tolérant jusqu'à 20 % de mise adversaire et une additional 20 % de mise non réactive. D'autres contributions incluent une stratégie d'échantillonnage à faible variance.

Nous avons rédigé un livre blanc complet qui décrit Alpenglow en détail. Le livre blanc présente l'intuition derrière Alpenglow et ce que nous voulons accomplir. Il discute également du protocole avec des définitions concises et du pseudo-code. Le livre blanc inclut diverses mesures et calculs de simulation pour comprendre comment Alpenglow va fonctionner. Enfin, le livre blanc contient des preuves de correction.

Avertissement :

1. Cet article est reproduit de [ anza]. Tous les droits d'auteur appartiennent à l'auteur original [Quentin Kniep, Kobi Sliwinski, et Roger Wattenhofer]. Si vous avez des objections à cette réimpression, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Avertissement de responsabilité : Les opinions et points de vue exprimés dans cet article n'engagent que l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.