ERPC migliora significativamente l’infrastruttura di rete Solana. Piattaforma proxy ad alte prestazioni in Rust completamente aggiornata, distribuita in tutte le regioni per RPC condivisi, gRPC e Shredstream. Aggiornamenti con zero downtime implementati

ERPC, gestito da ELSOUL LABO B.V. (sede: Amsterdam, Paesi Bassi; CEO: Fumitake Kawasaki) e Validators DAO, ha completato un importante aggiornamento della propria infrastruttura di rete Solana.

Questo aggiornamento è già stato applicato a tutte le regioni e a tutti gli endpoint condivisi forniti da ERPC (Solana RPC, Geyser gRPC e Shredstream). Abbiamo aggiornato come sistema integrato i comportamenti infrastrutturali che tendono a influenzare direttamente i risultati reali, inclusi l’avvio delle connessioni, l’elaborazione TLS, il controllo della cache, il trasporto HTTP/1.1 e HTTP/2, il comportamento delle connessioni di lunga durata e le metriche per l’osservabilità e la risoluzione dei problemi.

Mantenendo la reattività quotidiana come riferimento, abbiamo anche riorganizzato il comportamento di rete sottostante affinché sia meno soggetto a polarizzazioni o instabilità negli scenari in cui i risultati tendono a degradare — come la volatilità sotto carico di picco, l’instabilità nel funzionamento prolungato e le cascate innescate da disconnessioni e riconnessioni. Di conseguenza, l’ambiente è ora strutturato meglio per sostenere sia le prestazioni sia la stabilità nelle operazioni pratiche su Solana.

Inoltre, siamo passati a un’architettura operativa che consente di applicare modifiche alla configurazione di rete e aggiornamenti della piattaforma con zero downtime completo. Non ci sono modifiche a prezzi, specifiche, autenticazione o rate limit, e i clienti ERPC esistenti ricevono i benefici dell’aggiornamento senza alcuna configurazione aggiuntiva o modifica operativa.

Contesto

Nelle operazioni pratiche su Solana, il tempo medio di risposta e la latenza in condizioni normali sono requisiti di base critici. Allo stesso tempo, esistono scenari in cui è il comportamento stesso dell’infrastruttura di rete sottostante a determinare i risultati — come i momenti di carico concentrato, le connessioni di lunga durata e le fasi in cui avvengono disconnessioni e riconnessioni.

Gli endpoint condivisi in particolare devono gestire sia raffiche di invio di transazioni in finestre temporali brevi sia connessioni sempre attive tramite WebSocket e gRPC. In queste condizioni, il comportamento a livello infrastrutturale — avvio delle connessioni, handshake TLS, comportamento del trasporto, gestione della cache e ripresa dagli stati di inattività — si riflette direttamente nell’esperienza utente e nei risultati di esecuzione.

Con la reattività media come riferimento esplicito, i risultati reali possono comunque essere decisi da fattori diversi durante i picchi o nel funzionamento prolungato. Pertanto, le operazioni pratiche richiedono che l’usabilità quotidiana e la continuità negli scenari soggetti a guasti siano entrambe raggiunte allo stesso tempo.

ERPC ha progettato e gestisce una propria piattaforma proxy ad alte prestazioni in Rust come base per le comunicazioni Solana, mantenendo un’architettura che applica lo stesso approccio in tutte le regioni e facendo evolvere continuamente la piattaforma. Questo aggiornamento riesamina i problemi osservati operativamente come un sistema unificato — dall’avvio della connessione al funzionamento di lunga durata — e riorganizza di conseguenza l’intera base di rete.

Cosa cambia per i clienti ERPC

Con questo aggiornamento, i clienti ERPC vedranno innanzitutto un comportamento stabilizzato all’avvio delle connessioni. Durante l’instaurazione della connessione, inclusa la fase TLS, condizioni disallineate e retry non necessari sono meno probabili, rendendo più facile per transazioni e stream entrare in elaborazione in modo affidabile fin dall’inizio.

In secondo luogo, abbiamo riorganizzato i comportamenti infrastrutturali che tendono a causare volatilità durante i picchi di carico. Combinando il filtraggio precoce delle connessioni non necessarie con aggiornamenti simultanei al trasporto HTTP/1.1 e HTTP/2 e alla coerenza dei timeout, alla salute dei pool di connessioni, al comportamento della cache in condizioni di contesa e alle metriche per l’osservabilità e la risoluzione dei problemi, abbiamo rafforzato le condizioni che aiutano a prevenire comportamenti polarizzati anche quando il carico si concentra.

