Solana v1 – Les transactions expliquées : limites de taille et changements majeurs

Quicknode

1er septembre 2026 — 10 min de lecture

Partager

Ajouter comme source préférée

Les développeurs qui créent des applications complexes sur Solana ont passé des années à contourner la limite de taille des transactions. La version v0 a introduit des tables de recherche d'adresses, permettant à une transaction de référencer davantage de comptes sans dépasser 1 232 octets. La dernière mise à jour introduit les transactions v1, qui multiplient par 3,3 cette limite.

La version v1 de « Transaction » porte la taille maximale des transactions sérialisées de 1 232 octets à 4 096 octets ; cette mise à jour sera activée avec la version v4.2 d’Agave début septembre 2026. Pour les équipes qui développent des applications « zero-knowledge » (ZK), des systèmes multisignature et des primitives DeFi complexes, cet espace supplémentaire élimine toute une catégorie de solutions de contournement.

Il n'est pas nécessaire d'adopter la version 1 pour en subir les conséquences. Tout ce qui lit des données de type « Solana » est concerné, qu'il envoie ou non des transactions en version 1.

La limite de 1 232 octets provenait du protocole UDP. Solana a transféré le traitement des transactions vers QUIC il y a plusieurs années, ce qui a supprimé cette contrainte. La limite est toutefois restée en place. Les équipes ont continué à fractionner les transactions, à mettre en place des tables de correspondance et à s'adapter à un plafond qui ne correspondait plus au protocole de transport sous-jacent.

Cette nouvelle limite ne repose pas sur une contrainte liée au réseau. La valeur de 4 096 octets correspond à la taille des pages de mémoire des validateurs. Cela permet d’accueillir les preuves ZK, les schémas de signature BLS, les transferts confidentiels, les demandes de mise à jour des prix par oracle, ainsi que d’intégrer davantage d’instructions dans une seule transaction sans avoir recours à des schémas de regroupement. Cela permet également d’intégrer en ligne un ensemble complet de 64 comptes, ce qui explique pourquoi la v1 supprime totalement les tables de recherche d’adresses.

Qu'est-ce qu'une transaction « Solana » v1 ?

Une transaction v1 est un nouveau format de transfert de données « Solana » dont la taille maximale est de 4 096 octets. Il ne s'agit pas d'une version v0 dotée d'une limite plus élevée ; cinq modifications les distinguent :

• Octet de version 0x81 est situé à l'offset zéro ; ainsi, tout utilisateur identifie le format à partir d'un seul octet

• Les signatures sont désormais placées à la fin de la transaction, et non plus avant le message.

• Largeur fixe u8 Les comptes remplacent le codage Compact-U16

• Les en-têtes d'instructions sont regroupés avant leurs données utiles, ce qui permet de calculer directement leurs limites

• Les limites de ressources sont transférées dans un masque de configuration d'en-tête

Les tables de correspondance d'adresses ont disparu

La prise en charge des tables de recherche d'adresses a été supprimée dans la version 1. Chaque compte est désormais transmis en ligne sous la forme d'une clé publique complète de 32 octets, et un ensemble maximal de 64 adresses occupe 2 048 octets, soit la moitié de la nouvelle enveloppe avant même qu'une seule instruction ne soit ajoutée.

Solana a évalué le coût sur l'ensemble du trafic mainnet . Environ 62 % des transactions v0 font référence à au moins une table de recherche. Une fois converties en v1, la moitié d'entre elles présentent un excédent inférieur à 420 octets et 90 % un excédent inférieur à 1 400 octets. Les transactions qui faisaient référence à plusieurs tables pour extraire chacune une poignée d'adresses deviennent plus légères, car la surcharge liée aux tables coûtait plus cher que le gain de compression obtenu.

La suppression des tables de correspondance simplifie également l'intégration des validateurs. La version v0 impose une résolution des tables en fonction de l'état avant même qu'un validateur ne sache quels comptes sont concernés par une transaction. La version v1 transmet l'ensemble complet des comptes contenus dans la transaction elle-même, ce qui permet de calculer les frais et la priorité plus tôt.

