Ankr Alternatifi Olarak BlockVectra: Yöntem Tabanlı EVM Okuma Fiyatlandırması

BlockVectra, desteklenen eth_call okumalarını adet başına 15 CU olarak fiyatlandırır; tam bir 30,000,000 CU'luk ücretsiz bakiye, diğer tüm yöntemlerle paylaşılan ve hesap ile anahtar sınırlarına tabi olan bu tür 2,000,000 çağrıyı karşılayabilir.

Karşılaştırma

Rakip verileri 2026-10-08 tarihinde doğrulandı. BlockVectra yöntem ağırlıkları, ücretsiz plan ve anahtar sınırları 2026-10-09 tarihinde GET /v1/plans ile, log aralıkları ise GET /v1/chains ile kontrol edildi. Güncel rakamlar aşağıdaki bileşenler tarafından oluşturulmaktadır.

Ankr, 1M API Kredisini $0.10 olarak dönüştürür; bu nedenle 200 kredilik HTTPS EVM kategorisinin maliyeti çağrı başına $0.00002'dir. Bu fiyatlar WSS ve Advanced API hariçtir. Ücretsiz çağrı bütçesi, başka hiçbir yöntemin kredi tüketmediğini varsayar; aylık ve döngü haklarının kendi yenileme kuralları vardır ve fiili trafik hesap ve anahtar hız sınırlarına uymalıdır.

Neden BlockVectra'yı seçmelisiniz

Yöntem fiyatları ve ücretsiz hesap bütçesi

Aşağıdaki yöntem ağırlıkları, USD dönüşümü ve ücretsiz hesap bütçesi GET /v1/plans adresinden alınmıştır. Zincir sınırları GET /v1/chains adresinden gelir. Aynı zinciri, yöntemi, bloğu ve eksiksiz sonucu karşılaştırın; bölme ve yeniden denemeler çağrı sayısını değiştirir.

Ücretsiz hesap sınırı: hesaptaki tüm key'ler, tüm zincirler ve Data API genelinde paylaşılan, saniyede en fazla 25 çağrı. Anahtar başına key_defaults.cu_per_sec ve burst_cu sınırları da geçerlidir. Uygun döngü yenilemeleri, tam bir hibe eklemek yerine ücretsiz bakiyeyi hedefe tamamlar. İlk ücretli bakiye yüklemesi, kalan ücretsiz CU'yu korurken döngü yenilemelerini durdurur. Bkz. ücretsiz plan kuralları.

Yararlı çağrılarla ölçülen ücretsiz bir bütçe

Ücretsiz plan tablosu, tam bir döngü bakiyesinin yalnızca listelenen her bir yöntem için kullanıldığında karşılayabileceği çağrıları verir. Sözleşme okumaları, log sorguları ve blok numarası kontrolleri aynı CU bakiyesinden harcar: her yöntemi yöntem fiyatlandırma tablosundaki ağırlık üzerinden bütçelendirin, ardından maliyetleri toplayın. CU'yu loglar için kullanmak, sözleşme okumaları için kalan miktarı azaltır.

Uygun yenilemeler, tam bir hibe eklemek yerine bakiyeyi hedefine geri yükler. Geriye dönük bir doldurmadan (backfill) önce gerçek kalan CU'nuzu kontrol edin ve tüm anahtarları paylaşılan hesap sınırı ve anahtar başına sınırlar dahilinde hızlandırın; döngü çağrı sayısı garantili bir günlük kullanım hakkı değildir. Karışık iş yükü tahminleri için CU fiyatlandırmasını okuma bölümüne bakın.

Anahtarsız denemeler ve programatik Agent fonlaması

Bir anahtar oluşturmadan önce zincir kataloğunun public.url adresinde listelenen bir public.methods yöntemini deneyin. Kimlik doğrulamalı erişim için programatik kayıt, bir Agent'ın cüzdan imzasıyla bir hesap ve anahtar oluşturmasına olanak tanır. Agent bakiye yüklemeleri, aynı kullanım bakiyesini sabit kripto paralarla fonlar; ağları, tokenları ve minimumları bakiye yükleme durumundan okuyun. Geliştiriciler ve AI Agent'lar aynı fiyatları ve sınırları kullanır.

