SSS - Direct Shreds

Q. 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
}

{
  "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.

Q. Düğümleriniz hangi bölgelerde bulunuyor?

Şu anda aşağıdaki bölgelerde düğümler işletiyoruz:

Frankfurt (FRA)
Amsterdam (AMS)
London (LON)
Dublin (DUB)
New York (NY)
Chicago (CHI)
Salt Lake City (SLC)
Tokyo (TY)
Singapore (SGP)
Sydney (SYD)

ERPC, düz çizgi mesafesine güvenmek yerine gerçek yönlendirme yollarına dayalı olarak fiili ağ gecikmesini ölçer ve en düşük gecikmeye sahip bölgeyi otomatik olarak seçer. Bu yaklaşım yalnızca bireysel kullanıcılar için gecikmeyi iyileştirmekle kalmaz, aynı zamanda genel ağ verimliliğini artırır ve ERPC'nin olası saldırılara karşı küresel dayanıklılığını güçlendirir.

Ortamınız en uygun bölgeyi otomatik olarak seçmiyorsa, lütfen ERPC Web Dashboard üzerinden bizimle iletişime geçin.

ERPC Web Dashboard: https://dashboard.erpc.global/tr

Q. Gecikme 9999ms gösteriyor ve en uygun olmayan bir bölge seçiliyor. Ne yapmalıyım?

Shreds bölge seçimi için ERPC, aşağıda listelenen proxy sunucularından kayıtlı IP adresinize ICMP gecikme yoklamaları gönderir. Listelenen tüm kaynak IP adreslerinden gelen ICMP echo isteklerine izin verin. Bunlar bir güvenlik duvarı (ufw, bulut güvenlik duvarı, güvenlik grubu vb.) tarafından engellenirse ölçüm 9999ms olabilir ve optimal olmayan bir bölge seçilebilir. Aynı bölgedeki birden fazla IP, ayrı yoklama sunucularıdır; tümü gereklidir.

Bölge	ICMP kaynak IP’leri
🇳🇱 Amsterdam	`64.130.43.108`, `82.21.43.35`
🇺🇸 New York	`151.243.244.162`
🇩🇪 Frankfurt	`64.130.41.236`, `151.241.178.73`
🇯🇵 Tokyo	`143.20.238.88`
🇸🇬 Singapore	`67.209.55.19`, `151.245.186.3`
🇬🇧 London	`64.130.63.211`, `151.241.65.10`

Far Point seçildi

Shared Shreds Far Point, sınırlı kapasiteli bir yedek seçenektir. Her endpoint, tüm müşteriler genelinde aynı anda en fazla 32 proxy stream destekler; bu, müşteri başına 32 yer anlamına gelmez. Subscriber seçilen Shreds endpoint'inin yakınında çalıştığında streaming en verimli şekilde gerçekleşir; uzun mesafeli stream'ler paylaşılan bağlantıları, akış kontrol pencerelerini ve egress kapasitesini daha uzun süre kullanır. Paylaşılan ortamın yanıt verebilirliğini korumaya yardımcı olmak için listelenen tüm bölgesel ICMP probe kaynak IP adreslerine izin verin ve bölge seçimini yeniden çalıştırın. Sürekli kullanım için seçilen endpoint'in yakınında bir ERPC VPS değerlendirin. Farklı bir coğrafya gerekiyorsa ilk yapılandırma sırasında kullanılabilir bir bölge seçin ve hedef olarak geçerli, boş olmayan bir genel IPv4 adresi ile bağlantı noktasını yapılandırın. Seçilen bölge kurulumdan sonra sabit kalır ve hedef daha sonra güncellenebilir.

Bu endpoint'in yakınında ERPC VPS kullanın · UDP Forwarding Standard'ı yapılandırın https://erpc.global/en/doc/shredstream/quickstart/

Q. IP adresimi allowlist'e ekledim, ama hâlâ bağlanamıyorum. Neyi kontrol etmeliyim?

ERPC gRPC ve Shreds endpointleri, IP allowlist ile korunan düz HTTP port 80 kullanır. Port 443 üzerinde HTTPS/TLS kullanmazlar.

Başka bir sağlayıcıdan client örneği kopyalarsanız, örnek varsayılan olarak :443 veya HTTPS kullanabilir. Sadece domain'i değiştirirseniz port ve TLS ayarları aynı kalabilir, bu da bağlantının çalışmasını engeller.

Aşağıdaki endpoint'ler örnektir. Bunları dashboard'da gösterilen kendi endpoint'inizle değiştirin. HTTP formunda kullanın veya client host ve port istiyorsa port 80'i açıkça belirtin:

Geçerli değil: shreds-fra6-1.erpc.global:443
Geçerli: shreds-fra6-1.erpc.global:80
Geçerli URL formu: http://shreds-fra6-1.erpc.global

Kimlik doğrulama kayıtlı IP adresinize dayanır. Belirli bir ürün sayfası açıkça belirtmedikçe ERPC gRPC veya Shreds endpointleri için x-token, token veya Authorization header'ları eklemeyin.

Q. Daha önce yalnızca WebSocket veya Geyser gRPC (YellowStone) kullandım. Örnekleriniz var mı?

Evet. SLV kullanarak Shreds bağlantılarını test etmeye ve uygulama geliştirmeye hızlıca başlayabilirsiniz.

Ayrıntılar için lütfen aşağıdaki kılavuza bakın:

Shreds Hızlı Başlangıç Kılavuzu

Q. İki IP adresi kaydedebilir miyim?

Abonelik başına bir endpoint kullanabilirsiniz. İki IP adresi kullanmak istiyorsanız, iki ayrı aboneliğe abone olmanız gerekir.

Q. Hangi bölgeyi önerirsiniz?

Kalıcı olarak tek bir en iyi bölge yoktur. Solana küreseldir ve leader rolü validator'lar arasında slot slot dolaşır. Daha fazla validator'a ve daha yüksek stake'e sahip bölgeler leader slot'ları daha sık görür; bu da işlemlerin daha hızlı yerleşmesine yardımcı olabilir. Bunun karşılığında, rakip trafik de oraya yoğunlaşır; bu nedenle daha az kalabalık bir bölge, stratejinize bağlı olarak bazen daha iyi sonuçlar verebilir.

Pratik bir başlangıç noktası olarak, istikrarlı leader-slot arzının en önemli olduğu durumlarda Frankfurt veya ABD Doğu Yakası gibi validator yoğunluğu yüksek bir bölge seçin; en kısa yol üzerinden yürütme önceliğiniz olduğunda ise kendinizi belirli bir hedef validator'a yakın konumlandırın. Solana ağının kamuya açık dağılımını anlamak için Validators Solutions'ı kullanın, ardından tek bölge, çift bölge veya küresel dağıtımın uygun olup olmadığına karar vermek için ERPC Leader Slot API'yi ve gerçek ölçümleri kullanın.

Q. En az ~400ms veya daha iyi bir gecikmeye ihtiyacım var.

Yaklaşık 400ms içinde bir gecikme elde etmek için şu temel noktaları göz önünde bulundurun:

Ping Değerlerinin Gerçekçi Şekilde Anlaşılması: Ping değerleri ideal koşulları gösterir ve genellikle ping gecikmesinin yaklaşık 5 katını yaşayan akış (streaming) iletişimlerindeki gerçek gecikmeyi yansıtmaz. Örneğin, kıtalar arası 100ms'lik bir ping, gerçekte yaklaşık 500ms'lik bir gecikmeyle sonuçlanır. Bu nedenle, ~400ms gecikme elde etmek için altyapı aynı bölge içinde kurulmalıdır.
- Tipik Ping Değeri Referansı:
  - Aynı ağ: ~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 Gecikme Tuzağından Kaçınmak: Solana validator'ları coğrafi olarak küresel çapta dağılmıştır ve leader schedule her epoch'ta rastgele değişir. ~400ms elde etmek için ortalama gecikmeye güvenmek pratik değildir. Bunun yerine, en düşük gecikmeye sahip slot'ları belirlemek için kendi bölgenizdeki validator schedule'larını hassas bir şekilde takip etmelisiniz. Sürekli olarak minimum gecikme elde etmek için ilgili tüm bölgelerde altyapı gereklidir. Aynı bölge içinde, veri elde etme onlarca milisaniye içinde gerçekleşebilir ve iletim yalnızca birkaç milisaniyede mümkündür.
Leader Schedule'ın Takibi: ERPC Leader Slot API (getLeaderSlots) kullanarak bölgeniz için leader validator schedule'ını sürekli olarak izleyin. Yaklaşan leader'lar, stake ağırlığı, validator coğrafi konumları ve referans ping değerleri hakkında gerçek zamanlı veri sağlar; bu da en düşük gecikmeye sahip optimal ticaret slot'larını doğru bir şekilde belirlemenize olanak tanır. Kamuya açık harita tarzı veriler ve native RPC API'leri geniş ağ görünürlüğü için kullanışlıdır, ancak yürütme zamanlaması için yeterince hassas değildir. Leader Slot API, yönlendirme ve ticaret kararları için gereken ayrıntı düzeyiyle bu boşluğu doldurur.
- ERPC Leader Slot API Documentation
- ERPC Web Dashboard

Validators Solutions - Solana network data

Solana ağ verileri: Validators Solutions

Q. Sıfır blok (sıfır slot) ticaretini nasıl gerçekleştirebilirim?

Sıfır blok (sıfır slot) ticaretini başarıyla gerçekleştirmek, aşağıdaki gibi daha sofistike stratejiler gerektirir:

Fırsat Bölgelerinin Belirlenmesi: Solana validator'ları küresel olarak dağılmıştır ve her slot için optimal gecikme elde etmek fiziksel olarak imkânsızdır. Bu nedenle, altyapınızın bulunduğu bölgedeki validator leader schedule'larını izleyin ve en uygun fırsat bölgelerini belirleyin. Altyapıyı birden fazla bölgeye dağıtmak da avantajlı olabilir. Örneğin, Frankfurt yüksek validator yoğunluğu nedeniyle kilit bir bölgedir; bu da daha sık leader seçimine ve daha fazla ticaret fırsatına yol açar.

Gerçek zamanlı leader schedule'larını, stake ağırlığını, validator coğrafi konum verilerini ve referans ping değerlerini, kamuya açık harita tarzı veri kaynaklarına veya native RPC API'lerine göre çok daha yüksek hassasiyetle elde etmek için ERPC Leader Slot API (getLeaderSlots) kullanın. Bu, fırsat bölgelerini daha doğru bir şekilde tahmin etmenize ve sıfıra yakın gecikmeli ticaretler yürütmenize olanak tanır.
- ERPC Leader Slot API Documentation
- ERPC Web Dashboard
Dedicated Node'ların Uygulanması: Rekabet etmekte zorlanıyorsanız, dedicated node'lar kurmayı düşünün. Paylaşımlı node'lar, diğer kullanıcıların trafiği nedeniyle gecikme yaşar ve bu nedenle önerilmez. Ayrıca, dedicated node'unuzu uygulamanızla aynı ağ içine yerleştirmek, ağ gecikmesini önemli ölçüde azaltır ve performansı optimize eder.

Q. Belirli bir endpoint kullanabilir miyim?

Düşük gecikmeli bir ortamı korumak için sistemimiz mevcut en yakın node'u otomatik olarak seçer. Belirli bir endpoint kullanmak istiyorsanız, o endpoint'e en yakın konumda bir sunucu kiralamanızı öneririz.

Q. Dedicated endpoint'ler neden daha hızlı?

Paylaşımlı endpoint'ler, aynı kaynakları paylaşan birden fazla müşteri tarafından kullanılır. Trafik arttıkça gecikme oluşma eğilimindedir. Sunucu kaynaklarının fiziksel sınırları vardır ve işleyebilecekleri iş miktarı sonludur. Aynı anda çok fazla istek geldiğinde, bunlar sırayla işlenmelidir; bu da daha yavaş yanıt sürelerine yol açar.

Paylaşımlı endpoint'lerde bile performansı optimize etmek için çeşitli önlemler alsak da, dedicated endpoint'lerde kaynağın tek kullanıcısı sizsiniz. Bu, diğer kullanıcılardan tamamen etkilenmediğiniz, dolayısıyla sürekli olarak istikrarlı ve hızlı yanıtların garanti edildiği anlamına gelir.

Ayrıca, dedicated endpoint'ler HTTP gibi TLS olmadan iletişim seçenekleri sunar. TLS handshake (yaklaşık 20ms) atlanarak iletişim, HTTPS'ye kıyasla daha da hızlı hale gelir.

Q. Abone olduktan sonra satış fiyatı artırılacak mı?

Aboneliğiniz aktif kaldığı sürece, kayıt sırasında sabitlediğiniz satış fiyatı geçerli kalır. Solana'nın gerçek zamanlı iş yükü altında ayakta kalabilen ortamlar küresel çapta nadirdir ve artan donanım ile ağ talebine paralel olarak liste fiyatlarını yükseltmeyi planlıyoruz. Daha yüksek spesifikasyonlu konfigürasyonlar ve yüksek talep gören bölgeler en hızlı şekilde tükenir; bu nedenle mevcut promosyon fiyatını sabitlemek, uzun vadede en uygun maliyetli seçimdir.

Q. 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'i ERPC planlarını etkinleştirmek veya sürdürmek için kullanın. Dashboard'u açın, kripto ödemeyi seçin, transferi cüzdanınızdan gönderin; dashboard işlemi doğrulayacak ve credit'leri hesabınıza uygulayacaktır.

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

Q. ShredStream neden tüm işlemleri içermiyor?

Tasarımı gereği, Shreds, Solana blockchain'indeki her işlemi içermez. Tüm işlemleri izlemek, küresel çapta çok sayıda proxy dağıtmayı ve her validator'dan Shreds almayı gerektirir; bu da pratik değildir.

Tipik olarak kullanıcılar, mevcut verilerin bir alt kümesiyle çalışır; çünkü bu yaklaşım çoğu gerçek dünya uygulaması için yeterlidir. Kullanım senaryonuz hiçbir kayıp olmadan tam veri kapsamı gerektiriyorsa, Shreds uygun olmayabilir.

Daha kapsamlı izleme gerektiren senaryolarda, Geyser gRPC, Shreds'e kıyasla daha yüksek güvenilirlik sağlar. Ancak, Solana blockchain'inde %100 veri kapsamı elde etmek yine de çok sayıda edge sunucusu dağıtmayı gerektirir; bu da pratikte gerçekçi olmayabilir.

Geyser gRPC, Shreds'ten belirgin şekilde daha yüksek olan %99'u aşan bir güvenilirlik sunar; bu, bizim de aralarında bulunduğumuz birçok kullanıcı tarafından doğrulanmış bir gerçektir. Shreds ise tipik olarak %90'ın üzerinde güvenilirlik sağlar.

Her işlemi yakalamasalar da, en önemli avantajları, çoğu işlemi Geyser gRPC'den daha hızlı bir şekilde elde edebilmeleridir.

Daha derin bir anlayış için, Solana'nın Turbine ve Gulf Stream protokollerini incelemenizi öneririz:

Q. Mümkün olan en iyi ortamı istiyorum.

UDP Forwarding Standard için ilk yapılandırma sırasında kullanılabilir bir bölge seçin ve hedef olarak geçerli, boş olmayan bir genel IPv4 adresi ile bağlantı noktası yapılandırın. Seçilen bölge kurulumdan sonra sabit kalır; hedef daha sonra güncellenebilir.

Daha fazla ayrıntı için lütfen ERPC Web Dashboard üzerinden bizimle iletişime geçin.

ERPC Web Dashboard

🔗 ERPC Web Dashboard

Q. Gecikme ne kadar?

Gecikme, ölçüm yöntemine ve özel kullanım ortamınıza bağlı olarak değişir. Kesin sayısal değerlere odaklanmak yerine, gecikmenin gerçek operasyonel gereksinimlerinizi karşıladığından emin olmak çok önemlidir.

Gecikmeyi ölçmek için TypeScript ve Rust'ta kullanımı kolay araçlar sunuyoruz.

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

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, lütfen karşılaştırdığınız özel koşulları ve rakipleri ERPC Web Dashboard üzerinden bize bildirin. Nedenini belirleyecek ve hızı daha da iyileştireceğiz.

ERPC Web Dashboard

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

Genel olarak, en üst seviye planımız; üstün CPU'lar, daha yüksek bellek kapasiteleri ve sağlam donanım konfigürasyonları sayesinde en hızlı performansı sağlar.

Daha güçlü sunuculara ihtiyacınız varsa özelleştirilmiş çözümler de sunuyoruz, ancak standart planlarımız optimal fiyat/performans oranları sunacak şekilde tasarlanmıştır.

Her fiyat seviyesinde dünya standartlarında performans sunma konusunda kendimize güveniyoruz. Aynı fiyat aralığında daha hızlı bir sağlayıcı bulursanız, lütfen bize bildirin ki inceleyip iyileştirmeler yapabilelim.

Q. Yüksek gecikme yaşıyorum. Neden?

Gecikme, endpoint'e olan mesafeyle birlikte önemli ölçüde artar. Sağlanan endpoint'e daha yakın konumda bir sunucudan erişmenizi öneririz. En hızlı ortamlar Bare-Metal sunucularımız ve VPS hizmetlerimiz aracılığıyla mevcuttur.

Q. Hangisi en hızlı: WebSockets, gRPC veya Shreds?

Müşteri geri bildirimlerine dayanarak, performans sıralaması şöyledir:

Shreds > gRPC > WebSockets

Deneyiminiz farklıysa, lütfen bize bildirin.

Q. Gecikme beklediğim gibi değil.

Performans, kullanılan programlama diline bağlı olarak önemli ölçüde değişir. Genel olarak performans sıralaması şöyledir:

Rust > Go > TypeScript (JavaScript) > Python

Ayrıntılı karşılaştırmalar için lütfen bakın:

Programming Language Speed Comparison

En yüksek performans için Rust'ı şiddetle öneririz.