Résumé Agave 2.0

La sortie de Agave validateur client v2.0 marque une étape importante dans le parcours de Solana vers un écosystème multi-client plus robuste. Cette mise à jour introduit plusieurs améliorations critiques pour améliorer les performances, la fiabilité et l’efficacité du réseau. Les principaux changements de cette mise à jour incluent:

• Refactorisations et optimisations approfondies du code source
• Récompenses d’époque partitionnées
• Récompenser les validateurs avec des frais de priorité complets
• Le nouveau planificateur central est maintenant activé par défaut
• Le programme de preuve ZK ElGamal
• Obtenir-Sysvar Syscall
• Appel système GetEpochStake
• MoveStake et MoveLamports
• Suppression des méthodes RPC obsolètes
• Changements de nom de caisse

‍

Que vous soyez un validateur, un développeur sur la plateforme ou un utilisateur actif de Solana, cet aperçu complet de la mise à jour Agave 2.0 vous fournira les informations nécessaires pour comprendre et tirer parti de ces dernières innovations.

Qu’est-ce qui fait de la version 2.0 une mise à jour majeure ?

Il n’y a plus un seul ‘validateur Solana’. Agave 2.0 adopte le nouveau monde multi-client de Solana et marque une rupture nette avec l’ancien.Dépôt GitHub de Solana Labs. Le dépôt Solana Labs sera archivé et les nouvelles demandes d’extraction ou problèmes ne seront plus acceptés. Auparavant, ce dépôt reflétait l’activité du dépôt Agave. Les développeurs doivent migrer toutes les activités vers leDépôt GitHub Anza Agaves’ils ne l’ont pas déjà fait. Le Processus de migration de Solana Labs vers Agavea commencé le 1er mars et est suivi publiquement sur leur GitHub.

‍

À mesure que l’écosystème évolue, les opérateurs doivent s’adapter à l’exécution d’un ou plusieurs clients. Suite à ce changement, plusieurs caisses sont renommées, libérant l’espace de noms pour prendre en charge plusieurs clients, notamment Firedancer, gérés par des équipes de développeurs indépendantes. Les caisses maintenues par Anza seront maintenant préfixées par « agave », ce qui les rend facilement identifiables en tant que dépendances spécifiques à Anza dans l’environnement multi-clients.

‍

‍

Les caisses concernées sont:

‍

solana-validator, solana-ledger-tool, solana-watchtower, solana-install, solana-geyser-plugin-interface, solana-cargo-registry

‍

Comme indiqué dans notreguide de transition précédent, la mise à jour 2.0 introduit plusieurs changements majeurs, notamment la suppression de plusieurs points de terminaison obsolètes et dépréciés - des mises à jour clés que tous les développeurs Solana devraient maintenant connaître. Tous les détails des changements RPC sont inclus à la fin de cet article.

Panneau déroulant des fonctionnalités

Au moment de l’écriture, environ 20,7 % des validateurs exécutent la version 2.0.14. Les activations de la fonction gate sur mainnet sont temporairement suspendues pour permettre à l’adoption de la v2.0 de mieux s’aligner sur les activations sur le testnet et le devnet. Une fois que le cluster mainnet aura largement adopté la v2.0, les activations de la fonction gate devraient reprendre selon le plan.ordre d’activation programmé.

‍

Les nouvelles fonctionnalités complètes discutées dans les sections suivantes ne sont actuellement pas disponibles et seront déployées progressivement tout au long du cycle de vie 2.0 en utilisant un système de portail de fonctionnalités. Les fonctionnalités sont activées à certains moments en fonction de la priorité relative et de l’ordre dans lequel elles ont été activées sur les clusters de testnet et de devnet.

‍

Récompenser les frais de priorité complets aux validateurs

Cette attente très attendue etmise à jour économique très débattueest maintenant en cours de mise en œuvre suite à la proposition,SIMD-0096, qui a été soumis à un vote de gouvernance du validateur en mai. Le vote s’est conclu à la fin de l’époque 620, avec 51,17 % de la participation des enjeux et 77,77 % de votes en faveur. La mise à jour sous la forme d’une porte de fonctionnalité changera fondamentalement la gestion du réseau.frais de priorité. Au lieu du modèle actuel, qui répartit les frais avec 50 % brûlés et 50 % récompensés aux validateurs, le nouveau modèle allouera 100 % des frais prioritaires directement aux validateurs.

