Per le prestazioni delle app Solana, se vuoi tagliare anche solo 20 ms, gli endpoint RPC dedicati + SWQoS sono la chiave

Per le prestazioni delle app Solana, se vuoi tagliare anche solo 20 ms, gli endpoint RPC dedicati + SWQoS sono la chiave

Per le prestazioni delle app Solana, se vuoi tagliare anche solo 20 ms, gli endpoint RPC dedicati + SWQoS sono la chiave
Nel trading ad alta frequenza e nelle applicazioni Solana mission-critical, anche 20 ms possono fare una differenza decisiva. Gli endpoint RPC dedicati e gli endpoint RPC condivisi differiscono nella loro progettazione fondamentale, e questo divario di 20 ms non può mai essere colmato. Questo articolo spiega il perché e come ERPC risolve il problema dall’inizio alla fine.

Tagliare 20 ms usando http invece di https

Avrai notato che gli URL degli endpoint RPC iniziano di solito con https. La «s» sta per crittografia TLS/SSL, che protegge le comunicazioni. Tuttavia, questa crittografia richiede un handshake e una crittografia/decrittografia costante, aggiungendo circa 20 ms di latenza a ogni richiesta.
In altre parole, se la comunicazione RPC avviene tramite http invece che https, questi 20 ms possono essere eliminati alla radice. Su Solana, dove le aste dei blocchi si concludono in circa 50 ms, questa differenza è critica.

Perché http non può essere usato sugli endpoint condivisi

Qualcuno potrebbe chiedersi: «Allora perché non consentire http sugli endpoint condivisi?» La risposta è semplice: è impossibile.
Consentire http in un ambiente condiviso significherebbe comunicazioni non crittografate, esponendo le transazioni ad attacchi man-in-the-middle, intercettazione dei pacchetti e persino furto di transazioni firmate. Un attaccante che usa lo stesso endpoint condiviso potrebbe realisticamente manomettere o riprodurre le tue transazioni.
Per questo motivo, gli endpoint condivisi devono sempre imporre TLS/SSL. I nostri endpoint RPC condivisi sono progettati per essere il più veloci possibile entro questo vincolo, ma l’overhead di 20 ms del TLS non può essere rimosso per progettazione.

Come l’RPC dedicato elimina i 20 ms

Gli endpoint RPC dedicati limitano l’accesso a client specifici e fidati. Questo ci consente di rimuovere il requisito TLS e di permettere la comunicazione http diretta.
Di conseguenza, una riduzione di 20 ms è garantita. Indipendentemente dal carico degli utenti o dai rischi di attacco, questa differenza strutturale garantisce che il divario di 20 ms tra endpoint condivisi e dedicati non verrà mai colmato.

La sfida rimanente: SWQoS

La velocità da sola non basta. Solana applica lo Stake-weighted QoS (SWQoS), secondo cui i nodi senza fiducia basata sullo stake sono limitati a solo il 20% delle corsie di transazione disponibili.
Ad esempio, le architetture Lite-RPC che inviano le transazioni direttamente al validator leader corrente possono sembrare veloci, ma senza SWQoS restano comunque limitate a quella corsia del 20%. Ciò significa che, anche se il pacchetto arriva rapidamente, le probabilità di inclusione saranno significativamente più basse.
Usare l’RPC dedicato per tagliare 20 ms è fondamentale, ma combinarlo con SWQoS è essenziale per ottenere sia velocità sia successo delle transazioni.
ERPC offre un’opzione per abilitare SWQoS sugli endpoint RPC dedicati.
Ciò significa che puoi combinare RPC dedicato + SWQoS per ottenere sia la riduzione della latenza sia tassi di successo più elevati.
Prezzo di Solana RPC

I problemi che Validators DAO ed ERPC risolvono

ERPC risolve i seguenti problemi:
  • Fallimenti delle transazioni e fluttuazioni di latenza negli ambienti RPC
  • Limitazioni delle prestazioni da parte di molti provider di infrastrutture
  • Il forte impatto della distanza di rete sulla qualità delle comunicazioni
  • Accesso limitato a infrastrutture di alta qualità per i progetti più piccoli
Durante lo sviluppo di Epics DAO, un progetto open source dedicato ai contributi all’ecosistema Solana, abbiamo affrontato la difficoltà di costruire un ambiente di sviluppo Solana realmente ad alte prestazioni e a bassa latenza. Questa sfida ci ha portato a progettare la nostra piattaforma, e da questa base oggi forniamo sia ERPC sia SLV.
Le applicazioni finanziarie e altre applicazioni mission-critical sono particolarmente sensibili a latenza ed errori, poiché incidono direttamente sull’esperienza utente. Gli ambienti Solana sono altamente complessi e, a differenza della finanza tradizionale su internet, i validator sono distribuiti a livello globale. A ciò si aggiunge la complessità delle conoscenze specifiche del Web3: è difficile per gli sviluppatori comprendere appieno il quadro completo, il che ha rallentato i progressi nell’ottimizzazione.
Fornendo un’infrastruttura Solana ad alte prestazioni, miriamo a rimuovere questi ostacoli e a migliorare l’esperienza utente in tutto l’ecosistema. ERPC e il nostro progetto open-source SLV sono entrambi parte integrante di questa missione.