ERPC

Solana RPC Endpoint SSS | ERPC

S. Shreds / getBlock çıktım aniden bozuk görünüyor ya da -32015 döndürüyor — ne değişti?

Solana Transaction v1 (SIMD-0385), 15 Eylül 2026'da, epoch 1035'te Solana mainnet üzerinde devreye girdi. Bir v1 işleminin wire düzeni sürüm öneki baytı 0x81 ile başlar, imzalar mesajdan sonra gelir ve legacy uzunluk öneki bulunmaz.
ShredStream, Direct Shreds veya UDP Forwarding entry'lerini kendiniz çözümlüyorsanız, 4.2 sürümünün altındaki bir bincode ya da solana-entry çözümleyicisi bu 0x81 baytını imza sayısı olarak yanlış okur; bu da EOF hatası, compact-length taşması veya "invalid message version" hatası olarak ortaya çıkar. Ham işlemleri 4.2 öncesi crate'lerle deserialize eden Geyser gRPC kullanıcıları da aynı sorunla karşılaşır. maxSupportedTransactionVersion: 0 ile yapılan getBlock ve getTransaction RPC çağrıları -32015 Transaction version (1) is not supported by the requesting client döndürür; getTransactionsForAddress ise full modunda aynı hatayı etkilenen her satır için bildirir. ERPC'nin parse edilmiş JSON yanıtlarını zaten sürüm 1 ayarıyla okuyorsanız etkilenmezsiniz.
maxSupportedTransactionVersion değerini options nesnesinde 1 olarak ayarlayın — getBlock ve getTransaction'ın ikinci parametresinde ve ayrıca getTransactionsForAddress'in options'ında da:
json
{
  "maxSupportedTransactionVersion": 1
}
Solana Stream SDK'yı 2.0.0 sürümüne yükseltin: crates.io üzerindeki Rust solana-stream-sdk ya da npm üzerindeki @validators-dao/solana-stream-sdk ve @validators-dao/solana-shreds-client. @validators-dao/solana-entry-decoder paketini ayrıca 2.5.0 sürümüne yükseltin. 1.4.0 ve entry-decoder 2.4.0 v1'i desteklemez. Kendi Rust çözümleyicileriniz solana-entry 4.2.x sürümüne geçmelidir.

S. Solana RPC endpoint nedir ve ERPC ile nasıl alınır?

Solana RPC endpoint; uygulamanızın, trading botunuzun, cüzdanınızın veya analitik sisteminizin Solana'ya JSON-RPC istekleri göndermek ve zincir verisi almak için kullandığı URL'dir. ERPC ile aynı global proxy network üzerinden HTTP ve WebSocket erişimi destekleyen yönetilen bir Solana endpoint elde edersiniz.
Başlamak için ERPC Web Dashboard üzerinden hesabınızı oluşturun veya açın, API key'inizi kopyalayın ve endpoint URL'sindeki api-key parametresine ekleyin:
text
https://edge.erpc.global?api-key=<YOUR_API_KEY>
WebSocket abonelikleri için de aynı API key formatını kullanın:
text
wss://edge.erpc.global?api-key=<YOUR_API_KEY>

S. Her yöntem kaç token tüketir?

Şu anda ayrıntılı bir token kullanım tablosu hazırlıyoruz.
Referans olarak temel oran yöntem başına 42 token'dır.
"full" modundaki getTransactionsForAddress dışında, History Access'in yanıtladığı bir çağrı yöntemin normal fiyatından 640 token fazla tutar (getBlock için 42 + 640 = 682 token); yakın veriden yanıtlanan bir çağrı ise history=true olsa bile normal fiyatını korur.
ERPC Web Dashboard
🔗 ERPC Web Dashboard

S. Daha eski Solana blokları veya işlemleri neden eksik, ya da neden -32011 görüyorum?

