Mise à jour Agave 4.3 : tout ce qu’il faut savoir

Introduction

Avec Agave 4.3, Solana se prépare à ce qui est probablement la plus importante mise à niveau de protocole de son histoire. Le cycle de publication 4.3 introduira Alpenglow, le nouveau mécanisme de consensus très attendu de Solana, avec pour point culminant « Alpenswitch » : la transition coordonnée du réseau principal pour abandonner TowerBFT.

Depuis son lancement, l’architecture de consensus de Solana repose sur Proof of History et TowerBFT. Les validateurs votent en soumettant des transactions qui sont traitées et incluses dans les blocs aux côtés des transactions ordinaires des utilisateurs. La finalité s’établit ensuite à mesure que ces votes s’accumulent sur 32 slots, ce qui donne à Solana un délai de finalité d’environ 12,8 secondes (en supposant des slots de 400 millisecondes).

Proof of History (PoH) était l’une des innovations architecturales emblématiques de Solana lors de son lancement, grâce à son approche unique de l’ordonnancement des événements et de la coordination temporelle. Son abandon marque donc la fin d’une époque et souligne à quel point le protocole a évolué depuis les technologies qui le distinguaient à l’origine.

Alpenglow remplace « PoH + TowerBFT » par Votor, un protocole dans lequel les validateurs échangent leurs votes en dehors du pipeline principal de transactions. Il agrège ces votes dans des certificats cryptographiques. Cette conception vise une finalité en environ 150 millisecondes.

Pour les utilisateurs et les applications qui soumettent des transactions et lisent l’état des comptes, la migration sera minime, voire inexistante. Les transactions et les mécanismes de frais restent inchangés. Les validateurs et les infrastructures qui consomment des blocs, des votes, des flux ou des données d’engagement connaîtront les ajustements les plus importants.

Les transactions de vote disparaissent des blocs, confirmed et finalized convergent dans les faits, et l’infrastructure de streaming reçoit de nouvelles informations permettant de distinguer les banques concurrentes au sein d’un même slot.

Dans cet article, nous verrons comment fonctionne Alpenglow, notamment ce que Votor change pour la production des blocs et la finalité. Nous aborderons également les autres évolutions notables prévues au cours du cycle de publication d’Agave 4.3.

Déploiement progressif : Votor d’abord, puis Rotor

Alpenglow a été conçu autour de deux composants majeurs : Votor, qui remplace le mécanisme de vote et de finalité de Solana, et Rotor, qui repense la propagation des blocs sur le réseau. Ces deux mécanismes seront déployés par étapes, en commençant par Votor.

Agave 4.3 introduit Votor tout en conservant le protocole actuel de propagation des blocs, Turbine. Rotor a été explicitement exclu de la SIMD-0326, la proposition qui régit l’activation initiale d’Alpenglow. Son déploiement nécessitera sa propre SIMD. Le déploiement initial modifie la manière dont les validateurs parviennent au consensus, mais pas encore la façon dont les données des blocs circulent sur le réseau.

Votor

Votor remplace les transactions de vote et le système de verrouillage de TowerBFT par un protocole plus direct entre validateurs. Avec TowerBFT, les validateurs votent en soumettant des transactions incluses dans les blocs, jusqu’à accumuler une profondeur de verrouillage suffisante pour qu’un bloc soit finalisé. Avec Votor, les validateurs échangent directement des messages de vote signés, puis le protocole agrège ces signatures dans des certificats compacts.

Au lieu d’attendre l’accumulation des votes sur 32 slots, Votor peut finaliser un bloc après un ou deux tours de vote. Le protocole vise une finalité d’environ 150 millisecondes, contre environ 12,8 secondes avec TowerBFT.

Votor dispose de deux chemins concurrents vers la finalité.

Si au moins 80 % du stake notarise un bloc au premier tour, ces votes peuvent être agrégés dans un Fast-Finalization Certificate et le bloc devient immédiatement définitif. Il s’agit du chemin rapide du protocole, qui ne nécessite qu’un seul tour de vote.