Au-dessus: Frais de priorité hebdomadaires de Solana en valeur USD (source)

‍

Bien que les frais prioritaires soient techniquement facultatifs, ils sont devenus une pratique courante à mesure que l’activité économique sur Solana a augmenté. Ces frais sont calculés en micro-lamports (millionièmes de lamport) par unité de calcul à l’aide de la formule suivante :

‍

frais de priorisation = prix de l’unité de calcul (micro-lamport) x limite de l’unité de calcul

‍

À l’avenir, tous les frais prioritaires seront attribués aux producteurs de blocs. Cela crée une plus grande alignement des incitations et réduit la probabilité que les validateurs s’engagent dans des arrangements en dehors du protocole pour l’inclusion des transactions, ce qui a été un problème par le passé.

‍

Bien que la suppression des frais de combustion augmente légèrement le taux d’inflation net de SOL, l’émission de nouveaux jetons via des récompenses de jalonnement a un impact bien plus significatif. Les lecteurs peuvent se référer à notre précédent article de blog Helius surLe calendrier d’émission et d’inflation de Solanapour une analyse plus détaillée de ces dynamiques.

‍

Récompenses d’époque partitionnées

Récompenses d’époque partitionnéesvisent à distribuerrécompenses de miseà travers plusieurs blocs, ce qui atténue les problèmes de performance liés à la concentration de la distribution des récompenses dans le premier bloc de chaque nouvelle époque. Le principal goulot d’étranglement dans ce processus est l’obligation d’écrire des mises à jour sur le nombre croissant de comptes de participation actifs sur le réseau, qui totalisent maintenant environ 1,4 million. \n

Dans cette nouvelle approche, le calcul et la distribution des récompenses de participation à l’enjeu à la limite d’époque seront divisés en deux phases distinctes :

‍

• Phase de calcul des récompenses : Dans cette phase, les récompenses d’époque pour tous les comptes de mise actifs sont calculées, et la distribution est divisée en tranches planifiées.
• Phase de distribution des récompenses : Les récompenses d’époque précalculées pour les comptes de mise actifs sont distribuées en conséquence.

‍

Pour faciliter et surveiller le processus, un compte Sysvar,EpochRewards, suivra et vérifiera la distribution des récompenses tout au long de la phase de distribution. Le Sysvar EpochRewards enregistre si la phase de distribution des récompenses est en cours et les informations nécessaires pour reprendre la distribution lorsqu’on part d’un instantané.

Calcul de récompense

Les calculs de récompense seront effectués au premier bloc de l’époque. Une fois calculées, les récompenses sont divisées en morceaux de distribution stockés dans la banque, qui seront distribués pendant la phase de distribution des récompenses.

‍

Afin de minimiser l’impact sur le temps de traitement des blocs pendant la phase de distribution des récompenses et de garantir que chaque bloc distribue une sous-ensemble des récompenses de manière déterministe, un objectif de 4 096 récompenses de participation sera distribué par bloc. Pour se prémunir contre une croissance dramatique du nombre de comptes de participation, le nombre de blocs est limité à 10% du total des emplacements dans une époque. Seulement si cette limite de bloc est atteinte, les comptes par partition sont autorisés à dépasser l’objectif de 4 096.

Distribution des récompenses

La distribution des récompenses commence immédiatement après la phase de calcul des récompenses, à partir du deuxième bloc de l’époque. Les distributions de récompenses ont lieu en haut du bloc avant le traitement normal des transactions.

‍

En conséquence, les utilisateurs peuvent voir les récompenses créditées sur leurs comptes d’enjeu quelques blocs plus tard qu’auparavant. Cependant, l’expérience globale reste similaire, car le temps de bloc initial prolongé à la limite de l’époque retardait auparavant l’accès de l’utilisateur aux comptes d’enjeu. Un avantage supplémentaire de cette approche est que les transactions non en jeu peuvent continuer à être traitées en douceur, alors qu’auparavant, elles étaient bloquées pendant la distribution des récompenses.

