Cofondateur de Solana : Construire une machine d’état mondiale et analyser l’architecture ultime de Solana

**Texte : Anatoly Yakovenko, PDG (cofondateur et PDG), Solana

Compilateur : 1912212.eth, Foresight News

L’objectif de Solana est de synchroniser le plus rapidement possible une machine d’état globale unique et sans autorisation, conformément aux lois de la physique. Je crois que l’architecture qui sera en mesure d’y parvenir ressemblera à ceci :

• Grand nombre de nœuds complets, plus de 10 000 (N > 10 000)

Pour que le réseau fonctionne comme une machine d’état globale, il doit prendre en charge de nombreux nœuds complets. Turbine a prouvé que la réplication rapide sur de très grands réseaux est évolutive sur du matériel et des réseaux modernes.

• Grand nombre de leaders de génération de blocs, plus de 10 000 (N > 10 000)
• Les leaders simultanés produisent des blocs en même temps, sélectionnés au hasard dans la plage de 4 à 16.

Concurrency Leader permet au réseau d’avoir plusieurs emplacements à travers le monde pour ordonner les transactions des utilisateurs. Il réduit la distance entre les utilisateurs et le réseau, éliminant ainsi le besoin d’une vérification complète des nœuds avant que les transactions ne soient ajoutées à la chaîne.

• Le temps de blocage est de 120 millisecondes

Des temps de blocage courts créent des points de finalité rapides, renforcent la résistance à la censure, améliorent l’expérience utilisateur, réduisent les fenêtres de réorganisation des transactions et accélèrent le réseau dans son ensemble.

• Certains des nœuds de consensus de vote dans le sous-comité d’approbation, avec un nombre compris entre 200 et 400, sont sélectionnés au hasard et font l’objet d’une rotation toutes les 4 à 8 heures par époque.

Le consensus est essentiel pour le choix d’un fork, qui se produit en raison du partitionnement du réseau. Un échantillon de 200 nœuds ou plus sera statistiquement représentatif de toutes les partitions principales du réseau et correspondra étroitement à leur distribution réelle. Par conséquent, tous les votes de nœud complet ne sont pas requis, 200 suffisent. Limitez l’approbation aux sous-comités afin de réduire la mémoire et la bande passante réseau nécessaires pour prendre en charge les blocs de 120 ms. La réduction du temps de blocage augmente naturellement le nombre de votes envoyés par seconde, ce qui exerce une certaine pression sur les ressources allouées au consensus.

Le véritable défi dans le bloc de 120 ms est de rejouer toutes les transactions de l’utilisateur. Étant donné que le réseau n’a pas d’autorisation, il est extrêmement difficile de garantir un environnement d’exécution homogène avec un temps fiable pour exécuter du code utilisateur arbitraire. Bien qu’il existe une possibilité, cela ne peut être réalisé qu’en limitant les ressources de calcul disponibles pour les transactions utilisateur et en veillant à ce que chaque nœud soit suralloué au pire des scénarios.

Cependant, il n’y a aucune raison d’appliquer un état complet pour les nœuds de consensus qui votent pour un fork ou un leader qui construit sur un fork. Afin de synchroniser les approbations des nœuds de consensus et des leaders, l’état ne doit être calculé qu’une seule fois par période.

Exécution asynchrone

Motivation

L’exécution synchrone nécessite que tous les nœuds qui votent et créent des blocs soient super-configurés dans n’importe quel bloc pour déterminer le temps d’exécution le plus défavorable. L’exécution asynchrone est l’un des rares cas où il y a peu de compromis. Les nœuds de consensus peuvent effectuer moins de travail avant de voter. Le travail peut être agrégé et groupé, ce qui le rend efficace dans l’exécution sans aucune perte de cache. Il peut même être exécuté sur une machine complètement différente de celle du nœud de consensus ou du leader. Les utilisateurs qui souhaitent une exécution synchrone peuvent allouer suffisamment de ressources matérielles pour effectuer chaque transition d’état en temps réel sans avoir à attendre l’ensemble du réseau.

Compte tenu de la diversité des applications et des développeurs principaux, il vaut la peine de planifier un changement de protocole majeur chaque année. Si je devais en choisir un, mon choix serait d’exécuter de manière asynchrone.

VUE D’ENSEMBLE

À l’heure actuelle, les validateurs répètent rapidement toutes les transactions sur chaque bloc et ne votent qu’une fois que l’état complet a été calculé pour le bloc. L’objectif de cette proposition est de séparer les décisions de vote sur les forks du calcul des transitions d’état complet des blocs.

Les validateurs qui votent dans l’approbation n’ont qu’à sélectionner le fork ; ils n’ont pas besoin d’effectuer d’état du tout. Ce n’est qu’à chaque époque qu’ils ont besoin du statut pour calculer l’approbation suivante.

