जो भी चाहिए, सब कुछ।Solana से सीधा संपर्क।
RPC, Geyser gRPC, and Direct Shreds run on the network right next to Solana. You talk to the chain directly.
भरोसेमंद infrastructure
गति Solana से दूरी पर निर्भर करती है।
क्षेत्र मायने रखता है। लेकिन अकेले शहर का नाम एक नेटवर्क पाथ नहीं है। एक ही शहर में भी, एक्सटर्नल ट्रांज़िट और अतिरिक्त hops लेटेंसी जोड़ सकते हैं। ERPC ऐसे डेटा सेंटर चुनता है जो Solana सर्वरों के करीब हों, फिर एक्सटर्नल ट्रांज़िट से बचकर और निरंतर टर्बो बूस्ट के साथ रूट छोटे रखता है।
ERPC प्रीमियम मार्ग
कोई एक्सटर्नल ट्रांज़िट नहीं
न्यूनतम RTT
शहर का नाम चयन
एक्सटर्नल ट्रांज़िट / 7 hops
70x धीमी
- 01समान डेटा सेंटरपहले क्षेत्र चुनें, फिर Solana के सबसे करीब का डेटा सेंटर।
- 02कोई बाहरी पारगमन नहींRTT और jitter को टाइट रखने के लिए एक्सटर्नल AS paths से बचें।
- 03पूर्ण थ्रॉटलERPC पावर-सेविंग प्रोफ़ाइल को बंद रखता है और संसाधनों को लगातार टर्बो बूस्ट पर बनाए रखता है।
मापा हुआ benchmark
एक ही class की मशीन। रफ़्तार एक जैसी नहीं।
AMD Turin, 4 vCPU, Amsterdam, Ubuntu 24.04 — दोनों boxes पर बिल्कुल एक जैसा: एक बड़ा cloud और हमारा। spec sheet कहती है दोनों बराबर हैं। bench कुछ और ही कहता है।
silicon तो वही है। फ़र्क है हमारी tuning का — box को बारीकी से tune करके ठीक Solana के बगल में बिठाया गया है।
node_bench · वही run, वही region
ERPC बनाम एक बड़ा cloud · एक ही spec
- CPU computesysbench · 4 threads · जितना ज़्यादा, उतना बेहतर
- ज़्यादा CPU throughput1.9×
- Memory bandwidthSTREAM Triad · 4 GiB · जितना ज़्यादा, उतना बेहतर
- ज़्यादा memory bandwidth3.2×
- Disk IOPSfio · 4K randread · QD32 · जितना ज़्यादा, उतना बेहतर
- ज़्यादा disk IOPS16.6×
- Disk latency · p99fio · 4K randread · QD32 · जितना कम, उतना बेहतर
- tail latency में काफ़ी तेज़25.7×
events/s
MB/s
IOPS
µs
Stake-weighted priority (SWQoS)
अगर आपकी transactions बार-बार fail होती रहती हैं, तो समझिए आप spam वाली lane में फँसे हैं।
Solana के leaders priority bandwidth को दो हिस्सों में बाँटते हैं। stake वाले connections — यानी किसी validator को सौंपी गई SOL — को उस bandwidth का 80% मिलता है। बाकी सब उस बचे हुए 20% के लिए लड़ते हैं — वही lane जो spam से ठसाठस भरी है।
सीधे leader पर निशाना साधना तेज़ चाल लगती है — पर stake के बिना यही वो भीड़भाड़ वाली 20% lane है, और load बढ़ते ही आपकी transaction block तक पहुँचती ही नहीं।
तो असली जवाब है — एक staked validator। हम एक top-tier validator चलाते हैं, जो बेहतरीन RPC lines से जुड़ा हुआ है — hardware को ठीक Solana के बगल में रखा गया है — ताकि आपकी transactions चौड़ी lane से निकल जाएँ।
हमारे Shinobi Performance Pool का एक top-tier validator
Solana के leaders priority bandwidth कैसे बाँटते हैं
stake किसी भी fee से पहले ही चौड़ी 80% lane पर सवार होकर validator तक पहुँच जाता है। stake न हो, तो आप 20% वाली spam lane में ठुँसे रहते हैं।
80 / 20 का बँटवारा Solana के leaders तय करते हैं, हम नहीं
कोर नोड स्थान
जहां Solana सबसे तेज चलता है।
हम अपने global network में ऐसे premium data centers चुनते हैं जहां Solana workloads तेज और स्थिर चलते हैं। उसी infrastructure पर RPC, streams और dedicated nodes चलते हैं, और bare metal/VPS विकल्पों से आप अपना app भी इसी network के करीब deploy कर सकते हैं।
The ERPC stack
Every layer runs right next to Solana.
- 01300+ edge locationsRPC EndpointHTTP & WebSocket, multi-region
- 02Push, no pollingGeyser gRPCAccount, tx, slot & block streams
- 03One layer before gRPCDirect ShredsData before the block is assembled
- 0480% priority bandwidthStaked ConnectionSWQoS priority lane
- 051.9× CPU vs Google CloudDirect VPS ServersEPYC compute right next to Solana
- 06Snapshot 2–4h → ~5minDirect Bare Metal ServersExclusive physical resources
- 07~2ms · −20ms TLSUnlimited EndpointsDedicated HTTP, no TLS overhead
- 08CLI agent, local & remoteSLV AINatural-language Solana ops
आप पहले से ही Solana के बगल में हैं।
RPC, Geyser gRPC, Direct Shreds — पूरा stack, chain के बगल वाले network पर racked। मुफ़्त शुरू करें और आपकी key एक मिनट में live हो जाती है।