Si le seuil de 80 % n’est pas atteint, un bloc peut tout de même progresser si plus de 60 % du stake a voté pour le notariser. Cela produit un Notarization Certificate qui autorise un deuxième tour de vote. Dès que plus de 60 % du stake émet des votes de finalisation par ce chemin en deux tours, un Finalization Certificate est formé et le bloc devient définitif.

Le protocole complet comporte donc cinq types de votes : Notarization, Notarization Fallback, Skip, Skip Fallback et Final. Différentes combinaisons de ces votes produisent des certificats de notarisation, de repli, de saut ou de finalisation. Ces certificats constituent des preuves cryptographiques compactes qu’une part suffisante du stake s’est accordée sur le résultat d’un slot.

Votor est conçu pour continuer à progresser avec seulement 60 % de stake honnête et réactif. Jusqu’à 20 % du stake peut ainsi adopter un comportement adverse tandis que 20 % supplémentaires sont hors ligne ou ne répondent pas. Ce compromis est délibéré : Alpenglow renonce au seuil byzantin traditionnel d’un tiers des conceptions BFT au profit d’un modèle de résilience 20+20, plus tolérant envers les validateurs en panne ou indisponibles.

Votor supprime également l’utilisation de Proof of History comme horloge de consensus. Les validateurs utilisent à la place des délais d’expiration locaux. Si un validateur a attendu suffisamment longtemps sans recevoir de bloc acceptable, il peut émettre un vote de saut et permettre au consensus de poursuivre. Par rapport à TowerBFT, cela simplifie la relation entre la mesure du temps et le consensus.

Rotor

Rotor ne fait pas partie d’Agave 4.3 et aucune date d’activation n’est actuellement publiée. Turbine continuera donc à transporter les données des blocs lors de l’activation de Votor. Rotor, ainsi que le mécanisme d’échantillonnage intelligent utilisé pour sélectionner ses relais, fera ultérieurement l’objet d’une proposition et d’un déploiement distincts.

Il est important de noter que Solana n’a pas besoin d’attendre Rotor pour atteindre une finalité inférieure à une seconde. Le déploiement actuel d’Alpenglow vise une finalité d’environ 150 ms avec Votor dans Agave 4.3, tandis que Turbine reste en place. Rotor doit améliorer davantage la diffusion des blocs et accroître l’efficacité globale de l’architecture Alpenglow, mais il n’est pas indispensable au nouveau modèle de finalité de Votor.

Fin des transactions de vote

L’une des conséquences les plus visibles d’Alpenglow sera la disparition des transactions de vote dans les blocs Solana. Les validateurs paient des frais de transaction pour ces votes, tandis que le réseau consacre de la bande passante, des ressources de calcul et de l’espace dans le registre à leur traitement et à leur stockage.

Historiquement, les transactions de vote représentaient environ les trois quarts de toutes les transactions enregistrées onchain, une proportion qui a diminué à mesure que la capacité des blocs augmentait. Bien que les transactions de vote soient peu coûteuses (5 000 lamports) et ne représentent qu’une faible part (environ 5 %) du calcul total, elles gonflent le nombre brut de transactions du réseau et l’empreinte du registre.

Avec Alpenglow, les validateurs échangent directement entre eux des messages de vote signés par BLS. Le ConsensusPool d’Agave suit les votes observés et agrège une part suffisante du stake dans les certificats utilisés par Votor pour faire progresser ou finaliser le consensus.

Cela ne signifie pas que les preuves de participation des validateurs disparaissent du registre. Les blocs Alpenglow introduisent un nouveau pied de bloc contenant des informations de consensus. Dans l’implémentation actuelle d’Agave, BlockFooterV1 peut contenir le dernier certificat de finalisation ainsi que notar_reward_cert et skip_reward_cert. Les certificats de récompense comprennent une signature BLS agrégée et un bitmap identifiant les validateurs qui ont voté.

Les systèmes qui déterminent actuellement si un validateur a voté en indexant les transactions du Vote Program devront plutôt utiliser les certificats et les données liées aux votes d’Alpenglow. Les pipelines de transactions existants qui se contentent de filtrer les transactions de vote pourront généralement continuer à fonctionner ; après Alpenswitch, le filtre n’aura simplement plus rien à retirer.