‍

En raison du nombre relativement faible de comptes de vote, environ 1 500, le mécanisme existant de distribution des récompenses de vote au premier bloc de la limite d’époque restera inchangé. Seules les récompenses d’enjeu seront distribuées sur plusieurs blocs.

‍

Central Scheduler Est Maintenant Activé Par Défaut

Initialement introduit en tant que version avec fonctionnalités supplémentaires dans la mise à jour v1.18, le planificateur central, anciennement connu sous le nom de « planificateur », n’était pas activé par défaut et devait être activé par les opérateurs à l’aide du drapeau —block-production-method central-scheduler lors du démarrage d’un validateur. Il est maintenant activé par défaut. L’implémentation précédente du planificateur avait plusieurs problèmes pouvant affecter négativement les performances. Les goulots d’étranglement dans le traitement des transactions entraînaient souvent des fluctuations ou des incohérences dans l’ordre et la priorisation des transactions.

‍

La nouvelle implémentation remplace le modèle précédent de quatre fils bancaires indépendants, chacun gérant sa propre priorisation et son propre traitement de transaction. Dans cette structure révisée, l’ordonnanceur central est le seul destinataire des transactions de l’étape SigVerify du TPU. Il construit une file d’attente de priorité et déploie un graphe de dépendance, connu sous le nom de prio-graphe, pour mieux gérer le traitement et la priorisation des transactions en conflit. Cette nouvelle conception d’ordonnanceur augmente la scalabilité et la flexibilité, permettant une augmentation du nombre de fils sans les préoccupations précédentes de conflits de verrouillage accrus. Le déploiement initial de l’ordonnanceur central a montré qu’il génère de meilleures récompenses, ce qui se traduit par des gains améliorés pour de nombreux opérateurs. Notre précédent article Helius sur la mise à jour Solana v1.18 a couvert en détail cette nouveauté.comment fonctionne l’ordonnanceur central.

‍

Programme de preuve ZK ElGamal

Le programme ZK Token Proof, initialement prévu pour être inclus dans la version 1.17, est maintenant obsolète et sera remplacé par une solution plus polyvalente et indépendante de l’application.Programme de preuve ZK ElGamal. Le nouveau programme ZK ElGamal Proof conserve les parties du programme ZK Token Proof qui s’appliquent largement à toutes les applications, telles que la vérification de la validité d’une clé publique ou de la plage de valeurs chiffrées dans un texte chiffré ElGamal. Cependant, il omet des éléments spécifiques à l’application, tels que la validation de preuve à divulgation nulle de connaissance requise pour les instructions de transfert de jeton SPL. Le nouveau programme ZK ElGamal Proof sera incorporé dans la liste des programmes intégrés à l’adresse suivante : ZkE1Gama1Proof11111111111111111111111111111.

‍

Pour en savoir plus sur le programme de preuve de jeton ZK, lisez notrearticle original sur le blog Helius.

Get-Sysvar Syscall

Les appels système, ou appels système, demandent des services au noyau du système d’exploitation. Dans le contexte de Solana, un appel système permet aux programmes s’exécutant dans la machine virtuelle Solana (SVM) d’interagir avec des ressources et des services externes.

‍

Les sysvars exposent des informations sur l’état du cluster, telles que le hachage du bloc récent et les récompenses de l’époque. Ces comptes sont peuplés à des adresses connues. Les programmes peuvent accéder aux sysvars via un compte sysvar ou les interroger via un syscall. Les programmes on-chain utilisent de nombreux sysvars pour une large gamme de cas d’utilisation, et certains sysvars sont essentiels pour le fonctionnement du réseau.

‍

L’appel système Get-Sysvar, initialement proposé dansSIMD-127 par l’ingénieur Anza Joe Caulfield, introduit une interface Syscall unifiée pour l’accès aux données Sysvar. Cette mise à niveau permet de récupérer des données Sysvar auparavant inaccessibles, y compris SlotHashes et StakeHistory. Grâce à cette nouvelle interface, les développeurs peuvent accéder à des fragments spécifiques de données Sysvar, tels que l’appel SlotHashes ::get_slot(emplacement)etStakeHistory::get_entry(epoch)—sans avoir besoin de dupliquer des structures de données entières.

