FAQ - Direct Shreds

Q. L’output dei miei Shreds / di getBlock all’improvviso sembra corrotto o restituisce -32015: cosa è cambiato?

Solana Transaction v1 (SIMD-0385) è stata attivata sulla mainnet di Solana il 15 settembre 2026, all’epoch 1035. Il formato wire di una transazione v1 inizia con il byte di prefisso di versione 0x81, le firme seguono il messaggio e non c’è più il prefisso di lunghezza legacy.

Se decodifichi da solo le entry di ShredStream, Direct Shreds o UDP Forwarding, un decoder bincode o solana-entry precedente alla versione 4.2 interpreta erroneamente quel byte 0x81 come numero di firme, e questo si manifesta come errore EOF, overflow di compact-length o errore "invalid message version". Gli utenti Geyser gRPC che deserializzano transazioni raw con crate precedenti alla 4.2 incontrano lo stesso problema. Le chiamate RPC a getBlock e getTransaction con maxSupportedTransactionVersion: 0 restituiscono -32015 Transaction version (1) is not supported by the requesting client; getTransactionsForAddress in modalità full segnala lo stesso errore su ogni riga interessata. Il problema non ti riguarda se leggi già le risposte JSON parsate di ERPC con la versione 1 impostata.

Imposta maxSupportedTransactionVersion a 1 nell’oggetto delle opzioni: il secondo parametro di getBlock e getTransaction, e anche le opzioni di getTransactionsForAddress:

json

{
  "maxSupportedTransactionVersion": 1
}

{
  "maxSupportedTransactionVersion": 1
}

Aggiorna il Solana Stream SDK alla 2.0.0: solana-stream-sdk in Rust su crates.io, oppure @validators-dao/solana-stream-sdk e @validators-dao/solana-shreds-client su npm. Aggiorna separatamente @validators-dao/solana-entry-decoder alla 2.5.0. 1.4.0 ed entry-decoder 2.4.0 non supportano v1. I decoder Rust scritti in proprio dovrebbero passare a solana-entry 4.2.x.

Q. In quali regioni si trovano i vostri nodi?

Attualmente operiamo nodi nelle seguenti regioni:

Francoforte (FRA)
Amsterdam (AMS)
Londra (LON)
Dublino (DUB)
New York (NY)
Chicago (CHI)
Salt Lake City (SLC)
Tokyo (TY)
Singapore (SGP)
Sydney (SYD)

ERPC misura la latenza di rete effettiva in base a percorsi di routing reali, selezionando automaticamente la regione con la latenza più bassa anziché affidarsi alla distanza in linea retta. Questo approccio non solo migliora la latenza per i singoli utenti, ma migliora anche l’efficienza complessiva della rete e rafforza la resilienza globale di ERPC contro potenziali attacchi.

Se il tuo ambiente non seleziona automaticamente la regione ottimale, contattaci tramite ERPC Web Dashboard.

ERPC Web Dashboard: https://dashboard.erpc.global/it

Q. La latenza mostra 9999ms e viene selezionata una regione non ottimale. Cosa devo fare?

Per la selezione della regione Shreds, ERPC invia sonde di latenza ICMP al tuo IP registrato dagli host proxy elencati di seguito. Consenti le richieste echo ICMP in entrata da ogni IP sorgente elencato. Se sono bloccate da un firewall (ufw, firewall cloud, security group, ecc.), la misurazione può diventare 9999ms e potrebbe essere selezionata una regione non ottimale. Più IP in una regione sono host di sonda distinti; sono tutti necessari.

Regione	IP sorgente ICMP
🇳🇱 Amsterdam	`82.21.43.35`
🇺🇸 New York	`151.243.244.162`
🇩🇪 Frankfurt	`151.241.178.73`
🇯🇵 Tokyo	`143.20.238.88`
🇸🇬 Singapore	`151.245.186.3`
🇬🇧 London	`151.241.65.10`

Far Point selezionato

Il Far Point di Shared Shreds è un'opzione di fallback a capacità limitata. Ogni endpoint supporta complessivamente fino a 32 stream simultanei inoltrati tramite proxy per tutti i clienti, non 32 posti per ciascun cliente. Lo streaming è più efficace quando il subscriber viene eseguito vicino all'endpoint Shreds selezionato; gli stream su lunghe distanze mantengono impegnati più a lungo le connessioni condivise, le finestre di controllo del flusso e la capacità di uscita. Per contribuire a mantenere reattivo l'ambiente condiviso, consenti tutti gli indirizzi IP sorgente elencati per le sonde ICMP regionali ed esegui nuovamente la selezione della regione. Per un utilizzo continuativo, valuta un ERPC VPS vicino all'endpoint selezionato. Per UDP Forwarding Standard, seleziona una regione disponibile durante la configurazione iniziale e configura come destinazione un indirizzo IPv4 pubblico valido e non vuoto con la relativa porta. La regione e la destinazione possono essere modificate in seguito dalla dashboard. Il cambio di regione modifica l'IP sorgente dell'inoltro, quindi il firewall lato ricezione deve consentire il nuovo IP sorgente dell'inoltro.

