ERPC pubblica Solana Stream SDK v4.0.0 con elaborazione degli Shreds UDP e riconnessione gRPC più rapide

ELSOUL LABO B.V. e Validators DAO hanno pubblicato ufficialmente Solana Stream SDK v4.0.0 il 6 novembre 2026. Si tratta di un SDK open source per gestire i dati in streaming di Solana. I benchmark locali hanno misurato un’elaborazione interna degli Shreds UDP in Rust circa 108 volte più veloce e un throughput della coda di eventi TypeScript circa 4 volte superiore. Anche Geyser gRPC riprende a ricevere aggiornamenti più rapidamente dopo una disconnessione. L’SDK è utilizzabile gratuitamente e include esempi in Rust e TypeScript per aiutare gli sviluppatori a iniziare.

Per sfruttare una distribuzione dei dati a bassa latenza in un’applicazione, conta anche la rapidità con cui vengono elaborati i dati in arrivo. La versione 4.0.0 rende più efficiente l’elaborazione interna dopo l’arrivo dei dati e migliora il ripristino della connessione dopo le disconnessioni. Usandola insieme a ERPC Shreds UDP Forwarding Premium, gli sviluppatori possono migliorare sia il percorso di distribuzione sia l’implementazione della ricezione nelle proprie applicazioni Solana.

Nel percorso di ricezione UDP in Rust, la v4 accelera la decodifica dei datagrammi, l’inserimento in un buffer interno e il deshredding, che ricostruisce i dati a partire dagli Shreds. Riduce il carico di elaborazione rivedendo la pulizia dello stato interno e le letture dell’orologio che venivano ripetute per ogni pacchetto, mantenendo invariati i periodi di conservazione dei dati. Nel confronto, il tempo di elaborazione interna per datagramma è sceso da 94.236 ns a 855–881 ns, con un’accelerazione di circa 108 volte.

Il benchmark è stato eseguito su un Mac con un chip Apple serie M, elaborando 403.200 datagrammi distribuiti su 300 slot per esecuzione. I risultati confrontano le mediane di cinque esecuzioni. La misurazione riguarda il percorso interno decode→insert→deshred. Non include il tempo di distribuzione attraverso la rete né l’elaborazione successiva nell’applicazione dell’utente. Ridurre il lavoro necessario per ricostruire gli Shreds in arrivo aiuta gli sviluppatori a destinare più risorse di calcolo alla logica applicativa.

Gli esempi e i progetti di avvio Geyser gRPC in TypeScript riducono l’attesa quando sono ancora presenti eventi nella coda, consentendo di recuperare i dati ricevuti in modo più efficiente. In un test limitato alla coda, con due milioni di eventi elaborati su Node.js 24, il throughput è passato da 5,7–7,4 milioni a 24,8–29,4 milioni di eventi al secondo, con un miglioramento di circa 4 volte.

Per Geyser gRPC sono stati aggiornati il client che gestisce la riconnessione e l’intervallo prima del primo nuovo tentativo. In un test che ha provocato 20 disconnessioni su un server tonic locale, l’intervallo mediano tra gli aggiornamenti ricevuti prima e dopo ciascuna disconnessione è sceso da 552 ms con il runner 3.0 a 103 ms con il runner 4.0. Questa misura rappresenta l’intervallo fino alla ripresa degli aggiornamenti nell’ambiente di test locale.

Questi tre risultati provengono da test diversi, con ambiti di misurazione e condizioni differenti. Mostrano rispettivamente i miglioramenti dell’elaborazione interna in Rust, della coda di eventi TypeScript e della riconnessione gRPC. I dettagli dell’implementazione e le condizioni dei test sono disponibili nella PR #129, riportata tra i link correlati.

Il supporto ad Alpenglow è stato introdotto nella v3.0.0. La versione 4.0.0 mantiene la distinzione tra i marcatori di blocco, che rappresentano gli aggiornamenti relativi a header, footer e blocco padre, e le voci, che contengono le transazioni. Le applicazioni possono gestire le informazioni sulla struttura dei blocchi separatamente dalle voci da elaborare.