Per gli stream WebSocket e gRPC di lunga durata e per i carichi di lavoro di monitoraggio sempre attivi, la continuità delle connessioni è migliorata. La frequenza degli eventi di disconnessione/riconnessione/risincronizzazione — e la probabilità che tali eventi si propaghino a cascata sui risultati — si è ridotta, rendendo più facile costruire operazioni che presuppongono un funzionamento prolungato.

I miglioramenti al controllo della cache e al comportamento del trasporto riducono inoltre la probabilità di refetch non necessari e di elaborazioni sprecate durante la congestione. La larghezza di banda e il margine di elaborazione hanno maggiori probabilità di rimanere utilizzabili e stabili, e l’ampliamento di metriche e osservabilità rende più facile accorciare l’identificazione delle cause radice e i tempi di ripristino.

Inoltre, consentendo modifiche di configurazione e aggiornamenti della piattaforma con zero downtime, abbiamo stabilito condizioni operative che rendono più facile aumentare prestazioni, stabilità e qualità complessiva della piattaforma ad alta frequenza. La capacità di continuare a migliorare senza mettere in pausa la piattaforma rafforza ulteriormente la continuità per i clienti.

Dettagli dei miglioramenti

Questo aggiornamento non è presentato come una release guidata da nomi di funzionalità specifiche o numeri di versione. Al contrario, scompone gli scenari che tendono a dominare i risultati reali su Solana nei seguenti livelli — avvio delle connessioni, TLS, il confine L4/HTTP, il trasporto H1/H2, la cache, l’osservabilità, il comportamento in caso di guasto e i prerequisiti operativi di lungo termine — e aggiorna la piattaforma affinché questi livelli si colleghino senza contraddizioni.

Di seguito, spieghiamo i miglioramenti incorporati in termini di come contribuiscono all’esperienza dei clienti e ai risultati operativi.

Miglioramenti all’avvio delle connessioni e alla gestione TLS

Abbiamo ampliato il contesto TLS gestito durante l’instaurazione della connessione e aggiornato la struttura affinché lo stato richiesto possa essere conservato e applicato in modo appropriato. Ciò rende meno probabili condizioni disallineate e retry non necessari all’avvio della connessione.

Abbiamo anche riorganizzato la gestione TLS — inclusa la verifica dei certificati e la verifica dell’hostname — affinché i requisiti di sicurezza possano essere soddisfatti riducendo le condizioni in cui fallimenti dell’handshake o incoerenze di gestione creano perdite all’avvio che si propagano a cascata sui risultati. Non si tratta semplicemente di un rafforzamento della sicurezza; contribuisce a stabilizzare il comportamento dall’inizio della connessione fino all’ingresso in elaborazione per i carichi di lavoro Solana.

Abbiamo inoltre rafforzato i meccanismi che rendono il comportamento adiacente a TLS più facile da osservare e da diagnosticare. Negli scenari in cui l’avvio domina i risultati, la capacità di riprodurre i problemi, identificarne le cause e applicare rapidamente le correzioni diventa la capacità che preserva la qualità dell’esperienza.

Preservare il margine tramite il filtraggio precoce delle connessioni non necessarie

Abbiamo introdotto un meccanismo per filtrare le connessioni TCP in una fase precoce, aggiornando la piattaforma affinché connessioni illegittime o non necessarie abbiano meno probabilità di mettere sotto pressione il traffico legittimo. Negli endpoint condivisi, le richieste di connessione possono impennarsi a causa di fattori esterni o squilibri temporanei.

Il filtraggio in fase precoce aiuta a garantire che le connessioni legittime abbiano meno probabilità di bloccarsi all’avvio, migliorando la probabilità che il margine rimanga disponibile durante i picchi di carico. Di conseguenza, il comportamento ha meno probabilità di polarizzarsi anche negli scenari di carico concentrato, e le condizioni per una distribuzione stabile della latenza sono rafforzate.

Chiarire il modello di connessione riorganizzando il confine L4/HTTP

L’infrastruttura di rete non si esaurisce in HTTP. L’instaurazione e la continuità delle connessioni dipendono dalle condizioni L4, e la volatilità a quel livello si propaga nell’esperienza dei protocolli di livello superiore.

