Il bug di Solana v1 può bloccare i reader e disattivare i limiti sulle commissioni

Il formato delle transazioni v1 di Solana aumenta il payload massimo da 1.232 byte a 4.096 byte, circa 3,3 volte. Le transazioni legacy e v0 mantengono i limiti e il comportamento esistenti. Gli utenti e le applicazioni che continuano a usare questi formati non devono migrare. La pagina degli aggiornamenti live di Solana indicava v1 come inattivo sulla mainnet al 4 settembre. La testnet era attiva. La devnet era operativa nell'epoch 1140. Un changelog di Solana pubblicato il 28 agosto descriveva le transazioni v1 come in arrivo. I consumatori RPC devono supportare il formato prima di leggere dati v1. L'attivazione opt-in comunica al servizio RPC solo il formato massimo che il client è in grado di decodificare. Non richiede dati v1 né modifica il modo in cui vengono restituite le transazioni legacy e v0. V1 sposta i limiti delle compute unit, i limiti dei dati degli account caricati e le commissioni di priorità in un oggetto anziché nelle istruzioni. Gli indicizzatori che continuano a esaminare le istruzioni possono segnalare un budget di calcolo pari a zero per ogni transazione v1 senza generare un errore. Il flag protobuf è true sia per v0 sia per v1. Un consumatore Geyser o gRPC obsoleto può quindi etichettare v1 come v0 e conservare un budget vuoto. I consumatori devono rigenerare gli stub protobuf e controllare il campo 7 prima di leggere il flag. Relayer, paymaster e altri firmatari server devono aggiornare i controlli delle policy. Uno sponsor che esamina le istruzioni per un limite alle commissioni potrebbe non applicare più un limite vincolante, perché tali istruzioni possono comparire in v1 ma vengono eseguite come no-op. I server devono identificare il prefisso v1 e applicare i limiti su commissioni e risorse nella configurazione della transazione. L'articolo descrive il problema come un errore di controllo applicativo, non come un difetto di consenso. Afferma che il problema non dimostra che i fondi siano automaticamente a rischio. Solana afferma che nessun sysvar o syscall attuale espone la configurazione del messaggio v1. I programmi che subordinano il comportamento a istruzioni ispezionate devono smettere di affidarsi a questo controllo quando v1 entrerà in funzione. Le versioni minime indicate come in grado di leggere il formato sono 8.0.0, 3.0.0-rc.3, Rust 4.2.x, Python 0.29.0 e 1.23.0. La linea web3.js 1.x può leggere v1 dalla versione 1.99.0-beta.0, ma non può costruirla, firmarla o inviarla. Gli utenti Yellowstone necessitano almeno della versione 12.6.0, del plugin geyser 15.1.1, del client gRPC 12.0.0 o 6.0.0, a seconda del proprio stack. La creazione di transazioni v1 è facoltativa. I team che le creano devono impostare esplicitamente i limiti delle compute unit e dei dati degli account caricati, perché entrambi hanno valore predefinito pari a zero. Devono rimuovere le istruzioni no-op. Devono smettere di usare le tabelle di ricerca degli indirizzi. Devono usare base64 per payload superiori a 1.232 byte. La scadenza immediata è un test di compatibilità per i servizi che potrebbero leggere, indicizzare o sponsorizzare la transazione v1 di un altro utente.