Çok zincirli adres Push

Tek bir HTTPS alıcısı ile bir abonelikte desteklenen birkaç zincirdeki aynı adres kümesini izleyin. Bu, zincir başına bir soket tutmaya gerek kalmadan cüzdan aktivitesi ve ödeme bildirimleri için uygundur. Bkz. self-servis ve kurumsal adres kapasitesi; kurumsal kapasiteyi etkinleştirmek için bize ulaşın. Adres-gün ve iletilen olay ücretleri RPC çağrılarından ayrıdır ve Push fiyatlandırması bölümünde listelenmiştir.

Robinhood Chain ve HyperEVM üzerindeki RPC, zincir kataloğunda listelenmiştir. Ağ başına yöntemleri ve Push desteğini kontrol edin; ilgili iş akışı için zincire özel başlangıç rehberini ve HyperEVM geriye dönük doldurma rehberini kullanın.

Geçiş adımları

1. Envanter ve kapsam: zincirleri, yöntemleri, sabit blokları, log aralıklarını ve abonelik bağımlılıklarını listeleyin. Katalogda methods.allow, methods.deny, public.methods, state_window_blocks ve ws alanlarını kontrol edin. Boş (null) bir geçmiş penceresi arşiv kapsamı değil, belirtilmemiş anlamına gelir. Anahtarsız bir public.url duman testi yalnızca listelenen genel yöntemlerini doğrular.
2. Anahtar ve kimlik doğrulama: konsol veya programatik kayıt aracılığıyla bir BlockVectra anahtarı edinin. Bunu sunucu ortamınızda saklayın. RPC, POST /v1/{chain}/{api_key} veya x-api-key ile POST /v1/{chain} kabul eder; Data API x-api-key kullanır. Bu Ethereum WETH decimals() örneği başlığı kullanır:

if [ -z "$BLOCKVECTRA_API_KEY" ]; then
  echo "Set BLOCKVECTRA_API_KEY in your server environment"
  exit 1
fi

curl --fail-with-body -sS --max-time 15 https://api.blockvectra.com/v1/eth_mainnet \
  -H 'Content-Type: application/json' \
  -H 'User-Agent: curl BlockVectraQA/1' \
  -H "x-api-key: $BLOCKVECTRA_API_KEY" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2","data":"0x313ce567"},"latest"]}'

3. Geçişten önce yeniden oynatın: her iki sağlayıcıda latest yerine desteklenen aynı sabit bloğu koyun ve blok karmasını kaydedin. HTTP 200'den sonra bile döndürülen değerleri ve JSON-RPC error nesnesini karşılaştırın. Temsili log sorgularını, sınırlı yeniden denemeleri, hız sınırı kurtarmayı ve imleç sürdürmeyi test edin. Tescilli API'leri ve abonelikleri ayrı olarak geçirin; trafiği yalnızca gerekli sonuçlar eşleştikten sonra taşıyın.

SSS

Daha düşük bir yöntem fiyatı daha düşük toplam görev maliyeti anlamına mı gelir?

max(0, sum(calls × method CU) − available_free_cu) / (pricing.units_per_usd × pricing.cu_per_unit) formülünü hesaplayın. Bölme, yeniden denemeler ve görevinizin kullandığı tüm hizmetleri dahil edin. Mevcut dahil edilen krediler marjinal maliyetleri değiştirir; faturalandırma birimi adları yerine eksiksiz sonucu karşılaştırın.

Yalnızca uç noktayı değiştirerek geçiş yapabilir miyim?

Desteklenen standart RPC yöntemleri için uç noktayı ve yol anahtarını veya x-api-key başlığını güncelleyin, ardından sabit blok isteklerini yeniden oynatın. Önce geçmiş durum ve yöntem kapsamını kontrol edin. Tescilli API'ler, WebSocket abonelikleri ve Push alıcıları kendi geçiş testlerine ihtiyaç duyar; bkz. geçmiş durum ve Webhook ile WebSocket karşılaştırması.

İş yükü kontrol listesi ve kendi kendine testler için Bir RPC sağlayıcısı nasıl seçilir rehberini kullanın.