getTransactionsForAddress dışında, history=true içermeyen bir istek her node'un tuttuğu yakın aralıktan yanıtlanır; bu nedenle daha eski bloklar veya işlemler, yönteme bağlı olarak This request needs history access. Add history=true to the endpoint URL. hatasını (kod -32011), null ya da boş bir sonuç döndürebilir. Bunları istemek için bir HTTP isteğinin https://edge.erpc.global URL'sine history=true ekleyin.
API key'i URL içinde gönderin:
text
https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=true
Ya da API key'i Authorization: Bearer <YOUR_API_KEY> header'ında gönderin ve history=true seçeneğini URL'de tutun:
text
https://edge.erpc.global?history=true
Daha eski blokların veya işlemlerin sorgulanması normal bir istekten çok daha uzun sürebilir; bazı durumlarda saniyeler alır. History Access, bu sorguları normal isteklerden ayıran ayrı bir seçenektir; böylece normal istekler hızlı kalır. "full" modundaki getTransactionsForAddress dışında, History Access'in yanıtladığı her çağrı, yöntemin normal fiyatından 640 token fazla tutar.
Free planı da dahil ücretsiz tahsisler, History Access için bir limite sahiptir. Free plan, 10 saniyede bir History Access isteğiyle sınırlıdır.
history=true olmadan, transactionDetails değeri "full" olan getTransactionsForAddress, verinin yaşı ne olursa olsun aynı -32011 hatasını döndürür; fiyatı ERPC dokümantasyonunda yer alır.
ERPC dokümantasyonu: RPC

Q. Unlimited Endpoint hangi yöntemleri destekler?

Unlimited Endpoints düşük gecikmeli standart Solana RPC çağrıları için tasarlanmıştır. Desteklenen yöntemler getSlot, getBlockHeight, getLatestBlockhash, getBalance, getAccountInfo, getMultipleAccounts, getTransaction, sendTransaction, simulateTransaction, getSignatureStatuses, getRecentPrioritizationFees, getHealth, getVersion, getEpochInfo, getBlock. Diğer yöntemler için https://edge.erpc.global?api-key=<YOUR_API_KEY> kullanın.

S. Node'larınız hangi bölgelerde bulunuyor?

Şu anda aşağıdaki bölgelerde node işletiyoruz:
  • Frankfurt (FRA)
  • Amsterdam (AMS)
  • London (LON)
  • New York (NY)
  • Chicago (CHI)
  • Tokyo (TY)
  • Singapore (SGP)
ERPC'nin RPC endpoint altyapısı Cloudflare tarafından desteklenir ve 300'den fazla edge sunucudan oluşan global bir network kullanır. İstekler otomatik olarak en yakın Cloudflare edge lokasyonundan geçirilir ve ardından en uygun ERPC node'una yönlendirilir. Böylece dünyanın herhangi bir yerinden mümkün olan en kısa ağ yolu ve tutarlı düşük gecikme sağlanır.
Bu mimari, coğrafi mesafenin ve karmaşık routing etkisinin azaltılmasına yardımcı olur; Solana node'larına maksimum stabilite ve performansla, sürekli optimize edilmiş bağlantı sunar.
ERPC Web Dashboard: ERPC Web Dashboard

S. WebSocket kullanabilir miyim?

Evet, WebSocket desteklenir. Aynı endpoint üzerinden çalışır ve gerçek zamanlı veri güncellemelerini verimli şekilde almanıza olanak tanır.

S. Neden 401 hatası alıyorum?

401 hatası bir kimlik doğrulama sorununa işaret eder. Lütfen şunları kontrol edin:
  • Aboneliğinizin başlayıp başlamadığı
  • Kalan krediniz olup olmadığı
Krediniz bittiyse planınızı yükseltmeyi değerlendirin.

S. Neden 429 hatası alıyorum?

429 hatası rate limit'e ulaştığınız anlamına gelir. Bu hata sık sık oluşuyor ve hizmetinizi etkiliyorsa planınızı yükseltmeyi değerlendirin.

S. Dedicated endpoints neden daha hızlı?

