Solana, अभी

Solana पर तेज़ कैसे बनें?

अगर आप Solana पर build करते हैं, तो इनमें से कोई एक बात आपने ज़रूर कही होगी।

  1. बगल वाले desk की strategy भी वही है जो मेरी — फिर भी fill देर से सिर्फ़ मेरा bot करता है

  2. price print होती है। मैं भेजता हूँ। transaction जाती ही नहीं

  3. हर RPC provider बदलकर देख लिया — और फ़र्क ज़रा भी नहीं

सारी professional tuning के बाद भी

code भी tune कर लिया, box भी upgrade कर लिया — अड़चन इनमें से कोई नहीं। दिक़्क़त यह है कि आप बहुत दूर से एक ऐसे leader के पीछे भाग रहे हैं जो कभी रुकता ही नहीं।

सिर्फ़ hardware और code slot नहीं जिता सकते। slot जीता जाता है timing और जगह से।

तेज़ी खरीदी जा सकती है। असली बढ़त समझ से आती है।

देखिए सबसे पहले कैसे पहुँचें

चलता हुआ निशाना

सबसे तेज़ जगह एक पल टिकती नहीं।

हर slot में — block बनाने के लिए Solana को मिले ~400 ms में — कोई और validator leader बन जाता है, और जो उसके सबसे करीब बैठा हो वही जीतता है।

किसी तय जगह के बगल में तो आप एक बार डेरा जमाकर बैठ सकते हैं — पर Solana की सबसे तेज़ सीट हर बार बदलती है, दोबारा कभी वही नहीं होती

~400 ms · हर slot पर नया leader

सबसे तेज़ सीट, slot दर slot

leader slot दर slot दुनिया भर में घूमता है। एक जीतो, और अगली पहले से कहीं और जा चुकी होती है।

इसे चलते हुए देखें

उन्नत Solana RPC, Geyser gRPC और ShredStream

Epoch —

0.00%— validators
SOL

— countries

Leader

Live block producer

Slot

दूरी ही latency है

एक महाद्वीप पार करते ही आप 100–300 ms पीछे पड़ जाते हैं।

fiber में दौड़ती रोशनी और routers की कतार एक ऐसी हद तय कर देती है जिसे कोई hardware नहीं तोड़ सकता। एक ही rack में करीब 0.1 ms। समुद्र पार करते ही 100–300 ms — जबकि एक slot सिर्फ़ करीब 400 ms चलता है।

तो जब leader आपके बिल्कुल पास हो, आप window के भीतर होते हैं — और जब वह आधी दुनिया दूर हो, तब तक आप चूक चुके होते हैं। हर slot पर तेज़ रहने का मतलब है — leader जहाँ भी उतरे, वहीं उसके पास होना।

दूरी के हिसाब से round-trip की सीमा · यह भौतिकी है, benchmark नहीं

एक packet को दूरी कितनी पड़ती है

एक ही network
0.1 ms
एक ही datacenter
0.3 ms
एक ही शहर
1 ms
पड़ोसी देश
5–10 ms
महाद्वीप पार
100–300 ms

एक महाद्वीप दूर होना एक ही rack की छलांग का सैकड़ों गुना है — और एक पूरे slot से भी ज़्यादा। नज़दीकी कोई छोटी-मोटी tuning नहीं — सारा हिसाब यहीं से तय होता है।

Coverage — एक शहर काफ़ी क्यों नहीं

सबसे भीड़ वाला शहर भी network का बस एक-चौथाई है।

Frankfurt में operators की सबसे ज़्यादा भीड़ है — फिर भी सबसे व्यस्त शहर के पास network का सिर्फ़ लगभग एक-चौथाई ही है, validators के लिहाज़ से भी और stake के लिहाज़ से भी। ज़्यादातर slots का live leader कहीं और होता है।

हर जगह coverage तो आदर्श है, पर budget किसी एक को चुनने पर मजबूर कर देता है। इसलिए सवाल सिर्फ़ यह नहीं कि सबसे बड़ा कौन है, बल्कि यह कि किसमें machines की भीड़ सबसे कम है — यानी सबसे कम मुक़ाबले वाला कौन। Amsterdam का stake Frankfurt के बराबर है, पर वहाँ validators कहीं कम ठुँसे हुए हैं — अक्सर यही ज़्यादा शांत और बेहतर सीट होती है।