In questo aggiornamento, abbiamo astratto la gestione degli stream L4 e riorganizzato la struttura affinché il modello di connessione possa essere gestito in modo più esplicito. Ciò rende più facile per la piattaforma sostenere un comportamento coerente negli scenari in cui le connessioni continuano a crescere, le implementazioni client variano e il funzionamento di lunga durata causa transizioni di stato.

Anche il comportamento dei retry è stato riorganizzato per ridurre i pattern in cui la volatilità di breve durata si propaga a cascata nell’esperienza utente. La stabilità pratica dipende meno dall’eliminazione dei guasti isolati e più dalla prevenzione delle cascate di guasti.

Miglioramenti al trasporto HTTP/1.1 e HTTP/2 e al comportamento di lungo periodo

Abbiamo aggiunto misurazioni che consentono di tracciare in modo coerente il volume di dati trasferiti attraverso HTTP/1.1 e HTTP/2. Ciò rende più facile identificare dove si verificano stalli o colli di bottiglia nella pipeline di trasporto, migliorando sia la risoluzione dei problemi sia la velocità con cui le correzioni possono essere applicate.

Abbiamo anche riorganizzato il comportamento dei timeout di scrittura del body in HTTP/2 affinché stalli e blocchi innaturali siano meno probabili durante il carico concentrato o lo streaming di lunga durata. Nel funzionamento di lungo periodo, ciò che conta non sono le prestazioni di picco in condizioni ideali, ma la capacità di impedire che il comportamento collassi durante le transizioni di stato.

Anche il comportamento degli idle timeout e la gestione dei pool di connessioni sono stati revisionati, rimuovendo fattori di instabilità che tendono ad accumularsi durante il funzionamento prolungato. Sul lato HTTP/1.1, abbiamo riorganizzato il comportamento di spegnimento sicuro per le connessioni che trattengono richieste incomplete, riducendo le fonti di volatilità sia nell’utilizzo delle risorse sia nel comportamento.

Miglioramenti al controllo della cache e alla qualità operativa

Abbiamo migliorato la capacità di tracciare perché una risorsa non viene messa in cache, aumentando la spiegabilità del comportamento della cache. In pratica, ciò che domina non è se la cache esiste, ma in quali condizioni viene applicata e in quali condizioni decade.

Abbiamo riorganizzato il comportamento dei lock, la gestione dei contenuti stale e i pattern di riconvalida affinché il degrado dell’esperienza abbia meno probabilità di propagarsi a cascata quando si verifica contesa sotto carico di picco. Abbiamo anche organizzato i controlli di eviction per i casi in cui il numero di risorse in cache cresce, e affinato i comportamenti sui contenuti parziali (incluse le richieste Range), rafforzando le condizioni che riducono refetch non necessari e latenza nei carichi di lavoro reali.

Questi miglioramenti riducono i casi in cui il comportamento della cache diventa un outlier, rendendo meno probabile che i clienti debbano progettare le operazioni attorno all’incertezza a livello infrastrutturale.

Miglioramenti al comportamento in caso di guasto, al logging e all’osservabilità

Il comportamento in caso di guasto e il logging sono stati riorganizzati affinché sia più facile capire cosa è successo quando si verificano problemi. I pattern in cui gli errori a valle si propagano a cascata nel comportamento di cache/trasporto e peggiorano l’esperienza sono ridotti, rendendo più facile circoscrivere il raggio d’impatto.

I miglioramenti di osservabilità e risoluzione dei problemi non intendono dichiarare «zero incidenti», ma accorciare il tempo di ripristino quando gli incidenti si verificano. Ciò riduce il rischio negli scenari di carico di picco e di funzionamento prolungato.

Aggiornamenti delle dipendenze e correzioni di sicurezza come prerequisiti operativi di lungo termine

Abbiamo incorporato aggiornamenti delle dipendenze e correzioni di sicurezza per mantenere i prerequisiti per il funzionamento della piattaforma a lungo termine. Ciò include aggiornamenti relativi alla versione minima supportata di Rust (MSRV) e all’allineamento della CI, rafforzando la base necessaria per far evolvere continuamente la piattaforma.

La capacità di continuare ad aggiornare in sicurezza è essa stessa un requisito per la qualità di lungo termine.

Transizione a operazioni con zero downtime

