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

Solana triplicherà la quantità di dati che una singola transazione può trasportare. Questo nuovo limite di 4.096 byte rientra in una singola pagina di memoria da 4 KiB dell'hardware del validatore, secondo la proposta SIMD-0296 su GitHub.

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

QUIC ha reso inutile il limite di 1.232 byte

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

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

Nel 2022 Solana è passata a QUIC come metodo standard per la gestione delle transazioni. La RFC 9000 non impone una dimensione massima al flusso di dati, pertanto payload di grandi dimensioni possono essere trasmessi senza problemi a livello di rete.

Il limite di 1.232 byte si era trasformato in una regola priva di fondamento tecnico.

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

Un protocollo complementare, SIMD-0385, defiil formato del messaggio v1, che contiene i byte aggiuntivi. La coppia risolve un vincolo che gli sviluppatori hanno aggirato sin dal lancio della blockchain.

La proposta preferisce 4.096 byte rispetto alla dimensione massima consentita da QUIC, in modo che una transazione possa essere contenuta in una singola pagina standard di 4 KiB di memoria del validatore. Nessuna transazione oltrepassa mai i limiti di 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 utilizzavano i bundle Jito per aggirare le vecchie restrizioni:

• Il 50% dei pacchetti inviati aveva una dimensione pari o inferiore a 2.048 byte.
• Il 65% era inferiore a 6.144 byte.
• Il 100% è rimasto al di sotto dei 9.216 byte.

Un limite massimo di 4.096 byte copre la stragrande maggioranza di questi carichi di lavoro multi-transazione in una singola chiamata, rimanendo entro i limiti delle pagine hardware del validatore.

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

La maggiore capacità consente di gestire carichi di lavoro che superano il limite di 1.232 byte.

Le prove a conoscenza zero, come quelle utilizzate nei Trasferimentidentdi Token Extensions, generavano payload che superavano il limite di 1.232 byte.

Per risolvere questo problema, gli sviluppatori hanno concatenato più chiamate o rinunciato ai trasferimenti atomici crittografati. Il nuovo limite di 4.096 byte consente di gestire le prove a conoscenza zero in un'unica transazione.

Anche l'aggregazione delle firme BLS e le configurazioni multisig di grandi dimensioni traggono vantaggio da questa modifica. SIMD-0296 cita il multisig annidato, il tipo di multisig utilizzato dalle tesorerie istituzionali e dalle DAO tramite Squads, come uno dei principali fattori trainanti.

Fa inoltre riferimento alle firme monouso di Winternitz e agli schemi BLS on-chain che funzionano senza precompilazione.

Il formato abbandona le tabelle di ricerca degli indirizzi (Address Lookup Tables), che la versione 0 utilizzava per fare riferimento a un massimo di 64 account con indici brevi. Le tabelle aggiungono complessità senza alcun vantaggio, poiché ora ci sono 64 indirizzi inline da 32 byte, che occupano solo 2.048 byte, ben al di sotto del limite massimo.

Il limite di 64 account per ogni transazione rimane invariato nella Solana . Le applicazioni con un elevato numero di account continueranno a raggiungere tale limite anche dopo la risoluzione del problema del budget di byte. rete

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

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

La versione V1 è facoltativa per i mittenti, quindi le transazioni legacy e v0 continuano a funzionare. Solana Foundation Le note affermano che si tratta di un cambiamento radicale per l'infrastruttura che legge i blocchi

Se gli strumenti di analisi dei dati e gli esploratori di blocchi non vengono aggiornati alla nuova versione di Solana, si bloccheranno completamente o visualizzeranno errori.

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

Gli strumenti che trasmettono in streaming continuo blocchi live incontreranno una nuova transazione v1, riceveranno una risposta completamente vuota e si bloccheranno lì.

Gli indicizzatori, ovvero gli strumenti che registrano i dati delle transazioni, mostrano commissioni di priorità pari a zero per le nuove transazioni perché stanno cercando nel posto sbagliato.

In precedenza, queste commissioni venivano lette da un elenco specifico all'interno della transazione. Nella nuova versione, tali informazioni sono contenute in un riquadro riassuntivo dedicato.

Anza richiede ai provider RPC di aggiornare ad Agave v4.2. Helius ha pubblicato una checklist di migrazione che descrive in dettaglio il lavoro da svolgere.

La transazione v1 è stata attivata sulla testnet Solana durante l'epoca 1025 del 1° settembre. Anza ha ufficialmente programmato il lancio sulla mainnet per il 9 settembre.