NotizieCryptoSolana attiva Transaction V1 e aumenta la dimensione massima delle transazioni a 4.096 byte

Solana attiva Transaction V1 e aumenta la dimensione massima delle transazioni a 4.096 byte

Autore: Cryptopolitan·

Punti chiave

  • Transaction V1 è entrata in funzione all’inizio dell’epoch 1035, intorno alle 01:00 UTC del 15 settembre.
  • La dimensione massima di una transazione serializzata è ora di 4.096 byte, circa 3,3 volte il precedente limite di 1.232 byte.
  • L’aggiornamento consente di eseguire routing, verifica delle prove e batching all’interno di un’unica transazione atomica a livello di protocollo.
  • V1 include direttamente i riferimenti agli account invece di utilizzare gli Address Lookup Tables, aggiungendo potenzialmente oltre 1.500 byte alle transazioni dense, mentre il limite degli account resta pari a 64.
  • I validatori e gli operatori RPC dovrebbero utilizzare Agave v4.2.2 o una versione successiva; lettori RPC, indicizzatori, mittenti e wallet necessitano di supporto e configurazioni specifici per V1.
Solana attiva Transaction V1 e aumenta la dimensione massima delle transazioni a 4.096 byte

Solana ha attivato la funzionalità Transaction V1 sulla propria mainnet martedì, consentendo di includere più dati in ogni transazione. L’aggiornamento offre agli sviluppatori maggiore spazio per eseguire azioni complesse all’interno di un unico processo atomico ed è rilevante per gli sviluppatori DeFi, i fornitori di wallet, gli indicizzatori e gli operatori RPC. Potrebbe inoltre avere ripercussioni sui progetti che lavorano con asset tokenizzati e soluzioni di pagamento.

Secondo la pagina degli aggiornamenti di Solana, il feature gate txv1 è stato attivato all’inizio dell’epoch 1035, intorno alle 01:00 UTC del 15 settembre. Transaction V1 è ora attiva sulla mainnet, testnet e devnet di Solana.

La dimensione delle transazioni aumenta da 1.232 a 4.096 byte

Il cambiamento più evidente è l’aumento della dimensione massima di una transazione serializzata. Solana ha innalzato il limite da 1.232 a 4.096 byte, offrendo circa 3,3 volte più spazio per i dati delle transazioni.

Il formato della nuova transazione è stato definito in SIMD-0296, mentre il V1 Message Format si basa su SIMD-0385. In precedenza, il limite alla dimensione delle transazioni di Solana era legato a vincoli conservativi della maximum transmission unit, o MTU, della rete. Transaction V1 supera il limite rigido imposto da QUIC alla dimensione dei flussi, consentendo transazioni più grandi.

La capacità aggiuntiva è destinata a supportare carichi di lavoro che richiedono grandi quantità di dati nelle transazioni, tra cui prove a conoscenza zero, operazioni multisig di grandi dimensioni e firme che utilizzano BLS. Come riportato in precedenza da Cryptopolitan, V1 è stata lanciata sulla testnet all’epoch 1025, il 1° settembre, dando ai fornitori di infrastrutture il tempo di prepararsi al rilascio sulla mainnet.

Perché è importante una singola transazione atomica

Prima dell’aggiornamento, gli sviluppatori che incontravano il limite alla dimensione delle transazioni di Solana potevano, in alcuni casi, suddividere le operazioni in diverse transazioni oppure utilizzare i bundle di Jito. Tuttavia, la spiegazione contenuta in SIMD-0296 afferma che un bundle non equivale a una transazione nativa quando si considera l’atomicità a livello di protocollo.

Transaction V1 consente di inserire più istruzioni e dati all’interno di una singola transazione. Di conseguenza, il routing, la verifica delle prove e il batching possono riuscire tutti o fallire tutti, invece di essere eseguiti attraverso transazioni separate. A seconda dell’operazione, ciò potrebbe anche ridurre il numero di firme e conferme necessarie.

Compromesso degli Address Lookup Tables

Transaction V1 modifica inoltre il modo in cui le transazioni gestiscono le risorse e i riferimenti agli account. Le impostazioni relative al limite di calcolo e alle commissioni prioritarie sono state spostate dalle istruzioni ComputeBudget alle impostazioni della transazione, rendendo questi parametri più facilmente accessibili ai fornitori di infrastrutture.

Le transazioni V1 non utilizzano gli Address Lookup Tables perché gli account referenziati sono inclusi direttamente nella transazione. Ciò semplifica la struttura della transazione, ma può aumentarne la dimensione. Un Address Lookup Table v0 richiede solo un indice di un byte, mentre una chiave pubblica inline richiede 32 byte.

Un’analisi degli Address Lookup Tables di Solana ha rilevato che il 62% delle transazioni v0 utilizzava almeno un Address Lookup Table. Di conseguenza, le transazioni dense che utilizzano più di una tabella potrebbero aumentare di oltre 1.500 byte quando i riferimenti agli account vengono inclusi direttamente. Il limite degli account resta invariato a 64 account.

Il ruolo nell’espansione della finanza tokenizzata di Solana

L’aggiornamento arriva mentre Solana amplia il proprio ruolo nella finanza on-chain. Secondo DeFiLlama, il valore totale bloccato nel settore DeFi di Solana è vicino a $5,95 miliardi, mentre il volume sugli exchange decentralizzati nelle 24 ore è pari a circa $1,79 miliardi.

Il riepilogo di agosto di Solana ha inoltre riportato che il valore degli asset del mondo reale sulla rete aveva superato $4 miliardi ed era distribuito su oltre 350.000 indirizzi. Inoltre, xStocks aveva accumulato oltre $500 milioni di asset in gestione.

Una maggiore capacità delle transazioni, da sola, non garantisce un aumento dell’adozione. Galaxy Research ha osservato che una quota significativa del valore detenuto nei token di Solana rimane inutilizzata, mentre le piattaforme concorrenti continuano a essere leader in alcune aree in rapida espansione. Transaction V1 amplia la gamma di applicazioni che gli sviluppatori possono creare su Solana, ma la successiva risposta di utenti, liquidità e attività delle transazioni rimane una questione aperta.

Modifiche richieste per operatori e sviluppatori

I lettori RPC dovrebbero impostare maxSupportedTransactionVersion: 1 per getTransaction e getBlock. Gli indicizzatori devono leggere i limiti di calcolo e le commissioni prioritarie di V1 da transactionConfig.

I validatori e gli operatori RPC dovrebbero eseguire Agave v4.2.2 o una versione successiva. I mittenti V1 dovrebbero impostare esplicitamente i limiti di calcolo e degli account caricati e utilizzare base64 per le transazioni più grandi di 1.232 byte.

I fornitori di wallet dovrebbero dichiarare il supporto a V1 solo dopo aver verificato che il proprio software sia in grado di analizzare e firmare correttamente il nuovo formato, in linea con le indicazioni di aggiornamento di Solana. Il rapporto originale è stato pubblicato da Cryptopolitan.