Cette transition crée également une rupture dans les statistiques TPS habituelles de Solana. Une fois Alpenglow activé, les mesures brutes du TPS qui incluent les transactions de vote chuteront fortement, même si l’activité des utilisateurs reste parfaitement stable. Le TPS hors votes est donc la métrique pertinente pour comparer l’activité avant et après Alpenswitch. La suppression des transactions de vote élimine une source persistante de confusion concernant le débit réel de Solana et facilitera les comparaisons avec les réseaux concurrents.

La suppression des transactions de vote libère une certaine capacité pour les utilisateurs, mais il ne faut pas en exagérer l’effet, car les votes ne représentent qu’une part relativement faible de la charge de calcul du réseau.

Niveaux d’engagement

Alpenglow met également fin à l’une des distinctions historiques de Solana : l’écart entre les engagements confirmed et finalized.

Aujourd’hui, les applications choisissent entre trois niveaux d’engagement. processed fournit la vue la plus récente, mais sans garantie à l’échelle du cluster. confirmed signifie qu’une supermajorité du stake a voté pour le bloc, généralement dans un délai d’un ou deux slots. finalized offre une finalité déterministe, mais exige avec TowerBFT que le bloc atteigne le verrouillage maximal des votes, ce qui crée un écart d’environ 32 slots entre la confirmation et la finalisation. En règle générale, confirmed est recommandé pour les requêtes RPC sensibles à la latence, et finalized lorsqu’une garantie plus forte est nécessaire.

Dans la pratique, confirmed s’est révélé extrêmement fiable : aucun bloc Solana confirmé de manière optimiste n’a jamais échoué par la suite à être finalisé. La garantie du protocole reste toutefois plus faible. Un bloc confirmé n’est pas encore définitif de manière déterministe. Les applications comme les ponts, les plateformes d’échange et les systèmes de règlement, qui ne peuvent tolérer ce risque résiduel extrême, ont donc historiquement dû attendre finalized.

Alpenglow élimine ce compromis. Dès que Votor produit un certificat de finalisation rapide ou de finalisation, le bloc est définitif. Lorsque Votor sélectionne une banque finalisée comme racine, le validateur met simultanément à jour son slot confirmé le plus élevé, sa racine et sa racine de supermajorité la plus élevée.

Pour les développeurs, cela signifie qu’après Alpenswitch, confirmed et finalized désignent dans les faits le même état de consensus. Les applications existantes n’ont pas besoin de modifier leur paramètre d’engagement le jour de l’activation, car l’interface RPC accepte toujours processed, confirmed et finalized, mais la différence de latence entre les deux derniers disparaît.

La distinction entre les deux chemins de finalisation de Votor est invisible pour les consommateurs RPC ordinaires. Qu’un bloc atteigne le seuil de finalisation rapide de 80 % en un tour ou soit finalisé par le chemin en deux tours avec un seuil de 60 %, le résultat visible de l’extérieur est identique.

Plusieurs blocs candidats

Une autre évolution importante d’Alpenglow concerne les fournisseurs RPC, les indexeurs et les autres infrastructures qui consomment les données des validateurs. Un slot ne peut plus être considéré comme l’identifiant unique d’un bloc.

Un slot Solana est une fenêtre pendant laquelle un leader peut produire un bloc. Un bank est quant à lui la représentation locale, par le validateur, de l’état produit par l’exécution d’un bloc candidat donné. Ces concepts ont toujours été distincts et les banques concurrentes ne sont pas nouvelles, mais une grande partie des infrastructures de production a toujours traité les slots et les blocs comme des synonymes.

Avec Alpenglow, cette hypothèse devient de plus en plus risquée.

Agave 4.3 étend Geyser, l’interface de validateur utilisée pour diffuser les mises à jour de comptes, de transactions, d’entrées et de blocs, avec un nouvel identifiant : bank_id. Les nouveaux callbacks tenant compte des banques, notamment update_account_for_bank, notify_transaction_for_bank, notify_entry_for_bank et notify_block_metadata_for_bank, associent un événement à la banque précise qui l’a produit. De même, les notifications d’état limitées à une banque contiennent un bank_id. Les anciens callbacks sont conservés dans la version 4.3 à des fins de compatibilité, mais sont obsolètes et leur suppression est prévue dans la prochaine version majeure d’Agave.