La procédure de vote a été adaptée afin qu’elle puisse se dérouler de manière indépendante. Les nœuds exécutent les procédures de vote uniquement avant de voter. Étant donné que les validateurs ne prennent pas beaucoup de place, les besoins en mémoire devraient être relativement faibles. Étant donné que le temps d’exécution du vote est très prévisible, il devrait y avoir peu ou pas de gigue dans l’exécution de la procédure de vote.

Toutes les transactions sans droit de vote peuvent être calculées de manière asynchrone. Cela permet à replay d’exécuter toutes les transactions sans droit de vote par lots, de précharger et de JIT tous les programmes à l’avance, éliminant pratiquement toute perte de cache. L’objectif à long terme est que seules les machines qui nécessitent des calculs en temps réel, à faible latence et à l’état complet soient configurées pour cette tâche. On peut supposer que les utilisateurs paieront pour le matériel supplémentaire.

Une fois que la sélection du fork et l’exécution de l’état sont séparées, il devient plus facile d’accélérer les choses :

• Exécution asynchrone
• Chaque époque fait tourner un nombre fixe de comités de vote
• Temps de bloc de 200 ms

Étant donné que la relecture des transactions de l’utilisateur ne bloque pas la sélection du fork, la volatilité n’est plus un problème lors de la soustraction du temps de bloc. La seule chose à prendre en compte est qu’à 200 millisecondes, le taux de vote du validateur double. Le fait d’apporter un changement assez simple à la façon dont le quota est calculé pour les approbations nous permettra de fixer la taille de l’approbation à 200 ou 400, ou à tout autre nombre qui semble approprié.

Il est également naturel de séparer complètement la mise en œuvre du consensus. Il sera plus rapide de redémarrer le nœud de consensus qui n’a besoin que de vérifier le compte du programme de vote dans l’approbation de taille fixe.

En fait, je pense que le temps de confirmation va augmenter parce que la grande majorité des approbations sont votées le plus rapidement possible, et pendant que ces votes sont propagés, les nœuds qui fournissent aux utilisateurs des résultats d’exécution complets peuvent exécuter des transactions en même temps. Par conséquent, toute gigue de relecture que nous voyons aujourd’hui devrait se produire en même temps que la propagation du réseau de vote.

Votez

• Les comptes de vote doivent avoir un nombre suffisant de SOL pour couvrir les votes de 2 époques.
• Les transactions de vote doivent être simples. Un vote qui n’est pas simple est voué à l’échec. Les générateurs de blocs devraient renoncer aux votes complexes.
• Le retrait de SOL des comptes de vote est autorisé, tant que le solde ne tombe pas à moins de 1 époque de votes.
• Afin de mettre à zéro tous les lamports, la directive Vote CLOSE doit exiger que l’époque complète s’écoule. Les comptes de vote sont marqués comme FERMÉS dans l’ère 1, mais ne peuvent être fermés que dans l’ère 2. CLOSE vous permet de retirer toutes les SOL et de supprimer des comptes de vote. Une fois qu’un compte est marqué comme FERMÉ, il ne peut être complètement supprimé et ne peut pas être rouvert.
• Les votes contiennent un VoteBankHash au lieu d’un BankHash normal.

Réglementation et approbation des leaders

Seuls les validateurs répondent aux critères suivants :

• Montant de la mise > X
• Ainsi que SOL > 2 époques de vote
• et n’est pas marqué comme CLOSE

pour entrer dans l’échéancier de la ligne de repère et compter pour l’approbation. Pour la version 2, nous pouvons séparer le LeaderSchedule du Quorum, et ils n’ont pas besoin d’avoir les mêmes exigences chacun.

Calcul de VoteBankHash

Contrairement à Bankhash, qui calcule toutes les transactions, les validateurs ne calculent VoteBankHash que pour les transactions de vote simples liées aux validateurs dans le LeaderScheduler. Toutes les autres transactions sont ignorées. Après avoir rejoué tous les votes, le VoteBankHash est calculé dans le même format que le BankHash actuel.

Le VoteBankHash doit accumuler le VoteBankHash précédent, et non le BankHash complet.

Calculs de BankHash

Pour tous les blocs confirmés optimistes (configurables pour tous les blocs), le validateur commence à calculer le UserBankHash, qui inclut toutes les transitions d’état, mais exclut les transactions qui ont été prises en compte dans le calcul de VoteBankHash.

Le BankHash est alors dérivé de l’accumulation de (VoteBankHash, UserBankHash). Les meilleurs 99,5 % des validateurs soumettent BankHash dans le cadre de leur vote tous les 100 créneaux horaires. Bien qu’il soit validé tous les 100 créneaux horaires, il est calculé à chaque créneau horaire. Il est intéressant de noter qu’il pourrait être intéressant pour un petit pourcentage de nœuds de soumettre systématiquement BankHash dans les commérages comme un signal doux sans non-déterministe observé.

