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

Solana est prêt à 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 KiB du matériel du validateur, selon la proposition SIMD-0296 sur GitHub.

Les charges de travail qui nécessitaient plusieurs transactions prennent désormais un appel atomique unique pour être complétées.

QUIC a rendu la limite de 1,232 octets inutile

La limite originale de Solana était une précaution réseau. Le réseau fonctionnait avec une MTU IPv6 de 1 280 octets.

Cela laissait 1 232 octets pour la charge utile d'une transaction après la surcharge du protocole, écrivent les auteurs de SIMD-0296. Cela a du sens lorsque chaque message devait passer par la MTU sans fragmentation.

Solana est passé à QUIC comme méthode standard de gestion des transactions en 2022. La RFC 9000 ne fixe pas de taille maximale de flux, de sorte que des charges utiles plus grandes peuvent passer sans aucun problème au niveau du réseau.

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

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

Un document compagnon, SIMD-0385, définit le format de message v1, qui contient les octets supplémentaires. La paire résout une contrainte que les développeurs contornaient depuis le lancement de la chaîne.

La proposition préfère 4 096 octets à la plus grande taille autorisée par QUIC afin qu'une transaction puisse tenir dans une seule page standard de 4 KiB de mémoire du validateur. Aucune transaction ne franchit jamais une limite de page.

La gestion de la mémoire par transaction est peu coûteuse. Chaque transaction est restreinte à 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 bundles soumis étaient de 2,048 octets ou moins.
• 65% était inférieur à 6,144 octets.
• 100% est resté inférieur à 9,216 octets.

Un plafond de 4 096 octets couvre la grande majorité de ces charges de travail multi-transactions en un seul appel tout en restant dans les contraintes de page du matériel du validateur.

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

La capacité supplémentaire permet aux charges de travail qui dépassent la limite de 1 232 octets.

Les preuves à divulgation nulle de connaissance, telles que celles utilisées dans les transferts confidentiels des 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 chiffrés atomiques. La nouvelle limite de 4 096 octets prend en charge les preuves à divulgation nulle de connaissance dans une seule transaction.

L'agrégation de signatures BLS et les grandes configurations multisig bénéficient également de ce changement. SIMD-0296 cite le multisig imbriqué, le type de multisig utilisé par les trésoreries institutionnelles et les DAO via Squads, comme l'un des principaux moteurs.

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

Le format évite les Address Lookup Tables, que v0 utilisait pour référencer jusqu'à 64 comptes avec des index courts. Les tables ajoutent de la complexité sans retour sur investissement car il y a maintenant 64 adresses inline de 32 octets, qui ne prennent que 2 048 octets, bien en dessous du plafond.

La limite de 64 comptes pour chaque transaction reste en place sur le réseau Solana. Les applications lourdes en comptes atteindront toujours la limite même si le problème du budget d'octets est résolu.

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

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

V1 est en option pour les expéditeurs, donc les transactions legacy et v0 continuent de fonctionner. Les notes de migration de la Solana Foundation indiquent qu'il s'agit d'un changement majeur pour les infrastructures qui lisent 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 figeront complètement ou généreront des erreurs.

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

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

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

Ils lisaient auparavant ces frais dans une liste spéciale à l'intérieur de la transaction. Dans la nouvelle version, cette information est conservée dans sa propre boîte de résumé dédiée.

Anza exige que les fournisseurs RPC mettent à niveau vers Agave v4.2. Helius a publié une liste de contrôle de migration détaillant le travail.

La transaction v1 a été activée sur le testnet de Solana pendant l'époque 1025 le 1er septembre. Anza a officiellement programmé le déploiement sur le mainnet pour le 9 septembre.