Shared endpoints, aynı kaynakları paylaşan birden fazla müşteri tarafından kullanılır. Trafik arttıkça latency oluşma eğilimi de artar. Sunucu kaynaklarının fiziksel sınırları vardır ve aynı anda çok fazla istek geldiğinde işlemler sıraya alınır; bu da yanıt sürelerini yavaşlatır.
Shared endpoints üzerinde performansı optimize etmek için çeşitli önlemler alsak da dedicated endpoints ile kaynağın tek kullanıcısı siz olursunuz. Bu, diğer kullanıcıların trafiğinden etkilenmeden daha stabil ve hızlı yanıtlar almanız anlamına gelir.
Ayrıca dedicated endpoints, HTTP gibi TLS kullanmayan iletişim seçenekleri sunabilir. TLS handshake atlandığında (yaklaşık 20ms), HTTPS'e kıyasla iletişim daha hızlı olabilir.

S. Abone olduktan sonra satış fiyatı artırılır mı?

Aboneliğiniz aktif kaldığı sürece kayıt sırasında kilitlediğiniz satış fiyatı geçerli olur. Solana'nın gerçek zamanlı iş yükünü taşıyabilen ortamlar global ölçekte sınırlıdır ve artan donanım ile network talebine paralel olarak liste fiyatlarını kademeli artırmayı planlıyoruz. Daha yüksek özellikli konfigürasyonlar ve yüksek talep gören bölgeler en hızlı tükenir; bu nedenle mevcut promosyon fiyatını kilitlemek uzun vadede en maliyet verimli seçenektir.

S. Kripto ile ödeme yapmak istiyorum

Kripto ödemeleri, kayıtlı fatura adresinizin ülkesi AB üyesi ülkelerden biri olduğunda ERPC Web Dashboard üzerinden kullanılabilir. SOL, USDC veya EURC ile ERPC Credits satın alabilirsiniz.
Bu ERPC Credits ile ERPC planlarını başlatabilir veya kullanmaya devam edebilirsiniz. Dashboard'u açın, crypto payment seçin, ödemeyi wallet'ınızdan gönderin; dashboard işlemi doğrular ve credits tutarını hesabınıza ekler.
Desteklenen ülkeler: Almanya, Avusturya, Belçika, Bulgaristan, Çekya, Danimarka, Estonya, Finlandiya, Fransa, Hırvatistan, Hollanda, İrlanda, İspanya, İsveç, İtalya, Kıbrıs, Letonya, Litvanya, Lüksemburg, Macaristan, Malta, Polonya, Portekiz, Romanya, Slovakya, Slovenya, Yunanistan.
Listede olmayan ülkeler için lütfen kredi kartıyla ödeme yapın.
ERPC Web Dashboard

S. Hangi bölgeyi öneriyorsunuz?

Kalıcı tek bir en iyi bölge yoktur. Solana globaldir ve leader rolü validator'lar arasında slot slot dolaşır. Daha fazla validator ve daha yüksek stake bulunan bölgelerde leader slot'ları daha sık görülür; bu, işlemlerin daha hızlı sonuçlanmasına yardımcı olabilir. Ancak rekabet eden trafik de bu bölgelerde yoğunlaşır, bu yüzden stratejinize bağlı olarak daha az kalabalık bir bölge bazen daha iyi sonuç verebilir.
Pratik bir başlangıç noktası olarak, sürekli leader-slot arzı önemliyse Frankfurt veya ABD Doğu Yakası gibi validator yoğun bölgeleri seçin. En kısa yol ile belirli bir hedef validator'a yakın olmak öncelikliyse altyapınızı buna göre konumlandırın. Public Solana network dağılımını anlamak için Validators Solutions kullanın; ardından tek bölge, çift bölge veya global dağıtımın uygun olup olmadığına karar vermek için ERPC Leader Slot API ve gerçek ölçümlerden yararlanın.
Solana Mainnet Dağıtım Raporu

S. En az yaklaşık 400ms veya daha iyi latency'e ihtiyacım var.