Le point important est que bank_id identifie une instance locale de banque, et non un bloc faisant l’objet d’un accord mondial. Agave crée les identifiants de banque à partir d’un compteur atomique local géré par l’environnement d’exécution du validateur. Il ne faut donc pas s’attendre à ce que deux validateurs rejouant le même bloc lui attribuent le même bank_id. L’infrastructure doit par conséquent utiliser (slot, bank_id) pour séparer les flux concurrents provenant d’un même validateur, mais utiliser l’identifiant ou le hash du bloc pour rapprocher les données entre différents validateurs ou différentes connexions.

Lors des prochaines étapes d’Alpenglow, la présence de plusieurs banques pour un même slot deviendra une composante normale du fonctionnement des validateurs.

L’exemple le plus clair est le transfert rapide entre leaders, l’un des composants d’Alpenglow qui sera déployé après l’activation initiale de Votor. Un leader peut commencer à construire de manière optimiste sur le parent qu’il pense voir accepté par le consensus. Si Votor décide au contraire que ce parent doit être ignoré, le leader peut changer de parent et reconstruire pendant le reste de sa fenêtre de leadership. En interne, cela revient à remplacer une banque par une autre pour le même slot. Agave contient déjà le mécanisme UpdateParent nécessaire pour représenter ce changement. Le transfert rapide entre leaders ne fait pas partie de l’activation initiale d’Alpenglow dans Agave 4.3 et devrait être déployé au cours de la version 4.4.

Une équivocation du leader peut produire globalement le même résultat. Si un leader signe et distribue deux blocs différents pour le même slot, les validateurs peuvent devoir temporairement conserver les deux candidats et les analyser. Différentes parties du réseau peuvent voir ces candidats dans des ordres différents, car Votor est asynchrone et les validateurs traitent les blocs, les votes, les certificats et les délais d’expiration locaux à mesure qu’ils les reçoivent.

Une modification récente a réduit MAX_ALTERNATE_BLOCKS_PER_SLOT de 11 à 6. Un validateur doit donc conserver au maximum sept blocs candidats pour un slot. Le consensus finit par ramener ces candidats à un historique unique. Avec Votor, la notarisation requiert plus de 60 % du stake. Deux blocs contradictoires ne peuvent pas tous deux obtenir des certificats de notarisation valides sans qu’une part importante du stake vote pour chacun d’eux. Selon l’hypothèse d’Alpenglow voulant que moins de 20 % du stake adopte un comportement byzantin, des certificats de notarisation contradictoires sont impossibles sans enfreindre les hypothèses de sécurité du protocole.

Pour les consommateurs de Geyser, l’enseignement pratique est simple : n’utilisez plus uniquement le slot comme clé de l’état transitoire. Les modifications de comptes, les transactions, les entrées et les métadonnées de blocs doivent être suivies par (slot, bank_id) jusqu’à ce que le consensus identifie la banque retenue. Si une autre banque apparaît pour le même slot, ses événements appartiennent à un état candidat distinct et ne doivent pas écraser silencieusement ceux de la première.

Tickets d’admission des validateurs

Les transactions de vote représentent actuellement le coût le plus élevé lié à l’exploitation d’un validateur Solana. Avec TowerBFT, les validateurs paient des frais de transaction standard à chaque vote soumis, pour un total d’environ 2 SOL par époque. Alpenglow remplace ces frais de transaction par des frais facturés une fois par époque aux validateurs admis dans l’ensemble de consensus actif, appelés Validator Admission Ticket (VAT).

Les fondations de cette transition sont déjà opérationnelles. L’enregistrement des clés publiques BLS, défini dans la SIMD-0387, a été activé sur le réseau principal en juillet, rapidement suivi par la fonctionnalité VAT, la SIMD-0357. Votor utilise des signatures BLS afin que les signatures de nombreux validateurs puissent être agrégées dans un seul certificat compact. Chaque validateur doit enregistrer une clé publique BLS dans son compte de vote avant de pouvoir participer à Alpenglow. Depuis l’activation de la fonctionnalité VAT, les validateurs qui n’en possèdent pas sont déjà exclus de l’ensemble de vote.