‍

La mise à jour réduit également les frais généraux lors de la modification des mises en page de données Sysvar ou de l’ajout de nouveaux Sysvars. Auparavant, chaque nouveau Sysvar nécessitait l’ajout d’un Syscall correspondant, créant une relation étroitement couplée qui a gonflé l’interface Syscall au fil du temps et compliqué la maintenance. Désormais, un seul Syscall sol_get_Sysvar servira toutes les interfaces Sysvar, permettant une récupération de données cohérente et efficace à partir de n’importe quel Sysvar.

‍

L’introduction du nouveau Syscall simplifie le processus de modification et d’ajout de nouveaux Sysvars. Il réduit considérablement la complexité et les exigences de maintenance de l’interface Syscall. De plus, cette mise à jour ouvre la voie à l’extension de l’accès du programme BPF aux données Sysvar, ce qui permet aux programmes on-chain de lire davantage d’informations Sysvar sans impact sur la taille des transactions.

‍

Obtenez le système d’appel GetEpochStake

Le nouveau Appel système GetEpochStakeintroduira une fonctionnalité très demandée pour récupérer la participation déléguée d’un compte de vote pour l’époque en cours, offrant ainsi une méthode plus efficace et directe pour récupérer ces informations sur la chaîne.

‍

Actuellement, les programmes ne peuvent pas accéder aux données en temps réel sur les enjeux délégués à des comptes de vote spécifiques pour l’époque en cours, ce qui crée une barrière pour des cas d’utilisation tels que la gouvernance des validateurs et les mécanismes de consensus secondaires. Permettre l’interrogation on-chain de ces données ouvrira la voie à ces applications et préparera le terrain pour les cas d’utilisation futurs.

‍

Avec GetEpochStake, les développeurs fournissent une adresse de compte de vote de 32 octets, et l’appel système renverra un entier u64 représentant le total des participations actives actuellement déléguées à ce compte de vote. Si l’adresse fournie ne correspond pas à un compte de vote valide ou n’existe pas, l’appel système renverra simplement 0.

‍

MoveStake et MoveLamports

Deux nouvelles instructions de programme de mise en jeu,MoveStake et MoveLamports, sont introduits pour faciliter les transferts de valeur entre les comptes de mise. Ces instructions, proposées pour la première fois dansSIMD-0148, aider les développeurs en permettant le transfert de fonds entre des comptes avec des autorités correspondantes sans le contrôle de l’autorité du retrait.

‍

Auparavant, les protocoles gérant les enjeux des utilisateurs étaient confrontés à des difficultés lorsqu’il s’agissait de répartir les enjeux entre plusieurs validateurs et de les redédéléguer régulièrement. Lorsqu’un protocole divise la mise d’un utilisateur pour la désactivation, il doit financer l’exonération de loyer pour le nouveau compte. Le protocole ne peut pas récupérer l’exonération de loyer lors de la fusion de ces comptes partagés.

MoveStake : Cette instruction permet de déplacer un stake actif d’un compte à l’autre, en le transférant d’un compte actif à un autre ou d’un compte actif à un compte inactif, réactivant ainsi le compte. Si l’intégralité de la délégation du compte source est déplacée, le compte source devient inactif. Le solde exonéré de loyer reste inchangé dans tous les scénarios, et les règles de délégation minimales sont maintenues pour les comptes actifs.

‍

MoveLamports : Déplacer les lamports excédentaires d’un compte actif ou inactif vers un autre compte actif ou inactif, où “lamports excédentaires” fait référence aux lamports qui ne sont ni des parts déléguées ni nécessaires à l’exemption de loyer. MoveLamports permet d’effectuer des tâches de maintenance telles que la récupération de lamports à partir de comptes fusionnés et la consolidation des fonds inutilisés.

‍

Pour simplifier la mise en œuvre, ces modifications ne prennent pas en charge l’activation ou la désactivation des comptes et n’affectent pas les comptes d’enjeu partiellement actifs. Ces nouvelles instructions de programme ne modifient pas les fonctionnalités existantes.

