Solana starebbe preparando il raddoppio... si prepara a triplicare la dimensione massima di una singola transazione di rete, una modifica al limite transazionale della blockchain che darebbe alle applicazioni più spazio per inserire operazioni complesse in un'unica transazione. Secondo quanto riportato sull'aggiornamento pianificato, la mossa riguarda la quantità di dati che una singola transazione può trasportare. I limiti esatti in byte, lo stato della proposta e la tempistica di attivazione non sono stati confermati.

Cosa cambierebbe con l'aumento della dimensione delle transazioni

La modifica riguarda quanto può essere grande una singola transazione Solana, misurata in byte — non quante transazioni la rete elabora al secondo. Triplicare quel tetto aumenterebbe la quantità di dati di istruzioni e di account che una singola transazione può trasportare.

Il report disponibile non indica il limite attuale in byte, il nuovo valore proposto né un identificativo della proposta, quindi non è possibile fornire cifre precise di prima e dopo. I parametri di rete di Solana vengono tipicamente modificati tramite il processo Solana Improvement Documents, le cui proposte aperte sono tracciate pubblicamente.

È importante distinguere un limite transazionale più ampio da un throughput più elevato. Triplicare la dimensione delle transazioni è diverso dall'aumentare throughput, capacità di esecuzione o capacità dei blocchi. Un limite più ampio non aumenta di per sé le transazioni al secondo o i budget di compute-unit; cambia soltanto quanti dati possono essere codificati in una singola transazione. Per chi segue le modifiche di protocollo tra gli ecosistemi, questo tipo di regolazione dei parametri si colloca accanto ad altri lavori sulla capacità di rete delle blockchain con smart contract — ad esempio, l'uso storico di Ethereum dei limiti di gas per blocco e del pricing dei calldata per gestire quanti dati consumano le transazioni — anche se ogni chain imposta e governa tali parametri in modo diverso.

Come transazioni più grandi potrebbero supportare operazioni più complesse

Un limite transazionale più ampio potrebbe, in linea di principio, consentire a un'applicazione di inserire più istruzioni legate al trading o riferimenti ad account in una singola transazione, in base alla progettazione finale della modifica. Questo è il beneficio pratico che il report attribuisce all'aumento delle dimensioni, anche se non è stata fornita alcuna applicazione citata per nome, benchmark o dichiarazione di sviluppatori.

A titolo ipotetico, uno swap multi-step o un insieme di operazioni di trading combinate che oggi devono essere suddivise tra più transazioni potrebbero potenzialmente rientrarne in una sola. Ciò conta per la componibilità: quando operazioni correlate devono essere suddivise in transazioni separate, possono fallire in modo indipendente, un punto dolente di lunga data per i flussi di lavoro on-chain complessi. Questo resta puramente illustrativo; non è stato dimostrato alcun flusso di lavoro confermato. Solana costituisce già il punto di riferimento per un'intensa attività di routing delle operazioni tramite piattaforme come Raydium e Jupiter — il tipo di applicazioni che un limite più ampio inciderebbe più direttamente.

Altri limiti sulla complessità delle transazioni

La dimensione della transazione è solo uno dei vincoli. Anche i limiti di esecuzione, come i budget di compute-unit e le regole di accesso agli account, limitano la complessità di una transazione, e il report non specifica se tali limiti cambieranno insieme all'aumento delle dimensioni.

La modifica non va interpretata come una promessa di commissioni più basse, prezzi migliori o slippage ridotto; nessuno di questi effetti è supportato dalle evidenze disponibili.

Cosa resta da confermare sul rollout

Non è stata fornita alcuna tempistica, condizione di attivazione, release del client o conferma mainnet per la modifica. La specifica tecnica, lo stato della proposta, l'ambito di implementazione e la data di attivazione restano tutti non verificati.

Non è inoltre confermato se gli strumenti applicativi o il codice di costruzione delle transazioni dovrebbero essere aggiornati per usare un limite più ampio, e non sono disponibili misurazioni di prestazioni o compromessi in termini di risorse. Finché non saranno identificati una proposta specifica e una release del client, l'attestazione principale descrive un piano riportato, non un aggiornamento già distribuito.