Avant Alpenglow, les validateurs continuent de soumettre des transactions de vote ordinaires et d’en payer les frais. À ce stade, VAT sert principalement de filtre d’admission. Les validateurs éligibles doivent disposer d’une clé BLS et figurer parmi les 2 000 validateurs admissibles ayant le stake le plus élevé. VAT prend effet lorsque Alpenglow est activé et que les transactions de vote disparaissent.

Une fois Alpenglow actif, l’admission est recalculée autour des limites d’époque. Le compte de vote d’un validateur doit contenir une clé BLS enregistrée et suffisamment de SOL pour couvrir le ticket ainsi que l’exemption de loyer. Si plus de 2 000 comptes sont admissibles, le système les classe selon leur stake et admet ceux qui en possèdent le plus. Le système prélève ensuite directement le coût du ticket sur le compte de vote de chaque validateur admis et l’envoie au compte incinérateur de Solana. Les validateurs doivent donc veiller à approvisionner leur compte de vote ; dans l’ancien système, les frais des transactions de vote étaient prélevés sur le compte d’identité du validateur.

Les propositions initiales d’Alpenglow et de VAT prévoyaient un ticket de 1,6 SOL par époque, soit environ 80 % des quelque 2 SOL qu’un validateur consacrait auparavant aux transactions de vote. Ce chiffre reposait sur l’objectif historique de Solana de slots de 400 millisecondes. La SIMD-0525 ajuste plutôt VAT en fonction de la durée des slots. Avec des slots de 200 millisecondes, le coût d’admission sera de 0,8 SOL.

VAT modifie également la destination de ce coût. Aujourd’hui, les frais de base de 5 000 lamports payés par une transaction de vote sont divisés en deux : 50 % sont brûlés et 50 % reviennent au leader du bloc. À l’inverse, VAT est intégralement envoyé à l’incinérateur. L’objectif général de VAT n’est toutefois pas de rendre SOL sensiblement plus déflationniste. Il s’agit de préserver un coût économique pour rejoindre l’ensemble de consensus après la disparition des frais liés aux transactions de vote.

Sécurité et préparation

Remplacer le protocole de consensus d’un réseau actif est une opération exceptionnellement risquée. Alpenglow bénéficie donc d’un processus de test et de migration beaucoup plus vaste qu’une activation classique de fonctionnalité Agave, comprenant notamment un cluster de test communautaire dédié et un programme de bug bounty.

Depuis mai, les opérateurs de validateurs exploitent un Alpenglow Community Cluster dédié, qui compte désormais plus de 100 nœuds. Les opérateurs utilisent du matériel de validation et des configurations réseau réels, ce qui permet de tester Alpenglow dans des conditions de dispersion géographique, de variations de latence, de configurations logicielles, de redémarrages et d’erreurs opérationnelles difficiles à reproduire dans des environnements contrôlés.

L’un de ses objectifs les plus importants est de tester Alpenswitch lui-même. Au lieu de vérifier uniquement si Votor fonctionne une fois qu’un cluster exécute déjà Alpenglow, les opérateurs ont testé à plusieurs reprises la transition de TowerBFT vers le nouveau système de consensus.

Roger Wattenhofer

@TheWattenhofer

We just had the first successful Alpenswitch on our Alpenglow community cluster! The @solana finalization time improved 100x. Thanks to everybody participating. Watch it live: https://ag.validblocks.com/ https://ag-community-status.stakingfacilities.com/

9 mai 2026, 6:59 PM

Alpenglow a également fait l’objet d’un examen adverse dédié. En août, Anza a lancé une Alpenglow Bug Bounty Competition de deux semaines, dotée d’une cagnotte pouvant atteindre 50 000 SOL. Contrairement au programme permanent d’Agave, cette compétition ciblait spécifiquement la nouvelle pile de consensus, notamment Votor, la vérification des signatures et certificats BLS, l’admission des validateurs et le parcours de migration de TowerBFT vers Alpenglow. La participation a été importante. Anza a annoncé plus de 300 soumissions et indiqué que plus de 25 000 SOL seraient distribués en primes.