In precedenza, brevi downtime potevano verificarsi durante modifiche alla configurazione di rete o aggiornamenti della piattaforma. Con questo aggiornamento, siamo passati a un’architettura in cui queste operazioni possono essere applicate con zero downtime completo.

Gli endpoint condivisi hanno connessioni sempre attive e momenti continui in cui il tempismo conta. Anche un breve downtime può innescare disconnessioni, riconnessioni e cascate di risincronizzazione, e quel costo può propagarsi sui risultati. Gli aggiornamenti con zero downtime riducono la probabilità di queste cascate e impediscono che le operazioni di lunga durata vengano frammentate.

Allo stesso tempo, ERPC dispone ora di condizioni operative che consentono di riflettere rapidamente i problemi osservati in miglioramenti. Una frequenza di iterazione più alta ci consente di eliminare continuamente volatilità e comportamenti limite all’interno delle operazioni di produzione.

Impatto per servizio

Solana RPC (HTTP / WebSocket)

I miglioramenti all’avvio delle connessioni, a TLS, al controllo della cache e al comportamento del trasporto interessano sia le letture di dati sia l’invio delle transazioni. Mantenendo l’usabilità quotidiana, i fattori che polarizzano i risultati durante i picchi di carico sono ridotti, e le condizioni per preservare il margine durante la congestione sono rafforzate.

Geyser gRPC

La continuità delle connessioni è migliorata per l’uso in streaming di lunga durata. Il trasporto HTTP/2, la coerenza dei timeout, la salute dei pool di connessioni e le misurazioni di trasporto ampliate lavorano insieme per ridurre la probabilità che i costi di riconnessione/risincronizzazione si propaghino sui risultati.

Shredstream (Direct Shreds)

Con la gestione delle connessioni e i miglioramenti all’avvio progettati per la consegna continua, le condizioni sono rafforzate affinché dati mancanti o latenza siano meno probabili sotto congestione. La continuità stabile per il rilevamento e il following diventa più facile da sostenere.

Collegare R&D e operazioni di produzione

La base di sistemi distribuiti che include ERPC è stata riconosciuta come progetto R&D nell’ambito del programma WBSO del governo olandese. È stata stabilita una struttura in cui i problemi osservati operativamente possono essere incorporati come soggetti di ricerca e migliorati attraverso verifica e iterazione.

Questo aggiornamento della base di rete è una di queste iterazioni applicata a tutte le regioni, riflessa in prestazioni e stabilità pratiche. Mantenere operazioni e R&D collegate è un prerequisito per collegare continuamente ciò che si osserva in produzione al prossimo aggiornamento, invece di fermarsi a miglioramenti una tantum.

All’interno di ERPC, i pattern di utilizzo reali, la variabilità del carico e il comportamento nelle modalità di guasto sono incorporati in cicli ripetuti di verifica e miglioramento che alzano progressivamente la qualità della base di rete. Questo aggiornamento è stato eseguito all’interno di quel quadro integrato di R&D e operazioni di produzione.

Informazioni per i clienti

Questo aggiornamento è già stato applicato a tutte le regioni e a tutti gli endpoint condivisi. I clienti ERPC esistenti non devono modificare configurazioni o operazioni. Non ci sono modifiche a prezzi, specifiche, autenticazione o rate limit.

Poiché gli endpoint condivisi devono sostenere contemporaneamente sia picchi brevi sia connessioni di lunga durata, le condizioni sono state riorganizzate affinché il comportamento abbia meno probabilità di polarizzarsi sotto questi carichi di lavoro misti. Anche quando modifiche di configurazione o aggiornamenti della piattaforma avvengono durante le operazioni, le modifiche sono applicate con zero downtime, quindi i clienti non devono pianificare frammentazioni delle connessioni o risincronizzazioni by design.

Per domande su architettura, ottimizzazione specifica per carichi di lavoro o feedback operativo, contattaci tramite il Discord ufficiale di Validators DAO.

Collegando continuamente osservazioni e feedback dalla produzione ai miglioramenti, ERPC ha progressivamente alzato la qualità della propria base. Continueremo ad accumulare miglioramenti con zero downtime e a fornire un’infrastruttura di rete che sostiene i risultati reali su Solana.

Discord ufficiale di Validators DAO: https://discord.gg/C7ZQSrCkYR
Sito ufficiale di ERPC: https://erpc.global/it