NotizieCryptoSolana attiva il formato V1 e più che triplica la dimensione massima delle transazioni

Solana attiva il formato V1 e più che triplica la dimensione massima delle transazioni

Autore: Coindoo·

Punti chiave

  • L’aggiornamento txv1 di Solana, attivato sulla mainnet il 15 settembre all’inizio dell’epoca 1035, aumenta la dimensione massima delle transazioni da 1.232 byte a 4.096 byte.
  • La capacità aggiuntiva favorisce operazioni ad alta intensità di dati, come trading aggregato, approvazioni multisig di grandi dimensioni, prove a conoscenza zero e alcuni schemi di firma on-chain, mentre i semplici trasferimenti di SOL traggono pochi vantaggi dal nuovo formato.
  • Le transazioni legacy e V0 continuano a essere pienamente supportate e la maggior parte degli utenti dei wallet non deve spostare fondi, creare nuovi indirizzi o convertire account.
  • I servizi RPC devono impostare maxSupportedTransactionVersion su 1 per evitare errori nel recupero delle transazioni V1, mentre gli indicizzatori devono leggere i nuovi campi di transactionConfig per evitare di riportare erroneamente a zero i limiti delle risorse e le commissioni prioritarie.
  • V1 consente di includere direttamente in una transazione fino a 64 indirizzi di account, ma non supporta le tabelle di ricerca degli indirizzi; inoltre, le transazioni più grandi possono richiedere commissioni prioritarie maggiori quando lo spazio nei blocchi è molto richiesto.
Solana attiva il formato V1 e più che triplica la dimensione massima delle transazioni

Solana ha attivato la funzionalità txv1 sulla mainnet alle 01:00 UTC circa del 15 settembre, all’inizio dell’epoca 1035. L’aggiornamento aumenta la dimensione massima delle transazioni da 1.232 byte a 4.096 byte, offrendo una capacità più che tripla rispetto al limite precedente.

Lo spazio aggiuntivo è disponibile attraverso il formato di transazione V1. Le applicazioni devono aggiungere esplicitamente il supporto prima di utilizzarlo, mentre le transazioni legacy e V0 continuano a essere pienamente supportate entro i rispettivi limiti.

Una transazione più grande non significa un trasferimento maggiore di SOL

Il nuovo limite riguarda la quantità di informazioni trasportate da una transazione, non la quantità di SOL che un utente può inviare. Un trasferimento standard richiede generalmente una quantità limitata di dati, perché contiene solo pochi account, istruzioni e firme.

Le operazioni più avanzate possono richiedere diverse istruzioni, numerosi indirizzi di account, approvazioni multiple o prove crittografiche. Quando queste informazioni superavano il limite precedente, gli sviluppatori dovevano ridurre il payload, suddividere l’operazione in più transazioni oppure utilizzare alternative come le tabelle di ricerca degli indirizzi e i bundle di transazioni.

Solana può elaborare transazioni non correlate in parallelo, come spiegato in questa guida al funzionamento di Solana. V1 non modifica questo modello di esecuzione. Fornisce invece spazio aggiuntivo quando una singola operazione deve contenere diversi componenti collegati.

Quando queste istruzioni vengono inviate come un’unica transazione atomica, sono elaborate come un’unità. L’operazione completa viene eseguita con successo oppure le sue modifiche vengono annullate, evitando che solo alcune istruzioni raggiungano il ledger.

Operazioni che possono beneficiare dello spazio aggiuntivo

  • Trading aggregato: un’applicazione di trading può inserire istruzioni collegate in un’unica transazione invece di coordinare diverse conferme.
  • Approvazioni multisig di grandi dimensioni: i wallet di tesorerie e aziende possono gestire più firme e informazioni sugli account quando più persone devono autorizzare un’operazione.
  • Prove a conoscenza zero: le applicazioni possono dimostrare che una condizione è soddisfatta senza rivelare tutte le informazioni sottostanti, ma la prova stessa può richiedere uno spazio considerevole nella transazione.
  • Schemi di firma on-chain: alcuni formati di firma crittografica producevano in precedenza più dati di quanti potesse contenere una singola transazione Solana.

La Solana Foundation indica i trasferimenti confidenziali, i multisig annidati, le operazioni aggregate e alcuni schemi di firma on-chain tra i possibili utilizzi del nuovo formato.

La maggior parte degli utenti dei wallet non deve intraprendere azioni

L’attivazione non richiede agli utenti di spostare i propri SOL, creare un altro indirizzo o convertire un account esistente. Le applicazioni che continuano a utilizzare transazioni legacy o V0 dovrebbero funzionare come prima dell’aggiornamento.

Gli utenti avranno bisogno di un wallet compatibile quando un’applicazione sceglierà di inviare una transazione V1. Mantenere aggiornato il software del wallet renderà disponibile questo supporto quando i fornitori lo introdurranno, ma le applicazioni dovrebbero comunque verificare la compatibilità prima di chiedere a un wallet di firmare.

