SSS - Solana 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 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 olarak görünüyor ve optimal 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	`82.21.43.35`
🇺🇸 New York	`151.243.244.162`
🇩🇪 Frankfurt	`151.241.178.73`
🇯🇵 Tokyo	`143.20.238.88`
🇸🇬 Singapore	`151.245.186.3`
🇬🇧 London	`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. UDP Forwarding, Standard ve Premium olarak sunulur. Her iki durumda da UDP Forwarding bölgesini ERPC Web Dashboard üzerinden seçersiniz ve Raw Shreds, UDP üzerinden yapılandırdığınız genel IPv4 adresine ve bağlantı noktasına ulaşır.

Bu endpoint'in yakınında ERPC VPS kullanın · UDP Forwarding seçeneklerini karşılaştırın Solana Shreds Hızlı Başlangıç kılavuzunu okuyun

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

Dashboard'da seçilen şifreli HTTPS uç noktasını kullanın; HTTPS 443 portunu kullanır. 80 portundaki HTTP ise şifrelenmemiş, düşük gecikmeli seçenek olmaya devam eder.

Her iki aktarım yöntemi de aynı kayıtlı IP allowlist'ini kullanır. Dashboard'da seçilen uç noktayı kullanın: HTTPS için 443, HTTP için 80.

HTTPS uç noktası: Dashboard'da seçilen uç noktayı 443 portunda kullanın.
HTTP uç noktası: Dashboard'da seçilen uç noktayı 80 portunda kullanın.
Dashboard'da gösterilen URL'yi https:// veya http:// biçiminde kullanın.

Kimlik doğrulama kayıtlı IP adresinize dayanır. Belirli bir ürün sayfası açıkça belirtmedikçe 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 uç nokta kullanabilirsiniz. İki IP adresi kullanmak isterseniz, iki ayrı abonelik almanız gerekir.

Q. Hangi bölgeyi önerirsiniz?

Tek bir kalıcı en iyi bölge yoktur. Solana küreseldir ve liderlik rolü lider programına göre validatörler arasında el değiştirir. Daha fazla validatöre ve daha yüksek stake'e sahip bölgeler lider slotlarını daha sık görür; bu da işlemlerin bloğa daha hızlı girmesine yardımcı olabilir. Bunun karşılığında, rekabet eden trafik de orada yoğunlaşır; bu nedenle stratejinize bağlı olarak daha az kalabalık bir bölge bazen daha iyi sonuçlar verebilir.

Pratik bir başlangıç noktası olarak, sürekli lider slot tedariki en çok önem taşıdığında Frankfurt veya ABD Doğu Kıyısı gibi validatör yoğunluğu yüksek bir bölge seçin ya da en kısa yol üzerinden yürütme öncelikliyse kendinizi belirli bir hedef validatörün yakınına konumlandırın. Halka açık Solana ağ dağılımını anlamak için Validators Solutions sayfasını kullanın, ardından tek bölgeli, çift bölgeli veya küresel dağıtımın uygun olup olmadığına karar vermek için ERPC Leader Slot API ile gerçek ölçümleri kullanın.

Q. ~400ms veya daha düşük bir gecikmeye ihtiyacım var.

Gecikmeyi yaklaşık 400ms içinde tutmak için şu temel noktaları göz önünde bulundurun:

Ping Değerlerinin Gerçekçi Yorumlanması: Ping değerleri ideal koşulları gösterir ve akış iletişimindeki gerçek gecikmeyi yansıtmaz; akış iletişiminde gecikme genellikle ping gecikmesinin yaklaşık 5 katıdır. Ö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.
- Referans için tipik ping değerleri:
  - 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 validatörleri coğrafi olarak dünya geneline dağılmıştır ve lider programı 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 slotları belirlemek için kendi bölgenizdeki validatör programları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 edinimi onlarca milisaniye içinde gerçekleşebilir ve iletim yalnızca birkaç milisaniyede mümkündür.
Lider Programının Takip Edilmesi: ERPC Leader Slot API (getLeaderSlots) kullanarak bölgeniz için lider validatör programını izleyin. Bu API, yaklaşan lider programını, mevcut epoch için stake ağırlığını, validatörlerin tahmini coğrafi konumlarını ve referans ping değerlerini döndürür; böylece hedefleyeceğiniz en düşük gecikmeli slotları sıraları gelmeden önce belirleyebilirsiniz. Halka açık harita tarzı veriler ve yerel RPC API'leri geniş ağ görünürlüğü için faydalıdır, ancak yürütme zamanlaması için yeterince hassas değildir. Leader Slot API, yönlendirme ve işlem kararları için gereken ayrıntı düzeyiyle bu boşluğu doldurur.
- ERPC Leader Slot API Dokümantasyonu
- ERPC Web Dashboard

Validators Solutions - Solana ağ verileri

Solana ağ verileri: Validators Solutions

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

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

Fırsat Bölgelerinin Belirlenmesi: Solana validatörleri dünya geneline dağılmıştır ve her slot için en uygun gecikmeyi elde etmek fiziksel olarak imkânsızdır. Bu nedenle, altyapınızın bulunduğu bölgedeki validatörlerin lider programları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 validatör yoğunluğu nedeniyle önemli bir bölgedir; bu da daha sık lider seçimine ve daha fazla işlem fırsatına yol açar.

Yaklaşan lider programını, mevcut epoch için stake ağırlığını, validatörlerin tahmini coğrafi konum verilerini ve referans ping değerlerini halka açık harita tarzı veri kaynaklarından veya yerel RPC API'lerinden çok daha yüksek hassasiyetle sorgulamak için ERPC Leader Slot API (getLeaderSlots) kullanın. Bu sayede slotların sırası gelmeden fırsat bölgelerinin haritasını çıkarabilir ve sıfıra yakın gecikmeli işlemler yürütebilirsiniz.
- ERPC Leader Slot API Dokümantasyonu
- ERPC Web Dashboard
Dedicated Düğümlerin Devreye Alınması: Rekabet etmekte zorlanıyorsanız, dedicated düğümler kullanmayı düşünün. Paylaşımlı düğümlerde diğer kullanıcıların trafiği gecikmeye yol açtığından bunlar önerilmez. Ayrıca, dedicated düğümünüzü uygulamanızla aynı ağa yerleştirmek, ağ gecikmesini önemli ölçüde azaltır ve performansı optimize eder.

Q. Belirli bir uç nokta kullanabilir miyim?

Düşük gecikmeli bir ortam sağlamak için sistemimiz en yakın uygun düğümü otomatik olarak seçer. Belirli bir uç nokta kullanmak isterseniz, o uç noktaya en yakın konumda bulunan bir sunucu kiralamanızı öneririz.

Q. Dedicated uç noktalar neden daha hızlıdır?

Paylaşımlı uç noktalar, aynı kaynakları paylaşan birden fazla müşteri tarafından kullanılır. Trafik arttıkça gecikme yaşanma olasılığı da artar. Sunucu kaynaklarının fiziksel sınırları vardır ve üstlenebilecekleri iş miktarı sınırlıdır. Aynı anda çok fazla istek geldiğinde, bunlar sırayla işlenmek zorundadır; bu da daha yavaş yanıt sürelerine yol açar.

Paylaşımlı uç noktalarda bile performansı optimize etmek için çeşitli önlemler alsak da, dedicated uç noktalarda kaynağın tek kullanıcısı sizsiniz. Bu sayede diğer kullanıcılardan hiçbir şekilde etkilenmezsiniz ve sürekli olarak istikrarlı, hızlı yanıtlar alırsınız.

Ayrıca, dedicated uç noktalar HTTP gibi TLS'siz iletişim seçenekleri sunar. TLS el sıkışması (yaklaşık 20ms) atlandığı için iletişim HTTPS'ye kıyasla daha da hızlanır.

Q. Abone olduktan sonra satış fiyatı yükseltilecek mi?

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 dayanıklılığını koruyan ortamlar küresel olarak nadirdir ve artan donanım ve ağ talebine paralel olarak fiyatlarımızı yükseltmeyi planlıyoruz. Daha yüksek özellikli yapılandırmalar ve yüksek talepli bölgeler en hızlı şekilde tükenir; bu nedenle mevcut fiyatı 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. Hesabınızda kayıtlı tüm ödeme kartları AB dışında düzenlenmişse kripto ödemeleri kullanılamaz. 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 kredileri hesabınıza tanımlayacaktı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 ve Premium olarak sunulur. İkisi de seçtiğiniz bölgeden alıcınıza ulaşır. Standard'da ERPC, Shreds'i o bölgedeki bir node'undan yönlendirir; böylece Shreds size tek bir kaynak IP'den ulaşır. Premium'da ise mesh ağ, her Shred'in kendisine ilk ulaşan kopyasını aktarır. Her iki durumda da ERPC Web Dashboard üzerinden bölgenizi seçin ve Raw Shreds'i alacak genel IPv4 adresi ile bağlantı noktasını ayarlayın.

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 düzeyde?

Gecikme, ölçüm yöntemine ve kendi özel kullanım ortamınıza bağlı olarak değişir. Tam 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 dillerinde kullanımı kolay araçlar sağlıyoruz.

Q. Bu RPC (gRPC, Shreds) 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şımlı mı yoksa dedicated bir uç nokta mı kullandığınıza, kullandığınız protokole (WebSockets, gRPC veya Shreds) ve istemcinizin programlama diline göre değişebilir.

Hizmetimizi daha yavaş bulursanız, lütfen karşılaştırdığınız belirli 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 düzey planımız üstün CPU'lar, daha yüksek bellek kapasiteleri ve sağlam donanım yapılandırmaları sayesinde en hızlı performansı sağlar.

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

Her fiyat seviyesinde dünya standartlarında performans sağlama konusunda kendimize güveniyoruz. Aynı fiyat aralığında daha hızlı bir sağlayıcı bulursanız, araştırıp iyileştirmeler yapabilmemiz için lütfen bize bildirin.

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. En hızlısı hangisi: WebSockets, gRPC mi yoksa Shreds mi?

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:

Programlama Dillerinin Hız Karşılaştırması

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