La versione 4.0.0 aggiorna i client ad Agave 4.4.1 e Yellowstone gRPC 17.x. Durante la riconnessione, un evento Disconnected può comunicare informazioni che identificano i dati ricevuti parzialmente, insieme alla posizione di ripresa. Le applicazioni dispongono così delle informazioni necessarie per implementare la propria gestione dei dati ritrasmessi duplicati e dei dati ricevuti solo in parte.

La migrazione dalla v3 alla v4 conserva le definizioni protobuf di Geyser, aggiornando al contempo gli eventi di riconnessione e i tipi di messaggi e transazioni Solana utilizzati in Rust. La guida alla migrazione pubblicata descrive le modifiche ai gestori degli eventi e alle versioni delle dipendenze.

Il pacchetto Rust pubblicato solana-stream-sdk e il pacchetto TypeScript @validators-dao/solana-stream-sdk sono entrambi disponibili nella v4.0.0. I linguaggi supportati per ciascun tipo di connessione sono elencati di seguito.

Usa il client Rust per ricevere gli Shreds via UDP. L’esempio e il progetto di avvio UDP in Rust utilizzano l’SDK v4.0.0 pubblicato e permettono di provare la ricezione dei dati, la ricostruzione dei dati dagli Shreds e il rilevamento delle istruzioni di un programma da monitorare. Modifica il programma monitorato e l’elaborazione successiva al rilevamento per usarli come punto di partenza della tua applicazione.

Per lo sviluppo in TypeScript puoi utilizzare Geyser gRPC o Shreds gRPC. I miglioramenti della coda di eventi di questa versione sono inclusi negli esempi e nei progetti di avvio Geyser gRPC. Scegli l’implementazione pubblicata che corrisponde al tuo linguaggio e al metodo di distribuzione utilizzato.

ERPC Shreds UDP Forwarding Premium collega più nodi in una rete mesh all’interno di ogni regione e inoltra la copia di ciascuno Shred ricevuta per prima da quella mesh. Sia il momento di arrivo lungo il percorso di distribuzione sia il tempo di ricostruzione nell’SDK dopo l’arrivo incidono sulla rapidità con cui i dati ricevuti diventano utilizzabili. I miglioramenti della ricezione UDP in Rust possono essere applicati sul lato ricevente ai dati distribuiti da Premium.

Nel confronto effettuato a Francoforte il 30 ottobre 2026, Standard e Premium sono stati acquisiti simultaneamente per 120 secondi su una stessa macchina e con lo stesso orologio. I payload UDP con contenuto identico sono stati abbinati a partire dalla cattura pcap. Premium è arrivato per primo nel 98% di questo insieme di corrispondenze e la differenza mediana nei tempi di arrivo è stata di 1,78 ms. Dei payload osservati su Standard, il 93,9% è stato osservato anche su Premium.

Il grafico di Premium mostra le differenze nei tempi di arrivo tra i percorsi di distribuzione, mentre il grafico dell’SDK mostra l’elaborazione interna lato ricevente e il ripristino della connessione. In un’applicazione reale, registrare sia l’arrivo dei pacchetti sia il momento in cui viene rilevata un’istruzione rilevante consente di verificare quanto del vantaggio nella distribuzione si mantenga nel risultato dell’elaborazione.

Shreds UDP Forwarding Premium è disponibile con fatturazione oraria a 1,39 € all’ora. Attiva il servizio dalla dashboard e verifica la ricezione con il progetto di avvio UDP in Rust. Mantenere la stessa regione, lo stesso server ricevente e lo stesso carico applicativo consente di valutare le differenze nei tempi di arrivo separatamente dal tempo di elaborazione dopo la ricezione.

Per prima cosa, registra il tuo indirizzo IPv4 pubblico e la porta UDP nella dashboard e consenti il traffico in ingresso dalle sorgenti indicate. Dopo aver verificato la ricezione dei pacchetti e la ricostruzione dei dati con il progetto di avvio UDP in Rust, includi nella valutazione i programmi da monitorare e l’elaborazione effettiva della tua applicazione. Combina gli esempi con il servizio di distribuzione per misurare il tempo dalla ricezione al rilevamento nel tuo ambiente.