Si moins de 67 % des validateurs soumettent des calculs BankHash complets, les dirigeants doivent réduire de 50 % l’espace disponible pour les transactions des utilisateurs et les comptes inscriptibles. Cette mesure vise à protéger la chaîne contre les abus qui pourraient augmenter excessivement le temps de relecture.

BankHash doit accumuler les BankHash précédents.

Aller voir le leader de la banque

Lors de la création d’un bloc, il est probable que le leader ne soit pas en mesure d’obtenir l’état utilisé pour créer le bloc, et il n’est pas idéal d’exécuter toutes les transactions pendant la période de création du bloc.

• Les leaders maintiennent un cache des soldes des comptes payés.
• Si un compte payant est utilisé comme source pour les transferts système, ou comme compte inscriptible transmis avec un programme système à un autre programme, le solde du compte payant est défini sur 0.
• Les blocs sont emballés en fonction des unités de calcul (CU) déclarées dans l’ordre de priorité des frais locaux jusqu’à ce que les blocs soient remplis.
• Les frais sont déduits du cache du solde du compte payé.
• La mise en cache du solde des comptes payants est complétée par des calculs BankHash.

Le réseau n’entraîne que des coûts relativement faibles pour les échecs de spam de transaction, consistant uniquement en des octets stockés dans l’archive et de la bande passante nécessaire pour propager les transactions dans le bloc.

Étant donné que les validateurs cherchent déjà à maximiser leurs revenus, ils ont de nombreuses incitations à maintenir un cache précis des comptes payants. De plus, s’il n’y a pas de pénalité en place, n’importe qui dans n’importe quel réseau peut facilement servir le cache à long terme. En cas de corruption du serveur, un opérateur leader sans banque doit être en mesure de basculer facilement ou d’échantillonner à partir de plusieurs sources.

Cela signifie qu’en raison de la motivation des validateurs à maximiser les gains, ils s’efforceront de maintenir un cache précis des comptes payants. En l’absence d’un mécanisme de pénalité, ce cache peut être servi par n’importe quel nœud du réseau pendant une longue période. De plus, en cas de défaillance d’un serveur, un opérateur qui n’a pas de responsable bancaire doit être en mesure de passer facilement d’un serveur à l’autre ou d’échantillonner à partir de plusieurs sources.

Compromis

Le principal compromis est l’absence d’une signature d’accusé de réception sur le nœud complet desservant l’état de l’utilisateur pour confirmer que son statut de livraison est exactement le même que le reste approuvé. La seule explication faisant autorité de l’État doit rester la même, même si chaque transaction est rejouée séquentiellement dans le grand livre. Toute optimisation des performances ne doit pas altérer les résultats. Ainsi, une fois le fork finalisé, il ne reste plus que l’état correct à calculer, tant que l’implémentation du runtime est exempte d’erreurs.

Les nœuds conçus pour fournir un état fiable doivent exécuter plusieurs machines et clients, et en cas de divergence dans l’exécution de l’état, ils doivent cesser de fonctionner. C’est essentiellement ce que les opérateurs devraient faire aujourd’hui, car le fait de s’appuyer uniquement sur le reste du réseau introduit la plupart des hypothèses d’intégrité.

Les utilisateurs peuvent également signer des transactions qui affirment un BankHash ou déclenchent un abandon. Le reste du réseau n’exécutera ces transactions que si le BankHash exact calculé est exactement le même que le BankHash fourni à l’utilisateur par le fournisseur RPC.

Feuille de route à long terme du nœud de consensus sans état

Les réseaux avec des approbations de taille fixe ne nécessitent qu’une très petite quantité d’état pour démarrer. L’approbation elle-même et son poids de gage, ainsi que tous les soldes des comptes de vote. Il s’agit d’une très petite quantité de mémoire et d’un minuscule fichier instantané qui peut être rapidement distribué et rapidement initialisé lors d’un redémarrage.

Si l’approbation n’est pas cohérente avec le noeud complet, le noeud complet qui suit à la fois l’approbation et l’état cessera de s’exécuter. Cela signifie que s’il y a un désaccord entre l’approbation et le statut, l’échange, le canal fiat, le RPC, le pont, etc., cesseront tous de fonctionner. Cela ne nécessite qu’un très faible pourcentage de nœuds de consensus sans état défectueux.

Les leaders Bankless peuvent s’appuyer sur un échantillon de plusieurs nœuds complets pour fournir un cache du solde initial d’un compte payant. Même s’il est imparfait, le résultat sera du spam dans le bloc plutôt que l’échec du consensus. Les opérateurs doivent être en mesure de surveiller l’état de santé de leurs dirigeants et le pourcentage de spam qu’ils injectent dans leurs blocs, et de réagir rapidement aux défaillances.