‍

Bonus: La boîte Solana-SVM

Avec la sortie d’Agave 2.0 vient uncrate solana-svm flambant neuf offrant aux développeurs un accès direct aux principaux composants de la SVM par le biais d’une API simplifiée et indépendante de l’ensemble du cadre de validation. Cela ouvre le traitement des transactions hautes performances de Solana pour les applications au-delà du validateur, telles que les services hors chaîne, les clients légers, les canaux d’état et les cumuls.

‍

En dissociant l’API du reste de l’exécution, cette caisse élimine le besoin de composants tels que les instances de la Banque, réduisant ainsi les frais généraux opérationnels. Les développeurs peuvent désormais utiliser les mêmes composants robustes qui prennent en charge le mainnet-beta de Solana pour construire des projets SVM personnalisés tels que des clients légers, des canaux d’état, des rollups et des services hors chaîne. Le cœur de cette API est la structure TransactionBatchProcessor, qui permet aux applications de traiter des lots de transactions Solana désinfectées avec l’ensemble complet des composants Aval en aval, y compris le chargeur BPF, eBPF et la machine virtuelle.

‍

Ci-dessus : le processeur de traitement par lots de transactions (source de l’image : Anza)

‍

Lisez l’article en détailNouvelle API SVM d’Anza pour plus de détails sur ce développement passionnant.

‍

Supprimé les points de terminaison RPC

Plusieurs points de terminaison RPC Agave v1 obsolètes et obsolètes ont été supprimés. L’équipe d’Helius Devrel a contacté tous les clients utilisant ces terminaux. Grâce à une analyse interne, nous avons précédemment identifié un petit groupe de clients utilisant activement les points de terminaison suivants, qui sont configurés pour la suppression :

‍

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

‍

Encore une fois, nous recommandons vivement à tous les développeurs de vérifier les références à ces appels et de les mettre à jour en conséquence avec les remplacements suggérés.

‍

Ci-dessus: une liste complète des points de terminaison RPC Agave v1 obsolètes et dépréciés à supprimer

N.B. L’approche alternative pour obtenir les informations du compte indiquée dans l’image peut êtretrouvé ici.

‍

Les changements de rupture du SDK incluent :

‍

• La prise en charge de Borsh v0.9 a été supprimée, veuillez utiliser v1 ou v0.10 (#1440)
• La copie du trait n’est plus dérivée sur Rent et EpochSchedule ; Passer à l’utilisation de clone()
• solana-sdk: Symboles obsolètes) supprimé
• solana-programme : symboles obsolètes supprimés

‍

Pour les opérateurs de validateurs, plusieurs arguments de validateur obsolètes seront supprimés lors de la sortie d’Agave v2.0. Une liste complète de ceux-ci peut être trouvéeici.

‍

Conclusion

La mise à jour Agave 2.0 marque une avancée significative pour Solana, intégrant de nombreuses implémentations de fonctionnalités et optimisations d’exécution. Cette version continue de repousser les limites avec de nouveaux appels système puissants, des fonctionnalités étendues et une gestion complète, y compris des renommages de caisses, des suppressions de méthodes RPC obsolètes et des arguments de validation rationalisés. Agave 2.0 étend les capacités de Solana et affine ses performances et sa convivialité. Que vous soyez un développeur, un validateur ou un utilisateur actif, la mise à jour Agave 2.0 ouvre de nouvelles possibilités passionnantes pour tous les membres de l’écosystème Solana.

‍

Ressources supplémentaires / Lecture complémentaire

• Calendrier de sortie de Agave v2.0
• Journal des modifications Agave v2.0
• Versions de sortie d’Agave

Avertissement:

1. Cet article est repris de [ helius)]. Tous les droits d’auteur appartiennent à l’auteur original [Lostin]. S’il y a des objections à cette reproduction, veuillez contacter le Gate Learnl’équipe, et ils s’en occuperont rapidement.
2. Clause de non-responsabilité : Les opinions exprimées dans cet article sont uniquement celles de l’auteur et ne constituent en aucun cas des conseils 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.