Ce que permettent d'acheter ces octets supplémentaires

Les applications riches en charge utile gagnent en capacité, car les preuves et les données d’instruction consomment des octets sans occuper d’emplacements de compte. Les applications gourmandes en comptes, notamment celles impliquant un routage multi-plateformes et une composition de protocoles étendue, consacrent la majeure partie de cet espace supplémentaire à réintégrer les adresses que les tables de correspondance utilisaient auparavant pour la compression. Pour ces équipes, la limite de 64 comptes constitue désormais la contrainte déterminante, et le maintien de la version v0 est un choix raisonnable.

Les octets constituent la seule limite imposée par la version 1. Le nombre de comptes reste fixé à 64, celui des instructions à 64 et celui des signatures à 12.

Quels problèmes peuvent survenir lors de la lecture des données « Solana » ?

Les applications qui lisent ou indexent les données « Solana » échouent dès la première apparition d'une transaction v1 dans un bloc qu'elles interrogent. Le code chargé de lire une transaction depuis le début rencontre des données de message à l'endroit où les signatures « legacy » et « v0 » sont placées ; par conséquent, il n'est pas possible de corriger l'analyseur en augmentant la limite de longueur.

Les méthodes `getBlock` et `getTransaction` rejettent les transactions de la version 1

Un appel qui n'a pas déclaré la prise en charge de la version 1 renvoie une erreur -32015 dès qu’elle en rencontre une, et la lecture de l’ensemble du bloc échoue. Les indexeurs et les tâches de remplissage s’arrêtent au lieu de passer outre la transaction qu’ils ne parviennent pas à analyser. Définir maxSupportedTransactionVersion : 1 dans les deux appels, sous la forme d’un entier JSON 1. La chaîne "1" échoue, tout comme 0, de sorte que le code qui a opté pour la prise en charge de la version v0 lors de son déploiement n'est pas encore pris en charge. getSignaturesForAddress n'est pas affecté, car il n'examine jamais le corps des transactions.

L'appel qui échoue :

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBlock",
    "params": [402184291, { "encoding": "json" }]
}

Le même appel, corrigé. Le codage Base64 est obligatoire en plus du paramètre « version », car le codage Base58 ne permet pas d'encoder une transaction de plus de 1 232 octets :

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBlock",
    "params": [
        402184291,
        {
            "encoding": "base64",
            "maxSupportedTransactionVersion": 1
        }
    ]
}

blockSubscribe cesse d'avancer

blockSubscribe émet null et se bloque lorsqu'il atteint une transaction v1, sans qu'aucune erreur ne soit détectée. La surveillance basée sur les taux d'erreur ne se déclenche jamais, de sorte que l'abonnement se bloque au premier créneau v1 et y reste. Définir maxSupportedTransactionVersion : 1 concernant l'abonnement, traiter bloc : null comme un échec plutôt que comme un bloc vide, et ajouter un contrôle de validité, car rien d'autre ne le mettra en évidence.

L'analyse de ComputeBudget renvoie des zéros

La version 1 a déplacé les limites de calcul et les frais prioritaires des instructions vers une configuration au niveau du message. Les indexeurs qui recherchent des instructions « ComputeBudget » ne trouvent rien et écrivent des zéros dans tous les jeux de données en aval sans générer d'erreur à aucun niveau. Lisez plutôt les limites dans la configuration de la transaction. Elles sont incluses dans le message pour les réponses avec option d'adhésion et sont totalement absentes pour les versions héritées et la version 0. Les champs non définis sont renvoyés. null:

"message": {
    "instructions": ["… no ComputeBudget instruction here …"],
    "recentBlockhash": "GsdgFbNBoZmAB5uPHfk2xUFYyM4Wg2hYZBfBrxrqjxfF",
    "transactionConfig": {
        "computeUnitLimit": 30000,
        "heapSize": null,
        "loadedAccountsDataSizeLimit": 200000,
        "priorityFee": null
    }
}

