ERPC aggiunge HTTPS agli endpoint condivisi Solana Shreds e Geyser gRPC — HTTPS o HTTP, a seconda del caso d’uso
ELSOUL LABO B.V. (sede: Amsterdam, Paesi Bassi; CEO: Fumitake Kawasaki) e Validators DAO, gli operatori di ERPC, hanno aggiunto il supporto HTTPS agli endpoint condivisi Shreds gRPC e Geyser gRPC. Insieme al trasporto HTTP offerto da sempre, è ora possibile scegliere tra HTTPS e HTTP.
Il cambiamento riguarda Direct Shreds Connect e Direct Shreds Turbo sul lato Shreds gRPC, e i piani Standard, Premium e Burst dello Stream Geyser gRPC condiviso.
È possibile scegliere un endpoint HTTPS, crittografato e sicuro, oppure un endpoint HTTP che non comporta alcuna elaborazione TLS. Nella terminologia gRPC, il primo corrisponde a gRPC su TLS e il secondo a HTTP/2 in chiaro (plaintext). In questo modo viene coperta una gamma molto più ampia di casi d’uso: dai carichi di lavoro in cui conta soltanto la latenza, a quelli in cui conta soprattutto la riservatezza di ciò che si sottoscrive.
Il nome host dell’endpoint non cambia. Cambiano soltanto lo schema e la porta: HTTPS usa la porta 443, HTTP la porta 80. Il passaggio dall’uno all’altro si effettua nell’ERPC Web Dashboard.
La novità è HTTPS — l’HTTP esistente continua invariato
Gli endpoint di stream condivisi di ERPC sono stati finora erogati su HTTP.
Ciò che è stato aggiunto è il lato HTTPS. Le connessioni HTTP esistenti non cambiano né nelle specifiche né nel comportamento e possono continuare a essere utilizzate esattamente come prima. Per i clienti già connessi via HTTP non è richiesta alcuna azione.
Non è previsto alcun ritiro dell’HTTP. Resta disponibile come opzione per i carichi di lavoro in cui la latenza viene prima di tutto.
HTTPS — connessioni crittografate e sicure
Su un endpoint HTTPS, l’intero scambio tra il client e ERPC è crittografato con TLS.
Sia il contenuto della richiesta di sottoscrizione sia i dati dello stream restituiti vengono crittografati con TLS: di norma il contenuto del payload non è leggibile lungo il percorso. Nell’ERPC Web Dashboard, HTTPS è il trasporto selezionato per impostazione predefinita.
L’handshake TLS avviene principalmente al momento in cui la connessione viene stabilita. La crittografia e la decrittografia dei dati dello stream proseguono anche dopo, ma uno stream gRPC mantenuto aperto a lungo non paga ripetutamente il costo dell’handshake.
HTTP — l’opzione a bassa latenza senza elaborazione TLS
Su un endpoint HTTP non esistono né l’handshake TLS né alcuna operazione di crittografia e decrittografia.
Nell’elaborazione in tempo reale su Solana, ogni elaborazione lungo il percorso che va da dove i dati vengono generati a dove raggiungono l’applicazione influisce sulla latenza. Non richiedendo alcuna crittografia o decrittografia TLS, l’HTTP si presta ai carichi di lavoro a bassa latenza che puntano a ridurre il più possibile le elaborazioni lungo il percorso.
L’HTTP è avvantaggiato nelle configurazioni che ristabiliscono la connessione a intervalli brevi, o in quelle che non possono tollerare alcun overhead lungo il percorso.
Quando l’insieme di un filtro di sottoscrizione assume un significato
L’HTTP è l’opzione a latenza inferiore ma, a seconda di come un progetto lo utilizza, il gruppo di indirizzi richiesti resta esposto lungo il percorso — e per alcuni progetti questo è un problema.
I dati sulla blockchain sono di per sé pubblici. Tuttavia, quando è il loro raggruppamento a essere esposto, esso può assumere un significato che nessun elemento singolo aveva per conto proprio.
Si supponga che un progetto voglia filtrare e monitorare tutti i wallet dei propri clienti. L’elenco di indirizzi contenuto in quella richiesta di sottoscrizione può essere di per sé un’informazione sensibile per quel progetto. Anche quando ogni singolo indirizzo è pubblico, sapere quale insieme di indirizzi viene monitorato come un unico gruppo può offrire indizi sulla base clienti del progetto, su ciò che osserva e sui suoi interessi commerciali.
È proprio in questi casi che l’endpoint HTTPS è utile. In cambio del lavoro di crittografia e decrittografia richiesto da TLS, vengono crittografati i payload sia della richiesta di sottoscrizione sia dei dati dello stream.
Prima la latenza o prima la riservatezza della sottoscrizione? La valutazione cambia da progetto a progetto. ERPC lascia ora questa scelta ai clienti, che possono compierla in base al proprio caso d’uso.
L’ambito: gli endpoint condivisi
Il supporto HTTPS riguarda i seguenti endpoint condivisi:
- Direct Shreds Connect
- Direct Shreds Turbo
- Stream Geyser gRPC condiviso — Standard
- Stream Geyser gRPC condiviso — Premium
- Stream Geyser gRPC condiviso — Burst
HTTPS è già attivo sugli endpoint di stream condivisi di tutte le regioni, e gli endpoint HTTP esistenti sono mantenuti così com’erano. Anche gli endpoint condivisi inclusi in Shreds Bundle e in ERPC Bundle possono utilizzare HTTPS.
Gli endpoint dedicati non rientrano in questo cambiamento. Il Geyser gRPC dedicato e i prodotti Shreds dedicati mantengono invariato il metodo di connessione attuale.
Cambio di protocollo nella Dashboard — l’allowlist degli IP è comune
Il cambio del metodo di connessione si effettua dalla schermata degli endpoint nell’ERPC Web Dashboard.
È possibile passare da HTTPS a HTTP e viceversa: viene mostrato l’URL dell’endpoint corrispondente al trasporto selezionato. L’URL va configurato nel client esattamente come viene visualizzato.
Entrambi i trasporti usano la stessa allowlist degli IP registrati. L’autenticazione continua a basarsi sull’indirizzo IP registrato: non è quindi necessario registrare di nuovo gli IP per passare a HTTPS, né aggiungere token o header Authorization.
I prodotti Shreds condivisi di ERPC continuano dopo la fine di Jito ShredStream
Jito ShredStream termina il servizio il 5 settembre 2026. I prodotti Shreds condivisi di ERPC, invece, continuano a essere offerti anche dopo tale data.
Direct Shreds Connect e Direct Shreds Turbo — entrambi interessati da questa introduzione di HTTPS — insieme ai piani multi-IP di Shreds Bundle e al Direct Shreds Connect incluso in ERPC Bundle, restano tutti disponibili oltre il 5 settembre.
Per chiarezza: la fine del servizio del 5 settembre annunciata il 21 agosto 2026 riguarda i prodotti Shredstream dedicati e Stream Bundle. I prodotti Shreds condivisi non vi rientrano. L’accompagnamento alla migrazione per i clienti con piani dedicati continua a essere gestito individualmente, come prima.
Per i progetti che stanno rivedendo il proprio percorso di ricezione degli Shreds, questo è un momento naturale per valutare le opzioni. Saremo lieti se vorrete provarle.
Da provare con tariffazione oraria, a partire da un’ora
Gli endpoint condivisi di ERPC sono disponibili a partire da un’ora, con tariffazione oraria.
Senza impegnarsi in un piano mensile, è possibile provare sia HTTPS sia HTTP sul carico di lavoro reale e verificare di persona come si bilanciano latenza e riservatezza nel proprio ambiente.
Si può iniziare con una verifica breve e scegliere poi il piano in base a ciò che si è misurato.
Un prodotto UDP Forwarding rinnovato in arrivo a breve
Per UDP Forwarding — che semplifica il percorso di consegna degli Shreds stesso — è in arrivo a breve un prodotto rinnovato.
L’obiettivo è una gamma in cui si possa scegliere il metodo di consegna più adatto al compito: UDP per i carichi di lavoro che mettono la bassa latenza al di sopra di tutto, e Shreds gRPC per la sottoscrizione di stream tramite l’interfaccia gRPC esistente.
Regioni supportate, prezzi, specifiche dettagliate e la data di rilascio ufficiale saranno annunciati non appena pronti.
Un’infrastruttura da scegliere in base al caso d’uso
ERPC non valuta le prestazioni dell’infrastruttura Solana solo in base alle specifiche del server. La vicinanza alla fonte dei dati, il percorso di rete, l’hardware, l’OS e il kernel e il metodo di consegna finale all’utente sono progettati insieme come un’unica infrastruttura a bassa latenza.
Questa introduzione di HTTPS amplia la scelta all’interno di quel metodo di consegna finale. Non esiste un’unica opzione più veloce valida per ogni progetto: quanto peso dare alla latenza rispetto alla riservatezza dipende dalla natura del prodotto.
Per qualsiasi domanda, vi invitiamo a contattarci tramite la chat di supporto nell’ERPC Web Dashboard.
