Solana préparerait un triplement de la taille maximale d'une transaction réseau, un changement de la limite de transaction de la blockchain qui donnerait aux applications davantage d'espace pour intégrer des opérations complexes dans une seule transaction. Selon le reportage sur la mise à niveau prévue, cette mesure concerne la quantité de données qu'une transaction unique peut transporter. Les limites exactes en octets, le statut de la proposition et le calendrier d'activation n'ont pas été confirmés.

Ce que l'augmentation de la taille des transactions changerait

Le changement porte sur la taille maximale d'une transaction Solana individuelle, mesurée en octets — et non sur le nombre de transactions que le réseau traite par seconde. Le triplement de ce plafond augmenterait la quantité de données d'instructions et de comptes qu'une transaction unique peut transporter.

Le reportage disponible ne fournit ni la limite actuelle en octets, ni la nouvelle valeur proposée, ni un identifiant de proposition, de sorte qu'aucun chiffre précis avant/après ne peut être avancé. Les paramètres du réseau Solana sont généralement modifiés via le processus des Solana Improvement Documents, dont les propositions ouvertes sont suivies publiquement.

Il est important de distinguer une enveloppe de transaction plus large d'un débit accru. Le triplement de la taille des transactions est différent d'une hausse du débit, de la capacité d'exécution ou de la capacité des blocs. Une enveloppe plus large n'augmente pas en soi le nombre de transactions par seconde ni les budgets d'unités de calcul ; elle modifie uniquement la quantité de données pouvant être encodée dans une seule transaction. Pour les lecteurs qui suivent les changements de protocole entre écosystèmes, ce type d'ajustement de paramètres s'inscrit parmi les autres travaux de capacité réseau sur les chaînes à contrats intelligents — par exemple, l'utilisation historique par Ethereum de limites de gaz par bloc et de la tarification des calldata pour gérer la quantité de données consommées par les transactions — même si chaque chaîne définit et gouverne ces paramètres différemment.

Comment des transactions plus grandes pourraient prendre en charge des opérations plus complexes

Une enveloppe de transaction plus grande pourrait, en principe, permettre à une application d'intégrer davantage d'instructions liées aux échanges ou de références de comptes dans une seule transaction, sous réserve de la conception finale du changement. C'est l'avantage pratique que le reportage associe à cette augmentation de taille, même si aucune application, référence ou déclaration de développeur n'a été citée.

À titre hypothétique, un swap multi-étapes ou un ensemble d'opérations combinées qui doit aujourd'hui être réparti sur plusieurs transactions pourrait potentiellement tenir en une seule. Cela compte pour la composabilité : lorsque des opérations liées doivent être scindées en transactions distinctes, elles peuvent échouer indépendamment, ce qui constitue un problème de longue date pour les workflows on-chain complexes. Cela reste purement illustratif ; aucun workflow confirmé n'a été démontré. Solana concentre déjà une activité intense de routage d'échanges via des plateformes comme Raydium et Jupiter — le type d'applications qu'une enveloppe plus large concernerait le plus directement.

Autres limites à la complexité des transactions

La taille des transactions n'est qu'une seule contrainte parmi d'autres. Les limites d'exécution, telles que les budgets d'unités de calcul et les règles d'accès aux comptes, bornent également la complexité d'une transaction, et le reportage ne précise pas si ces limites changeraient en même temps que l'augmentation de taille.

Ce changement ne doit pas être interprété comme la promesse de frais plus bas, de meilleurs prix ou d'un slippage réduit ; aucun de ces effets n'est corroboré par les éléments disponibles.

Ce qui reste à confirmer concernant le déploiement

Aucun calendrier, aucune condition d'activation, aucune version client ni confirmation mainnet n'a été fourni pour ce changement. La spécification technique, le statut de la proposition, la portée de la mise en œuvre et la date d'activation restent tous non vérifiés.

Il n'est pas non plus confirmé que les outils applicatifs ou le code de construction des transactions devraient être mis à jour pour utiliser une enveloppe plus large, et aucune mesure de performance ou de compromis sur les ressources n'est disponible. Tant qu'une proposition précise et une version client n'ont pas été identifiées, l'information décrit un plan rapporté plutôt qu'une mise à niveau déployée.