Yaklaşık 400ms içinde latency elde etmek için şu temel noktaları dikkate alın:
  • Ping değerlerini gerçekçi yorumlama: Ping değerleri ideal koşulları gösterir ve streaming iletişimindeki gerçek latency'i doğrudan yansıtmaz. Streaming iletişimde latency genellikle ping değerinin yaklaşık 5 katına çıkabilir. Örneğin kıtalar arası 100ms ping, pratikte yaklaşık 500ms latency anlamına gelebilir. Bu nedenle ~400ms latency için altyapının aynı bölgede kurulması gerekir.
    • Tipik ping değeri referansı:
      • Aynı network: ~0.1ms
      • Private Network Interconnect (PNI): ~0.2ms
      • Aynı veri merkezi: ~0.3ms
      • Aynı şehir: ~1ms
      • Komşu ülke: ~5-10ms
      • Kıtalar arası: ~100-300ms
  • Ortalama latency yanılgısından kaçınma: Solana validators global olarak dağılmıştır ve leader schedule her epoch'ta rastgele değişir. ~400ms hedefi için ortalama latency'e güvenmek pratik değildir. Bunun yerine, belirli bölgenizdeki validator schedule'larını hassas şekilde takip ederek en düşük latency sunan slot'ları belirlemelisiniz. Tutarlı şekilde minimum latency elde etmek için ilgili tüm bölgelerde altyapı gerekebilir. Aynı bölge içinde veri edinimi onlarca milisaniyede, iletim ise birkaç milisaniyede gerçekleşebilir.
  • Leader schedule'ı takip etme: Bölgeniz için leader validator schedule'ını ERPC Leader Slot API (getLeaderSlots) ile sürekli izleyin. Bu API yaklaşan leader'lar, stake weight, validator geolocation bilgileri ve referans ping değerleri hakkında gerçek zamanlı veri sağlar; böylece minimum latency ile en uygun trading slot'larını doğru şekilde belirleyebilirsiniz. Public harita tarzı veriler ve native RPC API'ler geniş network görünürlüğü için faydalıdır, ancak işlem zamanlaması için yeterince hassas değildir. Leader Slot API, routing ve trading kararları için gereken ayrıntı düzeyiyle bu boşluğu doldurur.
Validators Solutions - Solana network verisi
Solana network verisi: Validators Solutions

S. Zero-block (zero-slot) trading'i nasıl başarabilirim?

Zero-block (zero-slot) trading'i başarıyla uygulamak daha gelişmiş stratejiler gerektirir:
  • Fırsat bölgelerini belirleme: Solana validators global olarak dağılmıştır ve her slot için optimal latency elde etmek fiziksel olarak imkansızdır. Bu nedenle altyapınızın bulunduğu bölgedeki validator leader schedule'larını izleyin ve en avantajlı fırsat bölgelerini belirleyin. Altyapıyı birden fazla bölgede dağıtmak da avantaj sağlayabilir. Örneğin Frankfurt, yüksek validator yoğunluğu nedeniyle kritik bir bölgedir; bu da daha sık leader seçimi ve daha fazla trading fırsatı anlamına gelebilir.
    ERPC Leader Slot API (getLeaderSlots) ile gerçek zamanlı leader schedule, stake weight, validator geolocation verisi ve referans ping değerlerini; public harita tarzı veri kaynaklarına veya native RPC API'lere göre çok daha yüksek hassasiyetle alabilirsiniz. Bu sayede fırsat bölgelerini daha doğru tahmin edebilir ve near-zero-latency trade'ler yürütebilirsiniz.
  • Dedicated nodes kullanma: Rekabet etmekte zorlanıyorsanız dedicated nodes dağıtmayı değerlendirin. Shared nodes, diğer kullanıcıların trafiği nedeniyle latency yaşayabilir ve bu nedenle kritik kullanım senaryoları için önerilmez. Ayrıca dedicated node'unuzu uygulamanızla aynı network içinde konumlandırmak network latency'sini önemli ölçüde azaltır ve performansı optimize eder.