Usa un ERPC VPS vicino a questo endpoint · Configura UDP Forwarding Standard Leggi la guida rapida di Direct Shreds

Q. Ho inserito il mio IP nell’allowlist, ma non riesco ancora a connettermi. Cosa devo controllare?

Usa l’endpoint HTTPS crittografato selezionato nella Dashboard. HTTPS usa la porta 443; HTTP sulla porta 80 resta l’opzione non crittografata a bassa latenza.

Entrambi i trasporti usano la stessa allowlist degli IP registrati. Usa l’endpoint selezionato nella Dashboard: HTTPS sulla 443 o HTTP sulla 80.

Endpoint HTTPS: usa l’endpoint selezionato nella Dashboard sulla porta 443.
Endpoint HTTP: usa l’endpoint selezionato nella Dashboard sulla porta 80.
Usa l’URL mostrato nella Dashboard con https:// o http://.

L’autenticazione si basa sul tuo indirizzo IP registrato. Non aggiungere header x-token, token o Authorization, a meno che una pagina di prodotto specifica non lo indichi esplicitamente.

Q. Ho usato solo WebSocket o Geyser gRPC (YellowStone) in precedenza. Avete degli esempi?

Sì. Puoi iniziare rapidamente a testare le connessioni Shreds e lo sviluppo di applicazioni usando SLV.

Consulta la seguente guida per i dettagli:

Guida rapida Shreds

Q. Posso registrare due indirizzi IP?

Puoi usare un endpoint per abbonamento. Se desideri usare due indirizzi IP, devi sottoscrivere due abbonamenti separati.

Q. Quale regione consigliate?

Non esiste un’unica regione che sia sempre la migliore. Solana è globale e il ruolo di leader ruota tra i validator, slot dopo slot. Le regioni con più validator e più stake ottengono leader slot più spesso, il che può aiutare le transazioni a essere incluse più velocemente. Il compromesso è che anche il traffico concorrente si concentra lì, quindi una regione meno affollata a volte può offrire risultati migliori a seconda della tua strategia.

Come punto di partenza pratico, scegli una regione densa di validator come Francoforte o la costa orientale degli Stati Uniti quando conta di più un flusso costante di leader slot, oppure posizionati vicino a un validator target specifico quando la priorità è l’esecuzione sul percorso più breve. Usa Validators Solutions per comprendere la distribuzione pubblica della rete Solana, poi usa la ERPC Leader Slot API e misurazioni reali per decidere se è appropriato un deployment su regione singola, doppia o globale.

Report sulla distribuzione di Solana Mainnet

Q. Ho bisogno di una latenza di ~400ms o migliore.

Per raggiungere una latenza entro circa 400ms, considera questi punti essenziali:

Comprensione realistica dei valori di ping: i valori di ping indicano condizioni ideali e non riflettono la latenza effettiva nelle comunicazioni in streaming, che tipicamente presentano una latenza pari a circa 5 volte quella del ping. Ad esempio, un ping di 100ms tra continenti si traduce realisticamente in circa 500ms di latenza. Pertanto, l’infrastruttura deve essere collocata nella stessa regione per raggiungere una latenza di ~400ms.
- Valori di ping tipici di riferimento:
  - Stessa rete: ~0.1ms
  - Private Network Interconnect (PNI): ~0.2ms
  - Stesso data center: ~0.3ms
  - Stessa città: ~1ms
  - Paese vicino: ~5–10ms
  - Intercontinentale: ~100–300ms
Evitare la trappola della latenza media: i validator Solana sono dispersi geograficamente in tutto il mondo e lo schedule dei leader cambia casualmente a ogni epoch. Affidarsi alla latenza media per raggiungere ~400ms non è praticabile. Devi invece tracciare con precisione gli schedule dei validator nella tua regione specifica per identificare gli slot con la latenza più bassa. Per ottenere costantemente la latenza minima, è necessaria un’infrastruttura in tutte le regioni rilevanti. Nella stessa regione, l’acquisizione dei dati può avvenire in decine di millisecondi e la trasmissione in pochi millisecondi.
Tracciamento dello schedule dei leader: monitora lo schedule dei validator leader per la tua regione usando la ERPC Leader Slot API (getLeaderSlots). Restituisce lo schedule dei prossimi leader, il peso dello stake per l’epoch corrente, la geolocalizzazione stimata dei validator e i valori di ping di riferimento, così puoi individuare gli slot a latenza più bassa su cui puntare prima che arrivino. I dati pubblici in stile mappa e le API RPC native sono utili per una visibilità ampia della rete, ma non sono abbastanza precisi per il timing di esecuzione. La Leader Slot API colma questa lacuna con la granularità necessaria per le decisioni di routing e trading.
- Documentazione ERPC Leader Slot API
- ERPC Web Dashboard