Les regroupements de frais prioritaires sont interrompus en cas de changement d'unité

Les versions « Legacy » et « v0 » expriment les frais en micro-lamports par unité de calcul. La version « v1 » les exprime sous forme de montant total absolu en lamports. Pour afficher les deux valeurs sur un même tableau de bord, il suffit de multiplier le prix de la version « v0 » par le nombre d'unités de calcul demandé par la transaction, puis de diviser le résultat par 1 000 000 :

20 000 CU × 250 000 micro-lamports/CU = 5 000 lamports   // v0
                                        5 000 lamports   // équivalent v1

Si on ne tient pas compte de la conversion, les totaux n'ont aucune signification.

Les streams s de Geyser ne sont soumises à aucune restriction liée à la version

Les utilisateurs de services de streaming n'ont pas d'équivalent à maxSupportedTransactionVersion et il n'y a aucun moyen de désactiver cette fonctionnalité. Mettez à jour le plugin Geyser de Yellowstone vers la version 15.1.1 et régénérez les stubs Protobuf à partir de la version 12.6.0 ou ultérieure, qui ajoute le Message.config champ. Un consommateur « obsolète » ne génère pas d'erreur sur la version v1. Il interprète la transaction comme la version v0 avec un budget de calcul vide.

Détecter la version de manière structurelle sur Message.config, et vérifiez dans cet ordre :

L'ordre a son importance, car avec gestion des versions Cela vaut aussi bien pour v0 que pour v1. Lors du test, chaque transaction v1 est classée comme v0, sans message d'erreur, avec un budget de calcul remis à zéro.

function messageVersion(message: Message): "legacy" | "v0" | "v1" {
    if (message.config !== undefined) {
        return "v1";
    }
    return message.versioned ? "v0" : "legacy";
}

config Il s'agit d'un sous-message, et les champs des sous-messages comportent toujours une présence explicite dans proto3 ; cette vérification s'applique donc quelle que soit la manière dont un décodeur gère les valeurs par défaut.

Les anciennes versions d'Yellowstone passent de la version 1 à la version 0

Yellowstone Les versions du plugin Geyser antérieures à la 15.1.1 convertissent les transactions v1 en une représentation v0 avant leur transmission. Le flux continue de fonctionner, mais les données qu’il fournit ne correspondent plus à celles qui ont été exécutées sur la chaîne. Effectuez une mise à jour vers la version 15.1.1 ou une version ultérieure, et tenez compte de cet écart dans tout ce qui a permis de rapprocher les données du flux avec l’état de la chaîne lors de l’exécution d’une version antérieure.

Problèmes rencontrés lors de l'envoi de transactions v1

Les défaillances mentionnées ci-dessus surviennent que l'equipe e adopte ou non la version v1. Ce n'est pas le cas ici. Aucun des événements ci-dessous ne se produit tant qu'une application n'a pas elle-même créé et soumis une transaction v1 ; chaque élément correspond à une modification de la manière dont une transaction est construite, et non de la manière dont elle est lue. Les transactions héritées et v0 continuent de fonctionner sans changement à 1 232 octets ; l'envoi d'une transaction v1 est donc une décision qui dépend de la capacité. Une transaction nécessitant plus de 1 232 octets n'a pas d'autre choix.

Si aucune limite de ressources n'est définie, la valeur par défaut est zéro.

Les versions Legacy et v0 reviennent par défaut à 200 000 unités de calcul par instruction et à 64 Mio de données de comptes chargées lorsqu'une transaction ne précise rien. La version v1 revient par défaut à zéro et fait échouer la transaction. Chaque transaction v1 définit explicitement une limite d'unités de calcul et une limite de taille des données de comptes chargées. Dans @solana/kit 8.0 : ces éléments sont déplacés des instructions ComputeBudget vers la configuration des messages :

import { setTransactionMessageConfig } from '@solana/kit';

const message = setTransactionMessageConfig(
    {
        computeUnitLimit: 20_000,
        loadedAccountsDataSizeLimit: 64 * 1024,
        priorityFeeLamports: 5_000n,
    },
    baseMessage,
);