S. Mümkün olan en düşük latency'i nasıl elde edebilirim?

Minimum latency için ideal kurulum, dedicated bir RPC node ile aynı network içinde çalışan Bare-Metal sunucularımızı birlikte kullanmaktır. Her ikisi de aynı network'ü paylaşır ve yaklaşık 0.1ms ping latency ile özel, sıfır mesafeye yakın iletişim sağlar.
Daha fazla detay için lütfen ERPC Web Dashboard üzerinden bizimle iletişime geçin.
ERPC Web Dashboard

S. Dedicated node üzerindeki işlemlerimin başarı oranı düşük

İşlem başarı oranı ve hız, QoS (Quality of Service) adlı mekanizmadan önemli ölçüde etkilenir. Dedicated nodes için özel QoS sunuyoruz. Daha fazla ayrıntı için lütfen aşağıdaki sayfalara bakın veya ERPC Web Dashboard üzerinden bizimle iletişime geçin.

S. Latency seviyesi nasıl?

Latency, ölçüm yöntemine ve kullanım ortamınıza bağlı olarak değişir. Kesin sayılara odaklanmak yerine, latency'nin gerçek operasyonel gereksinimlerinizi karşılayıp karşılamadığına bakmak daha önemlidir.
Latency ölçümü için TypeScript ve Rust ile kullanımı kolay araçlar sağlıyoruz.

S. Bu RPC (gRPC, ShredStream) diğerlerinden daha hızlı mı?

Her fiyat kademesini hız için tasarlıyoruz ve bunun başka herhangi bir sağlayıcıyla yan yana ölçülmesinden memnuniyet duyuyoruz. Sonuçlar bölgeye, paylaşılan mı yoksa adanmış bir uç nokta mı kullandığınıza, kullandığınız protokole (WebSockets, gRPC veya Shreds) ve istemcinizin programlama diline göre değişir.
Hizmetimizi daha yavaş bulursanız, karşılaştırma yaptığınız koşulları ve rakipleri ERPC Web Dashboard üzerinden bizimle paylaşın. Nedeni belirleyip hızı daha da iyileştirmek için çalışırız.
ERPC Web Dashboard

S. Hangi plan en hızlı performansı sunar?

Genel olarak en üst seviye planımız, daha güçlü CPU'lar, daha yüksek bellek kapasitesi ve sağlam donanım konfigürasyonları nedeniyle en hızlı performansı sağlar.
Daha güçlü sunuculara ihtiyacınız varsa özel çözümler de sunuyoruz; ancak standart planlarımız optimum fiyat/performans oranı sağlamak için tasarlanmıştır.
Her fiyat seviyesinde dünya standartlarında performans sunma konusunda iddialıyız. Aynı fiyat aralığında daha hızlı bir sağlayıcı bulursanız lütfen bize bildirin; araştırıp gerekli iyileştirmeleri yapalım.

S. Yüksek latency yaşıyorum. Neden?

Latency, endpoint'e olan mesafeyle artar. Sağlanan endpoint'e yakın sunuculardan erişmenizi öneririz. En hızlı ortamlar Bare-Metal sunucularımız ve VPS hizmetlerimiz üzerinden sağlanabilir.

S. En hızlı seçenek hangisi: WebSocket, gRPC veya ShredStream?

Müşteri geri bildirimleri tutarlı şekilde şu performans sırasını gösterir:
ShredStream > gRPC > WebSocket
Farklı sonuçlar deneyimlerseniz lütfen bize bildirin.

S. Latency beklediğim gibi değil.

Performans, seçtiğiniz programlama diline göre değişebilir. Genel olarak diller şu sırayla performans gösterir:
Rust > Go > TypeScript (JavaScript) > Python
Daha ayrıntılı karşılaştırmalar için şu kaynağa bakabilirsiniz:
Programlama Dili Hız Karşılaştırması
Maksimum performans hedefliyorsanız Rust kullanmanızı güçlü şekilde öneririz.

Önceki

SSS - Latency

Sonraki

SSS - Direct Shreds