जो भी चाहिए, सब कुछ।ब्लॉकचेन से सीधा संपर्क।
Ethereum और Solana के लिए RPC, और सबसे तेज़ Solana डेटा स्ट्रीम — Geyser gRPC, Direct Shreds — उस नेटवर्क पर चलते हैं जो हर चेन के ठीक बगल में है। आप सीधे चेन से बात करते हैं।
भरोसेमंद इंफ्रास्ट्रक्चर
गति 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 सबसे तेज चलता है।
ग्लोबल नेटवर्क भर में हम सिर्फ़ प्रीमियम डेटा सेंटर चुनते हैं जहाँ Solana सबसे अच्छा चलता है, फिर टॉप-टियर हार्डवेयर पर फ़ुल थ्रॉटल RPC, स्ट्रीम और डेडिकेटेड नोड चलाते हैं। Bare Metal सर्वर और VPS विकल्प भी देते हैं, ताकि आप अपना ऐप उसी नेटवर्क पर डिप्लॉय करके सबसे तेज़ पथ पर बने रह सकें।
The ERPC stack
Every layer runs right next to the chain you build on.
- 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
आप पहले से ही चेन के बगल में हैं।
RPC, Geyser gRPC, Direct Shreds — पूरा स्टैक, चेन के बगल वाले नेटवर्क पर रैक किया हुआ।