Validators Solutions - Dati della rete Solana

Dati della rete Solana: Validators Solutions

Q. Come posso fare trading zero-block (zero-slot)?

Per riuscire a fare trading zero-block (zero-slot) servono strategie più sofisticate, come le seguenti:

Identificare le zone di opportunità: i validator Solana sono distribuiti globalmente ed è fisicamente impossibile ottenere la latenza ottimale per ogni slot. Pertanto, monitora gli schedule dei leader dei validator nella regione in cui si trova la tua infrastruttura e identifica le zone di opportunità più favorevoli. Anche distribuire l’infrastruttura su più regioni può essere vantaggioso. Ad esempio, Francoforte è una regione chiave grazie alla sua elevata densità di validator, che si traduce in una selezione dei leader più frequente e maggiori opportunità di trading.

Usa la ERPC Leader Slot API (getLeaderSlots) per consultare lo schedule dei prossimi leader, il peso dello stake per l’epoch corrente, i dati stimati di geolocalizzazione dei validator e i valori di ping di riferimento con una precisione di gran lunga superiore rispetto alle fonti di dati pubbliche in stile mappa o alle API RPC native. Questo ti permette di mappare le zone di opportunità prima che arrivino gli slot ed eseguire operazioni a latenza quasi zero.
- Documentazione ERPC Leader Slot API
- ERPC Web Dashboard
Implementare nodi dedicati: se fatichi a competere, considera l’implementazione di nodi dedicati. I nodi condivisi subiscono latenza a causa del traffico di altri utenti e quindi non sono consigliati. Inoltre, collocare il tuo nodo dedicato nella stessa rete della tua applicazione riduce significativamente la latenza di rete e ottimizza le prestazioni.

Q. Posso usare un endpoint specifico?

Per mantenere un ambiente a bassa latenza, il nostro sistema seleziona automaticamente il nodo disponibile più vicino. Se desideri usare un endpoint specifico, consigliamo di noleggiare un server situato il più vicino possibile a quell’endpoint.

Q. Perché gli endpoint dedicati sono più veloci?

Gli endpoint condivisi sono utilizzati da più clienti che condividono le stesse risorse. Quando il traffico cresce, la latenza tende ad aumentare. Le risorse del server hanno limiti fisici e la quantità di lavoro che possono gestire è finita. Quando troppe richieste arrivano contemporaneamente, devono essere elaborate in sequenza, il che si traduce in tempi di risposta più lenti.

Sebbene adottiamo varie misure per ottimizzare le prestazioni anche sugli endpoint condivisi, con gli endpoint dedicati sei l’unico utente della risorsa. Ciò significa che non risenti in alcun modo degli altri utenti, il che garantisce risposte costantemente stabili e veloci.

Inoltre, gli endpoint dedicati offrono opzioni di comunicazione senza TLS, come HTTP. Saltando l’handshake TLS (circa 20ms), la comunicazione diventa ancora più veloce rispetto a HTTPS.

Q. Il prezzo promozionale aumenterà dopo la sottoscrizione?

Finché il tuo abbonamento rimane attivo, il prezzo promozionale che hai bloccato al momento dell’iscrizione resta in vigore. Gli ambienti in grado di reggere il workload in tempo reale di Solana sono scarsi a livello globale e prevediamo di aumentare i prezzi di listino in linea con la crescente domanda di hardware e rete. Le configurazioni con specifiche più elevate e le regioni ad alta domanda si esauriscono più velocemente, quindi bloccare l’attuale prezzo promozionale è la scelta più conveniente nel lungo periodo.

Q. Voglio pagare in crypto

I pagamenti in crypto sono disponibili dalla ERPC Web Dashboard quando il paese del tuo indirizzo di fatturazione registrato è uno dei paesi membri dell’UE. Se tutte le carte di pagamento registrate sul tuo account sono state emesse fuori dall’UE, i pagamenti in crypto non sono disponibili. Puoi usare SOL, USDC o EURC per acquistare ERPC Credits.

Usa questi ERPC Credits per attivare o continuare i piani ERPC. Apri la dashboard, scegli il pagamento in crypto, invia il trasferimento dal tuo wallet e la dashboard verificherà la transazione e applicherà i crediti al tuo account.

Paesi supportati: Austria, Belgio, Bulgaria, Croazia, Cipro, Cechia, Danimarca, Estonia, Finlandia, Francia, Germania, Grecia, Ungheria, Irlanda, Italia, Lettonia, Lituania, Lussemburgo, Malta, Paesi Bassi, Polonia, Portogallo, Romania, Slovacchia, Slovenia, Spagna, Svezia.