Mesurez les deux limites à partir d'un passage de simulation en réglant chacune d'elles au maximum, puis notez la valeur renvoyée unitésConsommées et taille des données des comptes chargées Retour à la configuration. Arrondissez la taille des données à la page de 32 KiB supérieure. Le modèle de tarification par bloc facture par pages de 32 KiB ; l'espace restant en dessous de la limite supérieure est donc gratuit.

Prévoyez une marge supérieure à ce qu’indique la simulation. Le chargement d’un compte qui n’existe pas ne coûte rien, mais une fois créé, il occupe 64 octets, auxquels s’ajoutent ses données ; par conséquent, une limite fixée exactement en fonction de la simulation entraînera un échec avec le message La taille maximale des données des comptes chargés a été dépassée si le compte apparaît avant que la transaction ne soit enregistrée.

Les instructions ComputeBudget deviennent des opérations nulles

La version v1 les accepte, facture 150 unités de calcul pour chacune d’entre elles et les ignore lors de la configuration. Une transaction contenant des instructions ComputeBudget mais aucune configuration de message passe la validation et s’exécute ensuite sans aucune limite. Il convient de les supprimer complètement des générateurs v1. La configuration du message les remplace, et chacune d’entre elles qui subsiste occupe un emplacement d’instruction parmi les 64 disponibles et consomme 150 unités de calcul pour ne rien faire.

Frais de priorité

La version v1 définit les frais prioritaires sous la forme d'un total absolu de Lamport. Le calcul des « micro-Lamports par unité de calcul » de la version v0 n'est pas repris. La valeur est de type `bigint`, et la méthode de définition est rejetée lors de la compilation pour les messages hérités et ceux de la version v0 :

import { setTransactionMessagePriorityFeeLamports } from '@solana/kit';

const message = setTransactionMessagePriorityFeeLamports(5_000n, baseMessage);

Le codage Base58 est limité à 1 232 octets

Les transactions dépassant ce montant nécessitent encodage : « base64 » lors de la soumission. Les applications qui utilisent le codage Base58 en dur échouent lors des transactions volumineuses rendues possibles par la version 1.

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "sendTransaction",
    "params": [
        "<base64-encoded transaction>",
        { "encoding": "base64" }
    ]
}

Les adresses en double sont rejetées

Les versions « Legacy » et v0 acceptent la présence d'adresses de compte en double au sein d'une même transaction. La version v1 les rejette.

Quelles versions du client prennent en charge la version 1 ?

La prise en charge de la version 1 commence à @solana/kit 8.0.0, les crates Rust 4.2.x, Solders 0.29.0 et solana-go 1.23.0.

Le format v1 fonctionne dès aujourd'hui sur un validateur local sans nécessiter de « feature gate ». solana-test-validateur le prend en charge à partir de la version 4.2, Surfpool à partir de la version 1.5, et un Surfnet éphémère configuré pour SIMD-0296 propose une solution hébergée.

Quicknode Prise en charge de la version 1

Quicknode Les points de terminaison RPC et les API prennent en charge les transactions v1 dès leur activation. Aucune migration d'endpoint , modification de plan, indicateur de configuration ni ticket d'assistance n'est nécessaire.

Quicknode Le cluster Alpenglow traite d'ores et déjà les transactions v1; le format peut donc être testé sur une « endpoint » en production avant d'être déployé sur testnet. Le site Testnet est en attente de l'activation de la transaction V1 (SIMD-0385), prévue le mercredi 2 septembre 2026 à 10 h 30 UTC.

Le reste du travail se trouve dans le code de l'application. Passer maxSupportedTransactionVersion : 1 sur getTransaction et getBlock, effectuez une mise à jour vers l'une des versions client mentionnées ci-dessus, remplacez l'analyse des instructions ComputeBudget par la configuration des messages, harmonisez les unités de frais prioritaires entre les différents formats et passez à l'encodage Base64 pour les transactions dépassant 1 232 octets.