Solana dimensiona il suo nuovo limite di transazione di 4.096 byte a una pagina di memoria

Solana è pronta a triplicare la quantità di dati che una singola transazione può trasportare il 9 settembre. Questo nuovo soffitto di 4.096 byte si adatta a una singola pagina di memoria da 4 KiB dell'hardware del validator, secondo la proposta SIMD-0296 su GitHub.

I carichi di lavoro che richiedono più transazioni ora richiedono una singola chiamata atomica per essere completati.

QUIC ha reso inutile il limite di 1,232 byte

Il limite originale di Solana era una precauzione di rete. La rete operava con un MTU IPv6 di 1.280 byte.

Questo lasciava 1.232 byte per il payload di una transazione dopo l'overhead del protocollo, scrivono gli autori di SIMD-0296. Questo ha senso quando ogni messaggio doveva passare attraverso l'MTU senza frammentazione.

Solana ha adottato QUIC come metodo standard per gestire le transazioni nel 2022. RFC 9000 non imposta una dimensione massima dello stream, quindi payload più grandi possono passare senza problemi a livello di rete.

Il limite di 1.232 byte era diventato una regola senza basi tecniche.

I due documenti sono stati redatti dagli ingegneri di Anza Jacob Creech e Andrew Fitzgerald. SIMD-0296 aumenta il limite di dimensione.

Un documento companion, SIMD-0385, definisce il formato del messaggio v1, che contiene i byte extra. La coppia risolve un vincolo che gli sviluppatori hanno aggirato sin dal lancio della chain.

La proposta preferisce 4.096 byte rispetto alla dimensione massima consentita da QUIC in modo che una transazione possa entrare in una singola pagina standard di memoria del validator da 4 KiB. Nessuna transazione attraversa mai il confine di una pagina.

La gestione della memoria per transazione è economica. Ogni transazione è limitata a una singola pagina.

Per arrivare al limite di 4.096 byte, Creech e Fitzgerald hanno analizzato come gli sviluppatori hanno utilizzato i bundle Jito per aggirare le vecchie restrizioni:

• 50% dei bundle inviati erano di 2,048 byte o meno.
• 65% era sotto 6,144 byte.
• 100% è rimasto sotto 9,216 byte.

Un soffitto di 4.096 byte copre la vasta maggioranza di questi carichi di lavoro multi-transazione in una singola chiamata restando entro i vincoli della pagina hardware del validator.

Le chiamate RPC non preparate ora generano errore -32015 su Solana

La capacità extra permette carichi di lavoro che superano il limite di 1.232 byte.

Le prove a conoscenza zero, come quelle utilizzate nei Trasferimenti Riservati delle Estensioni Token, hanno generato payload che superavano il limite di 1.232 byte.

Per risolvere questo problema, gli sviluppatori concatenavano più chiamate o rinunciavano ai trasferimenti crittografati atomici. Il nuovo limite di 4.096 byte accommodate le prove a conoscenza zero in una singola transazione.

L'aggregazione delle firme BLS e le grandi configurazioni multisig beneficiano anche di questo cambiamento. SIMD-0296 cita il multisig nidificato, il tipo di multisig utilizzato dai treasury istituzionali e dalle DAO tramite Squads, come uno dei principali driver.

Fa anche riferimento alle firme Winternitz one-time e agli schemi BLS on-chain che funzionano senza precompilazioni.

Il formato evita le Address Lookup Tables, che v0 utilizzava per fare riferimento a fino a 64 account con indici brevi. Le tabelle aggiungono complessità senza vantaggi perché ora ci sono 64 indirizzi inline da 32 byte, che occupano solo 2.048 byte, ben al di sotto del soffitto.

Il limite di 64 account per ogni transazione rimane nella rete Solana. Le applicazioni con molti account raggiungeranno comunque il limite anche se il problema del budget dei byte è risolto.

I bundle Jito permettono agli sviluppatori di unire fino a cinque transazioni in una sequenza tutto-o-nulla per risolvere il problema della limitazione dei byte.

La transazione v1 raggiunge lo stesso risultato atomico in una singola transazione. Porta l'atomicità nativa direttamente al livello base.

V1 è opzionale per i mittenti, quindi le transazioni legacy e v0 continuano a funzionare. Le note di migrazione della Solana Foundation dicono che è un cambiamento incompatibile per le infrastrutture che leggono i blocchi

Se gli strumenti di dati e i block explorer non sono aggiornati per la nuova versione di Solana, si bloccheranno completamente o genereranno errori.

Quando un'app tenta di leggere una transazione o un blocco v1 senza il nuovo parametro della versione, i server di Solana rifiutano la richiesta con un codice di errore di sistema -32015.

Gli strumenti che trasmettono continuamente blocchi in tempo reale incontreranno una nuova transazione v1, riceveranno una risposta completamente vuota e si bloccheranno lì.

Gli indexer, o strumenti che registrano i dati delle transazioni, mostrano zero fee di priorità per le nuove transazioni perché stanno cercando nel posto sbagliato.

In passato leggevano queste fee da un elenco speciale all'interno della transazione. Nella nuova versione, queste informazioni sono mantenute nella propria casella di riepilogo dedicata.

Anza sta richiedendo ai provider RPC di aggiornarsi ad Agave v4.2. Helius ha emesso una checklist di migrazione che dettaglia il lavoro.

La transazione v1 è stata attivata sulla testnet di Solana durante l'epoch 1025 il 1 settembre. Anza ha ufficialmente programmato il deployment su mainnet per il 9 settembre.