Le transazioni Solana V1 arrivano su testnet, con l'obiettivo di raggruppare operazioni multi-step in una sola

Il 1° settembre, Anza ha avviato le Transazioni V1 sulla testnet di Solana, consentendo l'ultima prova generale di questo aggiornamento prima del lancio previsto per il 9 settembre.

La modifica mira a consentire l'elaborazione in un'unica transazione atomica dei carichi di lavoro crittografici e DeFi che inizialmente dovevano essere frammentati in diverse transazioni, come dichiarato da Solana Compass.

Le operazioni che in precedenza richiedevano chiamate multiple ora rientrano in un'unica chiamata

La modifica più significativa riguarda l'aumento dello spazio. La dimensione massima di una transazione Solana serializzata è passata da 1.232 byte a 4.096 byte, ovvero un incremento di 3,3 volte, entrato in vigore all'epoch 1025 della testnet.

Secondo il sito web dedicato all'aggiornamento sulle grandi transazioni della Solana Foundation, tale dimensione aumentata renderà possibile implementare prove a conoscenza zero, transazioni multisig complesse e vari schemi di firma che non erano realizzabili all'interno di una singola transazione.

Di conseguenza, meno transazioni devono essere elaborate, sono necessari meno fondi per pagare le firme e non è più necessario attendere una catena di conferme. Gli schemi di firma BLS, le transazioni confidenziali e le configurazioni multisig trarranno beneficio da questo aggiornamento.

Esistono due proposte principali essenziali per il miglioramento. SIMD-0296 aumenta la dimensione della transazione da 1.232 byte a 4.096 byte, mentre SIMD-0385 definisce il formato del messaggio V1 e sposta la configurazione della transazione direttamente nel messaggio.

Meno di un giorno dopo l'attivazione dell'aggiornamento, Brennan Watt, CEO di Anza ha pubblicato su X un post che menzionava una grande transazione sull'esploratore del testnet con il messaggio: "ATTENZIONE: le grandi transazioni sono arrivate sul testnet."

Perché una singola transazione batte un bundle

L'importanza dell'atomicità deriva dal fatto che, talvolta, gli sviluppatori aggiravano il vecchio limite di dimensione di Solana tramite bundle Jito. In effetti, SIMD-0296 spiega tale soluzione alternativa e sottolinea anche che i bundle mancano di atomicità a livello di protocollo, come avviene con una singola transazione nativa.

Secondo la documentazione di Jito, i bundle possono includere fino a cinque transazioni elaborate in sequenza su base tutto-o-nulla. Tuttavia, i bundle operano all'interno del block-engine di Jito e competono tra le commissioni per i validatori. La transazione V1, d'altro canto, si riferisce a una singola transazione nativa Solana, che garantisce l'atomicità a livello di transazione da parte di Solana.

Per gli sviluppatori DeFi, ciò può aiutare a semplificare la definizione di percorsi di swap, prove e altri tipi di transazioni multistep. Se l'operazione è interamente coperta dalla transazione V1, questa o ha successo o viene restituita come transazione nativa singola, senza dover fare affidamento su un bundle di transazioni.

Cosa ottiene il DeFi oltre ai byte aggiuntivi

V1 modifica anche la struttura della transazione. Mentre Legacy e V0 elaborano le fee di priorità e le richieste di risorse tramite istruzioni ComputeBudget, SIMD-0385 integra queste configurazioni nelle configurazioni delle transazioni V1, semplificando così il compito dei validatori nell'identificare le esigenze di risorse senza dover cercare attivamente nella lista delle istruzioni.

V1 elimina inoltre le Address Lookup Tables (ALT), utilizzate da V0 per accorciare gli indirizzi degli account. Secondo l'analisi della Fondazione sulle trade-off delle ALT di V1 , V1 esegue invece il posizionamento degli indirizzi inline. Questo rende più semplice l'input per i validatori rispetto al metodo utilizzato nelle applicazioni con molti account di V0, che consumano più byte quando convertiti.

Il vantaggio pratico per i router e gli aggregatori DEX è che ora c'è più spazio per percorsi atomici complessi. Tuttavia, questo miglioramento non è privo di limitazioni. Infatti, la capacità massima di Solana di 64 account diversi rimane invariata; pertanto, le applicazioni che richiedono un uso intensivo degli account possono ancora risentire di tale limite, anche se il vincolo legato alla capacità in byte non è più un problema.

L'aggiornamento viene introdotto mentre Solana compie un balzo verso la finanza on-chain. Il report di Galaxy sul Q2 2026 di Solana evidenzia un aumento dell'attività di stablecoin, azioni tokenizzate e asset del mondo reale.

Secondo Galaxy, in futuro il potenziale di Solana dipenderà largamente dalla capacità di utilizzare asset per lending, collateralizzazione, margin e yield, invece che solo per emissione o trading. Basandosi sui dati DeFiLlama su Solana, la piattaforma sembra avere una forte presenza nel settore DeFi.

Inoltre, il tempismo dell'upgrade coincide con la fase di aggiornamento Agave 4.2. Informativamente, Cryptopolitan ha dichiarato che il piano per un'implementazione graduale della riduzione dei costi dovrebbe portare a risparmi di circa il 90%, insieme a una diminuzione del tempo necessario per l'elaborazione da 500 a 200 millisecondi, portando benefici agli emittenti di stablecoin, ai provider di wallet e ai sistemi di pagamento.

Gli operatori RPC hanno una settimana per aggiornarsi

V1 è opzionale, quindi le transazioni Legacy e V0 continuano a funzionare. Il problema riguarda la disponibilità delle infrastrutture che leggono il traffico V1.

Anza ha obbligato i provider RPC a migrare ad Agave v4.2.2 o v4.3.0-beta.3. La checklist di migrazione Helius Agave 4.2 sottolinea anche che i consumatori RPC che non dichiarano la conformità V1 potrebbero riscontrare fallimenti nelle chiamate come getBlock quando viene utilizzata una transazione V1.

Il processo è iniziato con i test locali di V1 il 24 agosto, poco dopo di che la data del mainnet è stata confermata come 9 settembre il 29 agosto. V1 è stato abilitato sul Testnet il 1° settembre all'epoch 1025, con un'attivazione programmata sul mainnet per il 9 settembre.

Questo ultimo ciclo di test sul testnet rappresenta l'ultimo passo preparatorio per i provider RPC, gli indexer, i wallet, gli SDK e le piattaforme analitiche prima del lancio del mainnet.