Per gli utenti, il cambiamento potrebbe manifestarsi nel tempo sotto forma di un numero inferiore di richieste di approvazione per le operazioni complesse. Un servizio che in precedenza richiedeva diverse transazioni collegate potrebbe invece presentare un’unica richiesta e attendere una sola conferma.

Gli sviluppatori e gli indicizzatori devono aggiornare i propri software

L’invio di transazioni V1 è facoltativo, ma la loro lettura può creare problemi di compatibilità per le infrastrutture non aggiornate.

I servizi RPC che recuperano transazioni o blocchi devono impostare maxSupportedTransactionVersion: 1. Senza questa impostazione, una richiesta per una transazione V1 può restituire un errore. Anche una singola transazione non supportata può causare il fallimento della richiesta di un intero blocco.

Gli indicizzatori affrontano un rischio diverso. V1 memorizza il limite di calcolo, il limite dei dati degli account caricati e la commissione prioritaria all’interno di transactionConfig, invece che nelle istruzioni Compute Budget. I software che continuano a esaminare la vecchia posizione potrebbero classificare erroneamente la transazione o riportare a zero i suoi limiti di risorse e la commissione prioritaria.

Le applicazioni che creano transazioni V1 devono impostare esplicitamente i propri limiti di unità di calcolo e dei dati degli account caricati. Nel nuovo formato entrambi i valori sono predefiniti a zero, quindi ometterli può causare il fallimento della transazione prima dell’esecuzione.

Le transazioni più grandi di 1.232 byte devono inoltre essere inviate utilizzando la codifica base64. Il percorso di invio base58 mantiene il precedente limite dimensionale.

V1 aggiunge spazio ma modifica altri limiti

V1 non è semplicemente V0 con un payload più grande. Può includere direttamente nella transazione fino a 64 indirizzi di account, ma non supporta le tabelle di ricerca degli indirizzi. Anche gli indirizzi di account duplicati vengono rifiutati.

Queste regole introducono una scelta progettuale diversa per i team che sviluppano applicazioni. V0 rimane utile quando le tabelle di ricerca forniscono un modo efficiente per fare riferimento agli account, mentre V1 è destinato alle operazioni che traggono maggiore vantaggio da spazio aggiuntivo per istruzioni, firme o prove.

È improbabile che un pagamento di base tragga vantaggio dal nuovo formato. V1 è più adatto alle applicazioni che possono sostituire una sequenza complessa o gestire dati che in precedenza non potevano rientrare in un’unica transazione.

Le transazioni più grandi possono comportare commissioni maggiori

L’aumento del limite in byte non rende automaticamente più costosa ogni transazione V1. Il costo dipende dalle risorse richieste, dal numero di firme e dalla commissione prioritaria selezionata dall’applicazione.

I messaggi più grandi consumano comunque una maggiore larghezza di banda dei validatori. La documentazione di Solana afferma che lo scheduler dovrebbe richiedere una commissione prioritaria più elevata per una transazione grande rispetto a una più piccola che cerchi un livello di priorità equivalente, soprattutto quando lo spazio nei blocchi è richiesto.

V1 esprime la commissione prioritaria come importo totale in lamport. V0 utilizza un prezzo per unità di calcolo, il che significa che le piattaforme di analisi devono normalizzare i due formati prima di confrontarli.

La domanda di commissioni prioritarie può variare notevolmente in base all’attività della rete, come mostrano i dati recenti sulle commissioni di Solana. Gli sviluppatori dovranno quindi valutare la convenienza di un’unica operazione più grande rispetto al costo per includerla durante i periodi di congestione.

L’attivazione dà inizio alla prova di adozione

L’aggiornamento rimuove un vincolo che in precedenza influenzava il modo in cui venivano costruite le applicazioni Solana, ma l’attivazione sulla mainnet non garantisce un utilizzo diffuso. Wallet, fornitori RPC, indicizzatori e librerie applicative devono gestire correttamente il nuovo formato prima che gli sviluppatori possano farvi affidamento nei prodotti destinati agli utenti.

I primi vantaggi potrebbero emergere nei carichi di lavoro che già incontrano difficoltà con il limite precedente, inclusi trasferimenti confidenziali, configurazioni multisig istituzionali e applicazioni con numerose istruzioni. Per i trasferimenti ordinari, i formati esistenti rimangono l’opzione più semplice.

L’importanza di V1 dipenderà dal fatto che l’inserimento di questi carichi di lavoro in un’unica transazione atomica generi risparmi sufficienti in termini di coordinamento, firme e tentativi falliti da giustificare gli aggiornamenti infrastrutturali necessari.

Questo articolo è fornito esclusivamente a scopo informativo e non costituisce consulenza finanziaria o di investimento. La compatibilità dei wallet, il supporto delle applicazioni e le commissioni di transazione possono cambiare.

Fonte: Coindoo