Solana के validators कहाँ बैठे हैं

validatorsstake

Coverage — हर leader के बगल पहले से एक node

leader जहाँ भी उतरे, एक दमदार, Solana-direct node पहले से वहीं मौजूद।

leader की भूमिका slot दर slot दुनिया का चक्कर लगाती है — तो जीतता वही node है जो पहले से उसके सबसे करीब हो। एक ही region में बैठा node उस लंबे सफ़र वाली छलांग से बच जाता है जो देरी बढ़ाती है।

इसलिए हम किसी एक जगह पर टिके नहीं रहते। हर slot पर लगातार तेज़ रहने का मतलब है हर बार leader के पास होना — और चूँकि leader region दर region घूमता रहता है, इसके लिए कई regions में coverage चाहिए। जहाँ Solana का stake सिमटता है वहाँ हम validator-grade nodes चलाते हैं, एक ही low-latency fabric पर, और regions लगातार जोड़ते जाते हैं — हर नया region यानी और ज़्यादा slots, जहाँ आप पहले से leader के बगल होते हैं।

साल्ट लेक सिटीChicagoNew YorkडबलिनLondonAmsterdamFrankfurtस्टॉकहोमSingaporeTokyoसिडनी

Global Data Center Partner

गति Solana से दूरी पर निर्भर करती है।

क्षेत्र मायने रखता है। लेकिन अकेले शहर का नाम एक नेटवर्क पाथ नहीं है। एक ही शहर में भी, एक्सटर्नल ट्रांज़िट और अतिरिक्त hops लेटेंसी जोड़ सकते हैं। ERPC ऐसे डेटा सेंटर चुनता है जो Solana सर्वरों के करीब हों, फिर एक्सटर्नल ट्रांज़िट से बचकर और निरंतर टर्बो बूस्ट के साथ रूट छोटे रखता है।

ERPC प्रीमियम मार्ग

कोई एक्सटर्नल ट्रांज़िट नहीं

न्यूनतम RTT

0.1ms

शहर का नाम चयन

एक्सटर्नल ट्रांज़िट / 7 hops

70x धीमी

7ms
  • 01समान डेटा सेंटरपहले क्षेत्र चुनें, फिर Solana के सबसे करीब का डेटा सेंटर।
  • 02कोई बाहरी पारगमन नहींRTT और jitter को टाइट रखने के लिए एक्सटर्नल AS paths से बचें।
  • 03पूर्ण थ्रॉटलERPC पावर-सेविंग प्रोफ़ाइल को बंद रखता है और संसाधनों को लगातार टर्बो बूस्ट पर बनाए रखता है।

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 के साथ · 80% · साफ़ ✓
txleader
block
stake नहीं · 20% · जाम ✕

stake किसी भी fee से पहले ही चौड़ी 80% lane पर सवार होकर validator तक पहुँच जाता है। stake न हो, तो आप 20% वाली spam lane में ठुँसे रहते हैं।

80 / 20 का बँटवारा Solana के leaders तय करते हैं, हम नहीं

मापा हुआ 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 · जितना ज़्यादा, उतना बेहतर
1.9×
ERPC
7,850
Cloud
4,062

events/s

Memory bandwidthSTREAM Triad · 4 GiB · जितना ज़्यादा, उतना बेहतर
3.2×
ERPC
151,986
Cloud
47,943

MB/s

Disk IOPSfio · 4K randread · QD32 · जितना ज़्यादा, उतना बेहतर
16.6×
ERPC
50,675
Cloud
3,061

IOPS

Disk latency · p99fio · 4K randread · QD32 · जितना कम, उतना बेहतर
25.7×
ERPC
668
Cloud
17,170

µs

पूरा environment, सबसे ऊँचे दर्जे पर।

आपके और slot के बीच की हर परत को ERPC tune करता है — RPC, streaming, validators, नीचे का bare metal — और इन सबको Solana के ठीक पास ले आता है। यह सब एक साथ लाना पहले आपका काम था। अब बस हमारे products को मिलाकर इस्तेमाल कीजिए — Solana तक की सबसे तेज़ line।