La prise en charge de Frankendancer prendra fin avec l’arrivée d’Alpenglow. Frankendancer a toujours été conçu comme un client de transition, combinant les composants réseau et de production de blocs de Firedancer avec les composants d’Agave pour l’exécution et le consensus. La prise en charge du nouveau système de consensus dans cette architecture hybride ajouterait une importante charge de maintenance et de sécurité. L’équipe Firedancer concentre donc ses efforts sur le client Firedancer complet.

Les consignes communiquées aux validateurs indiquent que ni Frankendancer ni la version complète de Firedancer ne prendront en charge la courte fenêtre de migration de TowerBFT vers Alpenglow. Les opérateurs de Firedancer doivent donc prévoir un basculement vers un validateur Agave avant Alpenswitch, rester sur Agave pendant la transition, puis revenir à Firedancer une fois que le cluster fonctionne normalement avec Alpenglow.

Déroulement concret d’Alpenswitch

Alpenglow ne s’active pas partout à une heure arbitraire. Une fois sa fonctionnalité activée, le protocole définit une limite de migration 5 000 slots plus tard. TowerBFT continue de fonctionner pendant que les validateurs franchissent cette limite et recherchent un bloc confirmé avec une robustesse suffisante. Les validateurs signent ensuite avec BLS le bloc de genèse Alpenglow sélectionné et se transmettent directement ces votes de genèse.

Le transfert intervient lorsqu’au moins 82 % du stake a signé le même bloc de genèse, produisant ainsi le certificat de genèse Alpenglow. Les validateurs qui reçoivent et vérifient ce certificat désactivent TowerBFT au-delà du bloc de genèse et initialisent Votor à partir de l’état convenu. Le certificat se propage ensuite dans l’ensemble des validateurs, faisant franchir la limite aux nœuds restants.

Ce certificat offre aux opérateurs d’infrastructure un moyen pratique de déterminer de quel côté d’Alpenswitch se trouve un cluster.

Agave 4.3 introduit une nouvelle méthode RPC getAgGenesisCert. Avant la migration, un nœud Agave 4.3 renvoie null. Après le basculement du cluster, il renvoie le certificat de genèse Alpenglow, qui comprend le bloc de genèse et la signature BLS agrégée. Un nœud plus ancien qui ne prend pas en charge cette méthode renvoie plutôt Method not found. Le CLI expose les mêmes informations via : solana alpenglow-genesis-info.

Pour les validateurs, les fournisseurs RPC et les autres infrastructures qui doivent réagir à la migration, il est donc préférable de vérifier la présence du certificat de genèse plutôt que de supposer qu’Alpenglow est devenu actif à un instant précis.

Nouveaux appels système cryptographiques

Agave 4.3 enrichit également la boîte à outils cryptographique de la SVM avec de nouvelles primitives d’exécution pour les opérations dont le coût est prohibitif lorsqu’elles sont effectuées directement en sBPF.

Les deux ajouts notables sont le hachage SHA-512 et l’exponentiation modulaire de grands entiers. Tous deux sont additifs et contrôlés par une fonctionnalité : les programmes existants ne sont pas affectés, tandis que ceux qui choisissent de les utiliser peuvent déléguer les calculs cryptographiques coûteux à des implémentations natives optimisées dans l’environnement d’exécution du validateur.

Exponentiation modulaire de grands entiers

La SIMD-0529 : appel système ModExp pour grands entiers introduit sol_big_mod_exp, un appel système permettant de calculer :

result = (base ^ exponent) mod modulus

L’exponentiation modulaire est une opération fondamentale pour la vérification des signatures RSA, les accumulateurs cryptographiques, certaines fonctions de délai vérifiables et d’autres protocoles de théorie des nombres. L’implémenter directement dans un programme SVM avec une arithmétique d’entiers à précision arbitraire consomme énormément de ressources de calcul, en particulier avec les tailles de clés RSA courantes de 2 048, 3 072 et 4 096 bits.

Le nouvel appel système transfère les calculs coûteux vers l’environnement d’exécution du validateur. Les programmes fournissent la base, l’exposant et le modulo sous forme d’entiers non signés en petit-boutiste, puis reçoivent le résultat dans une zone mémoire fournie par l’appelant. Chaque opérande est initialement limité à 512 octets, ce qui suffit pour prendre en charge des entiers allant jusqu’à 4 096 bits.

