Transazioni Solana da 4.096 byte: cosa cambia con v1

Aggiornato all’8 settembre 2026. Le transazioni v1 sono attive su testnet e devnet, non ancora su Solana mainnet.

Le transazioni Solana potranno crescere da 1.232 a 4.096 byte grazie al nuovo formato v1. Lo spazio aggiuntivo consente di inserire in una sola operazione prove zero-knowledge, multisig più grandi e batch che finora dovevano essere spezzati. Non significa che throughput o velocità della rete triplichino automaticamente.

L’upgrade richiede modifiche concrete a wallet, indexer, RPC e servizi che sponsorizzano le commissioni. Le applicazioni legacy e v0 continuano a funzionare, ma chi legge i blocchi senza dichiarare il supporto a v1 rischia errori quando il formato raggiungerà mainnet.

Transazioni Solana: da 1.232 a 4.096 byte

La pagina ufficiale dell’upgrade Solana descrive un limite 3,3 volte maggiore. Il vecchio tetto derivava dalla dimensione prudente dei pacchetti di rete; con l’uso di QUIC è possibile trasportare transazioni distribuite su più frame.

Il limite resta a 4 KiB per contenere pressione sulla memoria e ritrasmissioni. Una transazione più grande usa più banda e può essere più costosa da propagare. Aumentare la dimensione massima crea capacità per casi complessi, non risorse gratuite per ogni utente.

Il formato v1 inserisce configurazioni di risorse direttamente nel messaggio e sposta le firme. Il primo byte consente all’infrastruttura di riconoscere la versione prima di decodificare tutto il contenuto. Legacy e v0 mantengono invece il tetto di 1.232 byte.

Cosa diventa possibile in una sola transazione

Una prova ZK o una multisig istituzionale può richiedere dati e firme che non entrano nel formato precedente. Gli sviluppatori dovevano dividere il flusso in più transazioni, usare tabelle di indirizzi o affidarsi a bundle. Ogni passaggio aggiunge conferme, firme e possibilità di fallimento intermedio.

Con v1 alcune operazioni potranno essere atomiche: o l’intero insieme viene eseguito, oppure nessuna parte modifica lo stato. Questo è utile per Confidential Transfers, schemi di firma avanzati e azioni coordinate tra più programmi.

Più spazio non elimina i limiti logici. V1 mantiene un massimo di 64 indirizzi di account e 64 istruzioni, e richiede budget espliciti. La complessità applicativa deve quindi essere progettata, non soltanto compressa in un contenitore più grande.

Perché indexer ed explorer devono aggiornarsi

Chi usa getTransaction o getBlock deve impostare maxSupportedTransactionVersion a 1. Senza questa dichiarazione, una transazione v1 può generare l’errore di versione non supportata; nel caso di getBlock, una sola operazione sconosciuta può far fallire la lettura dell’intero blocco.

Il changelog Solana del 27 agosto invita i team a prepararsi. Il rischio SEO più interessante per sviluppatori è concreto: un indexer non aggiornato può apparire funzionante fino al primo blocco con v1, per poi smettere di avanzare o produrre dati incompleti.

I flussi Geyser e gRPC devono rigenerare gli stub compatibili. Anche decoder e archivi devono riconoscere il prefisso v1. La nostra analisi sui validatori Solana e gli interventi su Agave offre il contesto sulla necessità di aggiornare l’infrastruttura insieme al protocollo.

Compute budget e priority fee cambiano posizione

Nel formato v1, compute unit limit, dimensione dei dati caricati, heap e priority fee vivono in transactionConfig. Leggere soltanto le vecchie istruzioni ComputeBudget può restituire valori pari a zero senza un errore evidente, producendo statistiche sbagliate.

Anche l’unità della priority fee cambia: in v1 è un totale in lamport, mentre nel formato precedente si usa un prezzo in micro-lamport per compute unit. Copiare la vecchia moltiplicazione può quindi calcolare o applicare una commissione errata.

Le applicazioni che inviano v1 devono impostare esplicitamente i limiti di calcolo e dati. I valori predefiniti sono zero, quindi una transazione costruita senza configurazione può fallire prima dell’esecuzione. La simulazione serve a stimare le risorse con margine adeguato.

Address Lookup Tables e account

V1 non usa Address Lookup Tables. Dispone di spazio sufficiente per includere fino a 64 indirizzi direttamente nel messaggio, eliminando una dipendenza utile in v0 ma aggiungendo byte alla transazione. Gli indirizzi duplicati non sono ammessi.

Il cambiamento semplifica alcuni flussi e rende il contenuto più autonomo. Non rende però equivalenti tutti i sistemi già costruiti su v0: SDK, wallet e programmi devono scegliere il formato adatto e gestire entrambi durante la transizione.

Il supporto compare nelle nuove versioni delle librerie, tra cui Anza Kit. Usare una versione che sa soltanto leggere v1 non significa automaticamente poterla costruire e inviare; la matrice di compatibilità va controllata per linguaggio e client.

Stato dell’attivazione mainnet

Secondo la pagina ufficiale, il feature gate è attivo su testnet e devnet, mentre mainnet risulta ancora non attivo. La pianificazione punta ad Agave 4.2, ma il calendario viene definito esplicitamente come provvisorio e può cambiare.

Gli utenti normali non devono intervenire: le transazioni legacy e v0 continuano a operare. La responsabilità immediata riguarda sviluppatori, servizi RPC, explorer, indexer, relayer e chi sponsorizza fee o co-firma operazioni.

Non è corretto scrivere che Solana ha già triplicato ogni transazione. È corretto dire che il nuovo formato eleva il tetto quando v1 viene scelto e supportato, mentre i formati precedenti conservano dimensioni e comportamento.

Costi e rischi delle transazioni più grandi

Una singola operazione atomica può ridurre firme e conferme rispetto a più transazioni collegate. Ma pacchetti più grandi richiedono più banda e, secondo la documentazione, possono aver bisogno di priority fee superiori per competere con transazioni piccole a parità di priorità.

Anche la superficie degli errori cresce: limiti sbagliati, parser vecchi e analisi delle commissioni basate sul formato precedente possono interrompere un servizio. I test devono includere lettura, simulazione, invio, archiviazione e riproduzione dei dati.

Il confronto con l’integrazione degli NFT Solana su OpenSea mostra perché compatibilità e infrastruttura contano quanto la funzione di protocollo. Una capacità utile diventa reale per l’utente soltanto quando wallet, API ed explorer la gestiscono senza ambiguità.

Le transazioni Solana da 4.096 byte risolvono un limite reale per applicazioni complesse, soprattutto ZK, multisig e batch atomici. Il valore dell’upgrade non si misura però soltanto nei byte: dipenderà dalla preparazione dell’ecosistema, dal costo di propagazione e dalla capacità di evitare dati silenziosamente errati durante il passaggio a v1.