Le réseau Solana continue de fournir des mises à niveau majeures de protocole à mesure que le réseau évolue avec une demande croissante. Cette page est une feuille de route technique des fonctionnalités clés prévues pour les prochaines versions. Les numéros de version et les délais sont susceptibles de changer à mesure que le développement progresse.
Dernière mise à jour le 3 février 2026
Compte de vote V4
STATUT: 🟡 En cours de développement. Attendu par Agave 3.1
Les comptes de vote sont la manière dont les validateurs participent au mécanisme de consensus de Solana. Actuellement, les comptes de vote utilisent l’espace de manière inefficace : plus de 40 % des comptes stockent un historique des électeurs autorisés précédents, ce qui est rarement nécessaire. Vote Account V4 modernise cette structure pour la rendre plus simple et plus flexible.
La mise à niveau supprime le suivi historique inutile et introduit des paramètres de commission distincts pour différents types de revenus des validateurs. Cela signifie que les validateurs peuvent définir un taux de commission pour les récompenses inflationnistes et un taux différent pour les revenus globaux provenant des frais de transaction. Vote Account V4 est une exigence fondamentale pour d’autres fonctionnalités à venir, en particulier le blocage de la distribution des revenus aux délégants et à Alpenglow.
Réduction de loyer
STATUT: 🟡 En cours de développement. Attendu par Agave 4.0
Le protocole Solana exige une caution de loyer à chaque ouverture de compte. Le terme loyer est un abus de langage : la caution est en réalité une caution remboursable qui est récupérée à chaque fermeture du compte. Le coût du loyer est indiqué en lamports par octet. La réduction du loyer réduira progressivement les lamports par octet dans une série d’activations de fonctionnalités, permettant de créer de nouveaux comptes Solana avec un montant de loyer réduit. Cela rend plus abordable pour les développeurs la création d’applications et pour les utilisateurs l’interaction avec le réseau, réduisant potentiellement les coûts jusqu’à 90 %.
Lueur alpine
STATUT: 🟡 En cours de développement. Attendu par Agave 4.1
Suivez les progrès sur Github.
Alpenglow est un protocole de consensus de pointe qui apportera des temps de confirmation de 150 ms à Solana. Les fonctionnalités de protocole existantes telles que la preuve d’historique (PoH) et les transactions de vote en chaîne seront supprimées pour faire place à un mécanisme plus simple dans Alpenglow. Cela représente une simplification fondamentale de la manière dont le réseau s’accorde sur les blocs, améliorant considérablement la fiabilité tout en réduisant considérablement les délais de confirmation.
Alpenglow introduit le concept de TVA (Validator Admission Ticket). La TVA est une taxe de 1,6 SOL que les validateurs doivent payer pour être inclus dans le consensus fixé à chaque époque. Avec l’introduction de la TVA, Alpenglow ouvre la voie à des temps de blocage plus rapides et à une capacité accrue des CU avec la suppression des transactions de vote des blocs.
SIMD-123 : Bloquer la distribution des revenus
STATUT: 🟡 En cours de développement. Attendu par Agave 4.1
Suivez les progrès sur Github.
Lorsque vous déléguez SOL à un validateur, vous ne recevez actuellement que les récompenses de l’inflation dans le protocole. Mais les validateurs gagnent également des revenus grâce aux frais de transaction, aux frais de priorité et à la MEV (valeur maximale extractible) lorsqu’ils produisent des blocs. SIMD-123 permet aux validateurs de partager automatiquement ces revenus de bloc avec leurs délégants via le protocole.
Les validateurs pourront fixer un taux de commission pour les revenus de bloc, de la même manière qu’ils fixent la commission pour les récompenses inflationnistes. Le protocole calculera et distribuera automatiquement les revenus restants aux délégants à la fin de chaque époque en fonction de leur mise. Cela crée plus de transparence et permet aux délégants de choisir des validateurs offrant de meilleures conditions de partage des revenus.
XDP (chemin de données eXpress)
STATUT: 🟢 Disponible en Agave 3.0+
En savoir plus sur la configuration de XDP.
XDP est une technologie réseau haute performance du noyau Linux qui permet aux validateurs Solana de traiter les paquets réseau plus rapidement. Considérez-le comme un raccourci qui contourne le traitement réseau normal, permettant aux données de circuler plus directement entre la carte réseau et le logiciel de validation. Cela réduit la latence jusqu’à 200x.
Agave version 3.0.9 et versions ultérieures prend en charge XDP pour la propagation de blocs, mais les validateurs doivent activer cette fonctionnalité. Les premiers tests montrent que 100 millions de blocs d’unités de calcul sont réalisables lorsque les opérateurs de validation adoptent XDP. Bien que XDP ne constitue pas un changement de protocole, il s’agit d’une amélioration critique des performances qui augmentera la capacité du réseau.
100 millions d’UC (unités de calcul)
STATUT: 🟡 En cours de développement. Attendu par Agave 4.1
Suivez les progrès sur Github.
Les blocs de Solana ont une limite de capacité mesurée en unités de calcul (CU). Chaque transaction consomme un certain nombre d’UC en fonction de sa complexité. La limite actuelle est de 60 millions d’UC par bloc.
SIMD-286 propose d’augmenter cette limite à 100 millions d’UC, soit une augmentation de capacité de 66 %. Cela signifie plus de transactions par bloc, un débit plus élevé et une réduction de la congestion pendant les pics de demande.
SIMD-296 : taille de transaction plus grande
STATUT: 🟡 En cours de développement. Attendu par Agave 4.1
Suivez les progrès sur Github.
Les transactions sur le réseau Solana sont actuellement limitées à un maximum de 1 232 octets. Cette limitation restreint la capacité des programmes à composer les uns avec les autres, car les transactions doivent contenir une quantité spécifique de données. Les transactions plus volumineuses permettent des opérations plus complexes en une seule transaction, réduisant ainsi le besoin de modèles d’exécution en plusieurs étapes difficiles.
Les ingénieurs principaux ont accepté le SIMD-296 pour permettre des transactions plus expressives pouvant interagir avec davantage de programmes et de comptes en une seule opération atomique.
SIMD-268 : Augmenter la limite d’imbrication de l’IPC
STATUT: 🟡 En cours de développement. Attendu par Agave 4.1
Suivez les progrès sur Github.
L’invocation inter-programmes (CPI) est la façon dont les programmes Solana appellent d’autres programmes pendant l’exécution. La profondeur d’imbrication maximale actuelle est de 4 niveaux, ce qui signifie qu’un programme peut appeler un autre programme, qui en appelle un autre, jusqu’à 4 niveaux de profondeur. Cela limite la sophistication des interactions multi-programmes.
SIMD-268 augmente la limite d’imbrication de 4 à 8, doublant ainsi la profondeur des appels de programme à programme. Cela permet aux développeurs de créer des applications décentralisées plus complexes qui composent ensemble plusieurs protocoles.