Solana adapte sa nouvelle limite de transaction de 4 096 octets à une seule page mémoire

Solana devrait tripler la quantité de données qu'une seule transaction peut transporter le 9 septembre. Ce nouveau plafond de 4 096 octets tient dans une seule page mémoire de 4 Kio du matériel de validation, conformément à la proposition SIMD-0296 sur GitHub.

Les charges de travail nécessitant plusieurs transactions s'exécutent désormais en un seul appel atomique.

QUIC a rendu la limite de 1 232 octets inutile

La limitation initiale de Solana était une mise en garde concernant le réseau. Ce dernier fonctionnait avec une MTU IPv6 de 1 280 octets.

Il restait donc 1 232 octets pour la charge utile d'une transaction après la surcharge du protocole, écrivent les auteurs de SIMD-0296. Cela se justifie lorsque chaque message devait traverser l'unité de transmission maximale (MTU) sans fragmentation.

Solana a adopté QUIC comme méthode standard de gestion des transactions en 2022. La RFC 9000 ne fixe pas de taille maximale pour les flux, ce qui permet aux charges utiles plus importantes de transiter sans problème au niveau du réseau.

La limite de 1 232 octets était devenue une règle sans fondement technique.

Les deux documents ont été rédigés par les ingénieurs d'Anza, Jacob Creech et Andrew Fitzgerald. SIMD-0296 relève la limite de taille.

Un document complémentaire, SIMD-0385, defile format de message v1, qui contient les octets supplémentaires. Ce duo résout une contrainte que les développeurs contournaient depuis le lancement de la chaîne.

La proposition privilégie une taille de 4 096 octets, supérieure à la taille maximale autorisée par QUIC, afin qu'une transaction puisse tenir dans une seule page standard de 4 Kio de mémoire du validateur. Aucune transaction ne dépasse la limite d'une page.

La gestion de la mémoire par transaction est peu coûteuse. Chaque transaction est limitée à une seule page.

Pour arriver à la limite de 4 096 octets, Creech et Fitzgerald ont analysé comment les développeurs utilisaient les bundles Jito pour contourner les anciennes restrictions :

• 50 % des paquets soumis avaient une taille de 2 048 octets ou moins.
• 65 % des données faisaient moins de 6 144 octets.
• 100% sont restés inférieurs à 9 216 octets.

Un plafond de 4 096 octets couvre la grande majorité de ces charges de travail multitransactionnelles en un seul appel tout en restant dans les limites de page matérielle du validateur.

Les appels RPC non préparés génèrent désormais l'erreur -32015 sur Solana

Cette capacité supplémentaire permet de traiter des charges de travail dépassant la limite de 1 232 octets.

Les preuves à divulgation nulle de connaissance, telles que celles utilisées dans les transfertsdentde Token Extensions, ont généré des charges utiles qui dépassaient la limite de 1 232 octets.

Pour résoudre ce problème, les développeurs enchaînaient plusieurs appels ou renonçaient aux transferts atomiques chiffrés. La nouvelle limite de 4 096 octets permet désormais d’effectuer des preuves à divulgation nulle de connaissance en une seule transaction.

L'agrégation de signatures BLS et les configurations multisignatures complexes bénéficient également de cette évolution. SIMD-0296 cite la multisignature imbriquée, type de multisignature utilisé par les trésoreries institutionnelles et les DAO via les Squads, comme l'un des principaux facteurs.

Il fait également référence aux signatures à usage unique de Winternitz et aux schémas BLS sur la chaîne qui fonctionnent sans précompilation.

Ce format abandonne les tables de correspondance d'adresses, utilisées par la version 0 pour référencer jusqu'à 64 comptes avec des index courts. Ces tables complexifient inutilement le système, car il utilise désormais 64 adresses de 32 octets intégrées, occupant seulement 2 048 octets, bien en deçà de la limite.

La limite de 64 comptes par transaction demeure sur le Solana . Les applications gourmandes en ressources atteindront toujours cette limite, même après la résolution du problème de la limite de données. réseau

Les bundles Jito permettent aux développeurs de fusionner jusqu'à cinq transactions en une séquence tout ou rien afin de résoudre le problème de la limitation en octets.

La transaction v1 permet d'obtenir le même résultat atomique en une seule transaction. Elle apporte l'atomicité native directement à la couche de base.

La version V1 est optionnelle pour les expéditeurs ; les transactions héritées et celles de la version V0 continuent donc de fonctionner. Solana de migration de la Fondation Les notes indiquent qu'il s'agit d'un changement majeur pour l'infrastructure qui lit les blocs.

Si les outils de données et les explorateurs de blocs ne sont pas mis à jour pour la nouvelle version de Solana, ils se bloqueront complètement ou afficheront des erreurs.

Lorsqu'une application tente de lire une transaction ou un bloc v1 sans le nouveau paramètre de version, les serveurs de Solanarejettent la requête avec un code d'erreur système -32015.

Les outils qui diffusent en continu des blocs en direct atteindront une nouvelle transaction v1, recevront une réponse complètement vide et resteront bloqués à ce stade.

Les indexeurs, ou outils qui enregistrent les données de transaction, affichent des frais de priorité nuls pour les nouvelles transactions car ils recherchent au mauvais endroit.

Auparavant, ces frais figuraient sur une liste spéciale intégrée à la transaction. Dans la nouvelle version, ces informations sont regroupées dans un encadré récapitulatif dédié.

Anza exige que les fournisseurs RPC passent à Agave v4.2. Helius a publié une liste de contrôle de migration détaillant les travaux à effectuer.

La transaction v1 a été activée sur le réseau de test Solana lors de l'époque 1025 le 1er septembre. Anza a officiellement programmé le déploiement sur le réseau principal pour le 9 septembre.