Le cas d’usage le plus évident est la vérification RSA. Par exemple, un programme qui vérifie une signature RSA classique peut invoquer sol_big_mod_exp avec l’exposant public courant 65537, au lieu d’implémenter lui-même l’exponentiation de grands entiers. L’appel système se limite volontairement à la primitive arithmétique : les programmes restent responsables du hachage, du remplissage RSA tel que PKCS#1 v1.5 ou PSS, de la validation des clés et de toute séparation de domaine propre au protocole.

Il peut également effectuer efficacement une réduction modulaire de grands entiers. Avec un exposant de 1, l’opération se réduit à :

base mod modulus

Les programmes disposent ainsi d’une primitive native pour réduire des entiers dépassant les tailles de mots machine intégrées à la SVM, sans supporter le coût d’une implémentation générique des grands entiers.

L’approche est similaire dans son principe au précompilé ModExp d’Ethereum introduit par EIP-198, et son modèle de comptabilisation du calcul suit la formule de complexité opérationnelle d’EIP-198. Elle n’est toutefois pas compatible octet par octet avec Ethereum. Solana expose cette fonctionnalité via une ABI d’appel système native, utilise des entrées en petit-boutiste et exige que le modulo soit un entier impair supérieur à un ; les modulos pairs sont rejetés.

Cela rend l’appel système particulièrement utile pour l’interopérabilité, sans obliger Solana à adopter l’interface de précompilation de l’EVM. Les programmes qui vérifient des preuves, des signatures ou des attestations fondées sur des hypothèses cryptographiques de type Ethereum peuvent réutiliser la même arithmétique sous-jacente en adaptant la manière de l’invoquer.

SHA-512

Le second ajout est nettement plus simple, mais immédiatement utile.

La SIMD-0512 : appel système Sha512 ajoute sol_sha512, offrant aux programmes onchain un accès direct à la fonction de hachage SHA-512 via l’environnement d’exécution du validateur. Son interface reprend celle des appels système sol_sha256, sol_keccak256 et sol_blake3 existants de Solana et renvoie le condensé SHA-512 standard de 64 octets.

SHA-512 est notamment l’une des primitives fondamentales utilisées par Ed25519, le schéma de signature que Solana utilise elle-même de manière intensive. Agave et Firedancer dépendent déjà tous deux de SHA-512 en interne, mais avant cette modification, les programmes SVM ne pouvaient pas accéder directement à cette implémentation optimisée. Un programme nécessitant SHA-512 devait donc implémenter l’algorithme dans le logiciel.

La différence est considérable en matière de calcul. Selon l’estimation de la SIMD, le hachage d’une entrée courte avec une implémentation sBPF coûte des milliers de CU, tandis que la même opération via l’appel système coûte moins de 100 CU. sol_sha512 utilise le même modèle général de coût de calcul que l’appel système SHA-256 existant de Solana.

Ensemble, ces deux appels système prolongent une tendance plus large de la SVM : déplacer les primitives cryptographiques courantes mais coûteuses en calcul hors des programmes individuels, vers des opérations d’exécution standardisées et mesurées. Les programmes continuent de définir le protocole cryptographique de haut niveau, mais le validateur peut exécuter les briques coûteuses bien plus efficacement qu’une implémentation sBPF.

Conclusion

La principale évolution d’Agave 4.3 est Alpenglow, qui remplace TowerBFT par Votor, supprime les transactions de vote des blocs, fait passer la finalité de plusieurs secondes à quelques millisecondes et transforme la manière dont les validateurs et les infrastructures interagissent avec le consensus.

Pour la plupart des utilisateurs et des développeurs d’applications, une grande partie de cette transition sera invisible. Pour les validateurs, les fournisseurs RPC, les indexeurs et les équipes d’infrastructure, Agave 4.3 marque toutefois le début d’une transformation majeure de la manière dont Solana parvient au consensus.

Ressources complémentaires

• Livre blanc Alpenglow v1.2 (juillet 2026)
• Calendrier de publication d’Agave 4.3
• Calendrier de suivi des fonctionnalités
• Journal des modifications d’Agave 4.3
• Pull requests d’Agave 4.3
• Mise à niveau Alpenglow - Solana Foundation