Per i paesi non presenti nell’elenco, paga con carta di credito.

ERPC Web Dashboard

Q. Perché ShredStream non include tutte le transazioni?

Per progettazione, gli Shreds non includono ogni transazione sulla blockchain Solana. Monitorare tutte le transazioni richiederebbe il deployment di numerosi proxy a livello globale e la ricezione di Shreds da ogni validator, il che non è pratico.

In genere, gli utenti operano con un sottoinsieme dei dati disponibili, poiché questo approccio è sufficiente per la maggior parte delle applicazioni reali. Se il tuo caso d’uso richiede una copertura completa dei dati senza alcuna perdita, gli Shreds potrebbero non essere adatti.

Per scenari che richiedono un monitoraggio più completo, Geyser gRPC offre un’affidabilità superiore rispetto agli Shreds. Tuttavia, raggiungere il 100% di copertura dei dati sulla blockchain Solana richiede comunque il deployment di numerosi edge server, il che potrebbe non essere realistico in pratica.

Geyser gRPC offre un’affidabilità superiore al 99%, notevolmente più alta degli Shreds, un fatto confermato da molti utenti, inclusi noi. Gli Shreds, tuttavia, offrono in genere un’affidabilità superiore al 90%.

Sebbene non catturino ogni transazione, il loro vantaggio chiave è la capacità di recuperare la maggior parte delle transazioni più velocemente di Geyser gRPC.

Per una comprensione più approfondita, consigliamo di esplorare i protocolli Turbine e Gulf Stream di Solana:

Q. Voglio il miglior ambiente possibile.

Per UDP Forwarding Standard, seleziona una regione disponibile durante la configurazione iniziale e configura come destinazione un indirizzo IPv4 pubblico valido e non vuoto con la relativa porta. La regione e la destinazione possono essere modificate in seguito dalla dashboard. Il cambio di regione modifica l'IP sorgente dell'inoltro, quindi il firewall lato ricezione deve consentire il nuovo IP sorgente dell'inoltro.

Contattaci tramite l’ERPC Web Dashboard per maggiori dettagli.

ERPC Web Dashboard

🔗 ERPC Web Dashboard

Q. Com’è la latenza?

La latenza varia a seconda del metodo di misurazione e del tuo specifico ambiente di utilizzo. Piuttosto che concentrarti su valori numerici esatti, è fondamentale assicurarti che la latenza soddisfi i tuoi requisiti operativi effettivi.

Forniamo strumenti facili da usare in TypeScript e Rust per misurare la latenza.

Q. Questo RPC (gRPC, Shreds) è più veloce degli altri?

Puntiamo alla velocità in ogni livello di piano e siamo lieti che venga misurata a confronto diretto con qualsiasi altro provider. I risultati possono variare in base alla regione, all’uso di un endpoint condiviso o dedicato, al protocollo che usi (WebSockets, gRPC o Shreds) e al linguaggio di programmazione del tuo client.

Se il nostro servizio ti risulta più lento, facci sapere tramite la ERPC Web Dashboard le condizioni specifiche e i concorrenti con cui lo hai confrontato. Identificheremo la causa e miglioreremo ulteriormente la velocità.

ERPC Web Dashboard

Q. Quale piano offre le prestazioni più veloci?

In generale, il nostro piano di livello più alto offre le prestazioni più veloci grazie a CPU superiori, maggiori capacità di memoria e configurazioni hardware robuste.

Offriamo anche soluzioni personalizzate se hai bisogno di server ancora più potenti, ma i nostri piani standard sono progettati per offrire un rapporto prezzo/prestazioni ottimale.

Siamo convinti di offrire prestazioni di livello mondiale in ogni fascia di prezzo. Se trovi un provider più veloce nella stessa fascia di prezzo, faccelo sapere, così potremo indagare e migliorare.

Q. Riscontro una latenza elevata. Perché?

La latenza aumenta significativamente con la distanza dall’endpoint. Consigliamo di accedere da un server situato più vicino all’endpoint fornito. Gli ambienti più veloci sono disponibili tramite i nostri server Bare-Metal e i servizi VPS.

Q. Qual è il più veloce: WebSockets, gRPC o Shreds?

In base al feedback dei clienti, l’ordine delle prestazioni è:

Shreds > gRPC > WebSockets

Se la tua esperienza differisce, informaci.

Q. La latenza non è quella che mi aspettavo.

Le prestazioni variano significativamente a seconda del linguaggio di programmazione utilizzato. In generale, l’ordine delle prestazioni è:

Rust > Go > TypeScript (JavaScript) > Python

Per confronti dettagliati, consulta:

Confronto di velocità tra linguaggi di programmazione

Consigliamo vivamente Rust per le massime prestazioni.