ERPC ने Solana shared Shreds और Geyser gRPC endpoints में HTTPS जोड़ा — अपने use case के हिसाब से HTTPS या HTTP चुनें
ELSOUL LABO B.V. (मुख्यालय: Amsterdam, Netherlands; प्रतिनिधि निदेशक और CEO: Fumitake Kawasaki) और Validators DAO, जो ERPC का संचालन करते हैं, ने shared endpoints के Shreds gRPC और Geyser gRPC में नए तौर पर HTTPS सपोर्ट जोड़ा है। जो HTTP हम शुरू से देते आए हैं, उसके साथ मिलकर अब आप HTTPS और HTTP दोनों में से चुन सकते हैं।
यह Shreds gRPC की ओर Direct Shreds Connect और Direct Shreds Turbo पर, और साझा Geyser gRPC स्ट्रीम के मानक, प्रीमियम तथा बर्स्ट tiers पर लागू होता है।
आप encrypted और secure HTTPS endpoint चुन सकते हैं, या फिर वह HTTP endpoint जिसमें TLS की कोई processing होती ही नहीं। gRPC की शब्दावली में पहला gRPC over TLS है और दूसरा TLS का उपयोग न करने वाला plaintext HTTP/2। इससे use cases का दायरा कहीं ज़्यादा चौड़ा हो जाता है — उन workloads से लेकर जहाँ सिर्फ़ latency मायने रखती है, उन workloads तक जहाँ आप क्या subscribe कर रहे हैं इसकी गोपनीयता सबसे ज़्यादा मायने रखती है।
Endpoint का hostname नहीं बदलता। सिर्फ़ scheme और port अलग होते हैं: HTTPS पोर्ट 443 का उपयोग करता है, HTTP पोर्ट 80 का। इनके बीच switching आप ERPC Web Dashboard में करते हैं।
नया जोड़ HTTPS है — मौजूदा HTTP पहले की तरह जारी
ERPC के shared stream endpoints अब तक HTTP पर दिए जाते रहे हैं।
जो जोड़ा गया है वह HTTPS की तरफ़ है। मौजूदा HTTP connections के specification और behavior में कोई बदलाव नहीं है, और आप उन्हें बिलकुल पहले की तरह इस्तेमाल करते रह सकते हैं। जो customers पहले से HTTP पर connect कर रहे हैं, उन्हें कुछ भी करने की जरूरत नहीं है।
HTTP को बंद करने की हमारी कोई योजना नहीं है। जिन workloads में latency सबसे पहले आती है, उनके लिए विकल्प के रूप में यह आगे भी उपलब्ध रहेगा।
HTTPS — encrypted और secure connection
HTTPS endpoint पर, आपके client और ERPC के बीच का पूरा exchange TLS से encrypt होता है।
आपके subscription request का content और आपको लौटाया जाने वाला stream data, दोनों TLS से encrypt होते हैं, इसलिए सामान्यतः path पर payload का content पढ़ा नहीं जा सकता। ERPC Web Dashboard में HTTPS ही default रूप से चुना हुआ transport है।
TLS handshake मुख्यतः connection बनते समय होता है। उसके बाद भी stream data का encryption और decryption चलता रहता है, लेकिन लंबे समय तक खुले रहने वाले सामान्य gRPC stream में handshake की लागत बार-बार नहीं चुकानी पड़ती।
HTTP — TLS processing के बिना कम latency वाला विकल्प
HTTP endpoint पर, न TLS handshake होता है और न encryption या decryption का कोई काम।
Solana की real-time processing में, data जहाँ बनता है वहाँ से लेकर आपके application तक पहुँचने के रास्ते में हर एक काम latency को प्रभावित करता है। TLS encryption या decryption की ज़रूरत न होने के कारण, HTTP उन कम latency वाले कामों के लिए उपयुक्त है जिनमें path पर processing को जितना हो सके घटाना होता है।
जिन setups में connections बार-बार दोबारा बनाए जाते हैं, या जो path पर किसी भी तरह की overhead बर्दाश्त नहीं कर सकते, वहाँ HTTP को बढ़त मिलती है।
जब subscription filter का "समूह" खुद मायने रखने लगे
HTTP कम latency वाला विकल्प है, लेकिन project उसे किस तरह इस्तेमाल करता है इसके आधार पर, माँगे जा रहे addresses का समूह path पर उजागर हो जाता है — और कुछ projects के लिए यही समस्या बन जाती है।
Blockchain पर मौजूद data अपने आप में public है। फिर भी, जब समूह उजागर होता है, तो उसका ऐसा अर्थ बन सकता है जो अकेली किसी entry का नहीं था।
मान लीजिए कोई project अपने सभी customer wallets को filter करके monitor करना चाहता है। तब उस subscription request में शामिल addresses की सूची अपने आप में उस project के लिए संवेदनशील जानकारी हो सकती है। भले ही हर एक address अलग से public जानकारी हो, "किस address समूह को एक इकाई के रूप में monitor किया जा रहा है" यह पता चलने पर उस project के customer आधार, उसकी निगरानी के विषयों और उसके व्यावसायिक हितों का अनुमान लगाने का सुराग मिल सकता है।
ठीक ऐसी ही स्थिति में HTTPS endpoint काम आता है। TLS के लिए ज़रूरी encryption और decryption के काम के बदले, आपके subscription request और stream data दोनों का payload encrypt हो जाता है।
पहले latency, या पहले subscription की गोपनीयता? यह फ़ैसला हर project में अलग होता है। ERPC ने अब यह चुनाव आप पर छोड़ दिया है, ताकि आप उसे अपने use case के अनुसार कर सकें।
दायरा: shared endpoints
HTTPS सपोर्ट निम्नलिखित shared endpoints को कवर करता है:
- Direct Shreds Connect
- Direct Shreds Turbo
- साझा Geyser gRPC स्ट्रीम — मानक
- साझा Geyser gRPC स्ट्रीम — प्रीमियम
- साझा Geyser gRPC स्ट्रीम — बर्स्ट
हर region के shared stream endpoints पर HTTPS enable किया जा चुका है, और मौजूदा HTTP endpoints पहले की तरह बनाए रखे गए हैं। Shreds Bundle और ERPC Bundle में शामिल shared endpoints पर भी HTTPS इस्तेमाल किया जा सकता है।
Dedicated endpoints इस बदलाव का हिस्सा नहीं हैं। Dedicated Geyser gRPC और dedicated Shreds products अपने मौजूदा connection method पर, बिना किसी बदलाव के, बने रहते हैं।
Dashboard में switch करें — IP allowlist दोनों के लिए एक ही
Transport का switching आप ERPC Web Dashboard के endpoint display से करते हैं।
HTTPS और HTTP के बीच स्विच करें; चुने गए transport के लिए endpoint URL दिखा दिया जाएगा। जैसा दिखाया गया है ठीक वैसा ही URL अपने client में सेट करें।
दोनों transports एक ही registered-IP allowlist का उपयोग करते हैं। Authentication अब भी आपके registered IP address पर आधारित है, इसलिए HTTPS पर जाने के लिए IPs दोबारा register करने की जरूरत नहीं है, और न ही कोई token या Authorization header जोड़ना है।
Jito ShredStream समाप्त होने के बाद भी ERPC के shared Shreds products जारी
Jito का Jito ShredStream 5 सितंबर 2026 को सेवा समाप्त कर रहा है। वहीं ERPC के shared Shreds products उस तारीख के बाद भी जारी रहेंगे।
इस HTTPS rollout में शामिल Direct Shreds Connect और Direct Shreds Turbo, साथ ही Shreds Bundle के multi-IP plans और ERPC Bundle में शामिल Direct Shreds Connect — ये सभी 5 सितंबर के बाद भी उपलब्ध रहेंगे।
स्पष्ट कर दें: 21 अगस्त 2026 को घोषित 5 सितंबर की सेवा समाप्ति dedicated Shredstream products और Stream Bundle पर लागू होती है। Shared Shreds products उसमें शामिल नहीं हैं। Dedicated plans वाले customers के लिए migration guidance पहले की तरह व्यक्तिगत रूप से दी जाती रहेगी।
अगर आप यह समीक्षा कर रहे हैं कि आपका project Shreds कैसे प्राप्त करता है, तो विकल्पों पर नज़र डालने के लिए यह स्वाभाविक मौका है। हमें खुशी होगी अगर आप उन्हें आज़माकर देखें।
एक घंटे से hourly billing पर परखें
ERPC के shared endpoints एक घंटे से, hourly billing पर उपलब्ध हैं।
किसी monthly plan के लिए प्रतिबद्ध हुए बिना, आप अपने असली workload पर HTTPS और HTTP दोनों को आज़मा सकते हैं और खुद देख सकते हैं कि आपके अपने environment में latency और गोपनीयता का संतुलन कैसा बैठता है।
छोटे से evaluation से शुरू करें, और जो आप मापें उसी के आधार पर अपना plan चुनें।
UDP Forwarding का renewed product जल्द आ रहा है
Shreds के delivery path को ही सरल बनाने वाले UDP Forwarding के लिए, renewed product जल्द आ रहा है।
लक्ष्य ऐसा lineup है जिसमें आप काम के हिसाब से delivery method चुन सकें: जिन workloads में सबसे कम latency सबसे ऊपर है उनके लिए UDP, और मौजूदा gRPC interface पर stream subscription के लिए Shreds gRPC।
Supported regions, pricing, detailed specifications, और official release date तैयार होते ही घोषित की जाएंगी।
अपने काम के हिसाब से चुनी जाने वाली infrastructure
ERPC, Solana infrastructure के performance का मूल्यांकन सिर्फ़ server specifications से नहीं करता। Data source से निकटता, network path, hardware, OS और kernel, और उपयोगकर्ता तक अंतिम delivery method — इन सबको मिलाकर एक ही low-latency system के रूप में design किया जाता है।
यह HTTPS rollout उसी अंतिम delivery method के भीतर विकल्पों को चौड़ा करता है। ऐसा कोई एक सबसे तेज़ विकल्प नहीं है जो हर project के लिए सही हो; latency और गोपनीयता में से किसे कितना वज़न देना है, यह product की प्रकृति पर निर्भर करता है।
कोई सवाल हो तो कृपया ERPC Web Dashboard की support chat के माध्यम से हमसे संपर्क करें।
