HyperEVM RPC hız sınırları ve log geriye dönük doldurma

BlockVectra'da, kimlik doğrulamalı HyperEVM eth_getLogs sorguları her iki uç nokta dahil en fazla 1,000 bloğu kapsar; daha uzun pencereleri bölün ve devam etmek için tamamlanan son bloğu kaydedin.

Doğrudan yanıt

Varsayılan resmi HyperEVM genel RPC'si, eth_getLogs sorgusu başına 50 bloğa izin verir (kaynak: Hyperliquid resmi JSON-RPC dokümantasyonu). BlockVectra'da, kimlik doğrulamalı eth_getLogs istekleri her iki uç nokta dahil sorgu başına 1,000 bloğa kadar kapsar (GET /v1/chains uç noktasından hyperevm_mainnet.max_logs_block_range). Daha geniş bir aralık HTTP 200, JSON-RPC -32602 ve retryable: false ile logs_range_too_large döndürür (bkz. hata kataloğu); [from, min(from + max − 1, end)] olarak bölün, imlecinizi kaydedin ve çalıştırmaları sürdürmek için başarıdan sonra sonuncunun bir fazlasına ilerleyin. Resmi genel RPC'nin IP başına hız sınırı ve BlockVectra'nın anahtar sınırları, Resmi genel RPC hız sınırları ve 429 bölümünde ve aşağıdaki hizmet parametrelerinde ayrı ayrı açıklanmıştır.

  • İlk adım: Aşağıdaki curl komutunu kullanarak bir API anahtarı olmadan en son bloğu okuyun.
  • Tamamlanma kriteri: Geriye dönük doldurma betiği, seçtiğiniz penceredeki her parça için fromBlock, toBlock ve bir result dizisi çıktısı verir; boş bir dizi o parçada eşleşen log olmadığı anlamına gelir.

Zincir parametreleri ve erişim seçenekleri.

Bu rehberin tamamlamanıza yardımcı olduğu görevler

Üç adımlı görev: sınırlı bir HyperEVM log penceresini geriye dönük doldurun

Bir anahtar olmadan en son bloğu okuyun, bir anahtar oluşturun ve ardından sonlu bir blok penceresinde bir sözleşme için olay loglarını alın.

İhtiyacınız olan sözleşmeyi ve blok penceresini seçin. Bu görev söz konusu sınırlı pencereyi kapsar; eksiksiz bir sözleşme geçmişi vaat etmez.

1. API anahtarı olmadan en son bloğu okuyun

curl -sS "https://api.blockvectra.com/v1/hyperevm_mainnet/public" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

JSON-RPC result alanı onaltılık olarak en son blok numarasıdır. Bu, GET /v1/chains tarafından yayınlanan HyperEVM public.url adresidir. Genel uç noktanın public.methods listesi eth_getLogs içermez; 3. adım bir anahtar gerektirir.

2. Bir API anahtarı oluşturun

Bu geriye dönük doldurma için bir anahtar oluşturun. Bir anahtar oluşturun ve iletişim kutusunda gösterilen gizli anahtarı hyperevm_mainnet ile kullanmak üzere kaydedin.

Tarayıcı olmadan HTTP kullanan bir AI Agent için Programatik kayıt rehberi adımlarını izleyin. POST /auth/siwe/login JSON gövdesinde örneğin docs-signup değeri yerine rehber URL'sinin geçerli ref değerini iletin; mevcut değilse atlayın. Kullanıcıdan anahtarı sohbete yapıştırmasını istemeyin.

3. Anahtarınızla logları geriye dönük doldurun

Eksiksiz başlangıç şablonu: blockvectra/hyperevm-backfill

Aşağıdaki betiği hyperevm-task.ts olarak kaydedin. Ek bir paket olmadan Node.js 24 veya üzeri ile çalışır. BLOCKVECTRA_API_KEY değerini kayıtlı anahtarınıza ve LOG_ADDRESS değerini incelemek istediğiniz yayımlayıcı sözleşme adresine ayarlayın; anahtarı sunucunuzda veya yerel bir terminalde tutun.

export BLOCKVECTRA_API_KEY='replace-with-your-key'
export LOG_ADDRESS='replace-with-contract-address'
node hyperevm-task.ts

Varsayılan olarak betik, en son max_logs_block_range bloğu veya başlangıç yakınında daha azını alır. Bu sınırı çalışma zamanında /v1/chains üzerinden okur. Başka bir sonlu pencere seçmek için çalıştırmadan önce hem FROM_BLOCK hem de TO_BLOCK değerlerini ondalık veya 0x onaltılık blok numaralarına ayarlayın. Daha büyük pencereler, her biri en fazla yayınlanan sınır kadar olan ardışık parçalara bölünür.

const apiKey = process.env.BLOCKVECTRA_API_KEY;
const address = process.env.LOG_ADDRESS;
if (!apiKey || apiKey === "replace-with-your-key") throw new Error("Set BLOCKVECTRA_API_KEY");
if (!address || !/^0x[0-9a-f]{40}$/i.test(address)) throw new Error("Set LOG_ADDRESS to a contract address");

const fromBlock = process.env.FROM_BLOCK;
const toBlock = process.env.TO_BLOCK;
if ((fromBlock !== undefined || toBlock !== undefined) && (!fromBlock || !toBlock)) {
  throw new Error("Set both FROM_BLOCK and TO_BLOCK");
}

const chainsUrl = "https://api.blockvectra.com/v1/chains";
const rpcUrl = new URL("./hyperevm_mainnet", chainsUrl).href;
async function readJson(url: string) {
  const response = await fetch(url, { signal: AbortSignal.timeout(15_000) });
  if (!response.ok) throw new Error(`Metadata HTTP ${response.status}`);
  return response.json();
}
const catalog = await readJson(chainsUrl);
const chain = catalog.chains.find((item: { chain: string }) => item.chain === "hyperevm_mainnet");
if (!chain || !Number.isSafeInteger(chain.max_logs_block_range) || chain.max_logs_block_range <= 0) {
  throw new Error("Missing or invalid max_logs_block_range");
}
if (!chain.methods.allow.includes("eth_getLogs") || chain.methods.deny.includes("eth_getLogs")) {
  throw new Error("eth_getLogs is unavailable on this chain");
}
const maxRange = BigInt(chain.max_logs_block_range);
const plans = await readJson("https://console-api.blockvectra.com/v1/plans");
function weight(method: string): bigint {
  const row = plans.method_weights.find((item: { method: string }) => item.method === method);
  if (!row || !Number.isSafeInteger(row.cu_weight) || row.cu_weight <= 0) {
    throw new Error(`Missing or invalid CU weight for ${method}`);
  }
  return BigInt(row.cu_weight);
}
const headWeight = weight("eth_blockNumber");
const logsWeight = weight("eth_getLogs");

type RpcBody = {
  result?: unknown;
  error?: { code: number; data?: { retryable?: boolean } };
};
async function rpc(method: string, params: unknown[]): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt++) {
    const response = await fetch(rpcUrl, {
      method: "POST",
      redirect: "error",
      headers: { "Content-Type": "application/json", "x-api-key": apiKey! },
      body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
      signal: AbortSignal.timeout(15_000),
    });
    const body = await response.json() as RpcBody;
    if (response.ok && !body.error && body.result !== undefined) return body.result;
    if (body.error?.data?.retryable !== true || attempt === 3) {
      throw new Error(`RPC failed: HTTP ${response.status}, code ${body.error?.code ?? "unknown"}`);
    }
    const retryAfter = response.headers.get("Retry-After");
    const delay = retryAfter === null ? 0 : /^\d+$/.test(retryAfter)
      ? Number(retryAfter) * 1000 : Date.parse(retryAfter) - Date.now();
    if (delay > 30_000) throw new Error("Retry-After exceeds 30 seconds; rerun later");
    const backoff = 1000 * 2 ** attempt + Math.random() * 250;
    await new Promise((resolve) => setTimeout(resolve, Math.max(backoff, Number.isFinite(delay) ? delay : 0)));
  }
  throw new Error("Retry limit reached");
}
function block(value: string): bigint {
  if (!/^(0x[0-9a-f]+|[0-9]+)$/i.test(value)) throw new Error("Invalid block number");
  return BigInt(value);
}
const head = await rpc("eth_blockNumber", []);
if (typeof head !== "string" || !/^0x[0-9a-f]+$/i.test(head)) throw new Error("Invalid chain head");
const latest = block(head);
const end = toBlock ? block(toBlock) : latest;
const start = fromBlock ? block(fromBlock)
  : end >= maxRange - 1n ? end - maxRange + 1n : 0n;
if (start > end || end > latest) throw new Error("Require 0 <= FROM_BLOCK <= TO_BLOCK <= latest");
const chunks = (end - start + maxRange) / maxRange;
console.error(`Window ${start}..${end}; chunks=${chunks}; estimated CU=${headWeight + chunks * logsWeight}`);

const hex = (value: bigint) => `0x${value.toString(16)}`;
for (let from = start; from <= end; from += maxRange) {
  const to = from + maxRange - 1n < end ? from + maxRange - 1n : end;
  const result = await rpc("eth_getLogs", [{ address, fromBlock: hex(from), toBlock: hex(to) }]);
  if (!Array.isArray(result)) throw new Error("Expected eth_getLogs result array");
  console.log(JSON.stringify({ fromBlock: hex(from), toBlock: hex(to), result }));
}

İstekler sıralı olarak çalışır. Bir JSON-RPC hatası yalnızca error.data.retryable true olduğunda, istek başına en fazla dört deneme, üstel geri çekilme ve rastgele gecikme ve Retry-After saniyesi veya bir HTTP tarihi desteğiyle yeniden denenir. 30 saniyeden uzun bir bekleme, daha sonra tekrar çalıştırabilmeniz için betiği durdurur. Ağ arızaları, zaman aşımları, hatalı biçimlendirilmiş yanıtlar ve yeniden denenemeyen hatalar hemen durur; betik tam bir geriye dönük doldurma bildirmek yerine başarısız olarak çıkar.

Her standart çıktı satırı bir parçanın fromBlock, toBlock ve result dizisini içerir. result: [], o parçada eşleşen log olmadığı anlamına gelir. Her logda şu alanları okuyun:

AlanAnlamı
addressOlayı yayımlayan sözleşme.
blockNumber, blockHashLogu içeren blok; numara onaltılıktır.
transactionHash, transactionIndex, logIndexİşlem ve log konumu; indeksler onaltılıktır.
topics, dataİndekslenmiş olay argümanları ve ABI ile kodlanmış indekslenmemiş argümanlar; sözleşme ABI'si ile çözün.
removedLogun bir zincir yeniden düzenlemesi tarafından kaldırılıp kaldırılmadığı.

En son blok bir kesinlik işareti değildir. Kararlı bir geçmiş penceresine ihtiyacınız varsa, uygulamanızın onaylanmış TO_BLOCK değerini seçin ve zincir yeniden düzenlemelerini yönetin.

B = TO_BLOCK − FROM_BLOCK + 1 blokluk bir pencere ve yayınlanan L sınırı için parça sayısı N = ceil(B / L) şeklindedir. GET /v1/plans üzerinden eth_getLogs ve eth_blockNumber için method_weights[].cu_weight değerini okuyun. Betik standart hataya bir tahmin yazdırır: anahtarlı tepe aramasını içeren N × weight(eth_getLogs) + weight(eth_blockNumber). Bu, fazladan çağrıları ve faturalandırılabilir yeniden denemeleri hariç tutar; tahakkuk için faturalandırma kurallarına bakın. CU, döndürülen log sayısından ziyade çağrılara bağlıdır.

Olay iletimi: Aşağıdaki parçalı HTTP yoklamasını kullanın veya izlenen adres olaylarını webhook push ile bir HTTPS alıcısına gönderin. GET /v1/push/chains desteklenen zincirleri ve onay ayarlarını listeler; x-api-key ile kimlik doğrulaması yapın. Webhook imzaları, tekilleştirme ve yeniden oynatma bu rehberde ele alınmıştır. Webhook push, WebSocket aboneliklerinden (/v1/chains içindeki ws ve subscriptions) ayrıdır.

viem veya ethers ile bağlanın

Parametre / Uç NoktaDeğer / ŞablonKimlik Doğrulama
Chain ID (EIP-155)999—
JSON-RPC (yol anahtarı)POST https://api.blockvectra.com/v1/hyperevm_mainnet/{api_key}URL yolunda API key
JSON-RPC (başlık anahtarı)POST https://api.blockvectra.com/v1/hyperevm_mainnetHeader x-api-key: {api_key}
Data API tabanıGET https://api.blockvectra.com/v1/data/hyperevm_mainnet/…Header x-api-key: {api_key}
Genel durumGET https://api.blockvectra.com/v1/statusKimlik doğrulamasız (genel)

Geliştiriciler ve AI Agent'lar aynı sunucu tarafı ayarlarını kullanabilir. Node.js 24 veya üzeri, viem 2 veya ethers 6 kullanın ve genel okumalarla başlayın. Anahtarlı yöntemler için ortamda güvenli bir şekilde BLOCKVECTRA_API_KEY ayarlayın. Anahtarları ve anahtar içeren RPC URL'lerini tarayıcı kodundan, loglardan ve sürüm denetiminden uzak tutun.

Bunu network.mjs olarak kaydedin. chain_id ve yöntem politikasını GET /v1/chains üzerinden okur. Anahtarsız okumalar için kataloğun public.url adresini ve yalnızca public.methods içinde listelenen yöntemleri kullanın; genel HTTP kullanılabilirliği WebSocket erişimi anlamına gelmez.

const chainSlug = process.env.BLOCKVECTRA_CHAIN ?? 'hyperevm_mainnet';
const key = process.env.BLOCKVECTRA_API_KEY;
const catalogUrl = 'https://api.blockvectra.com/v1/chains';
const response = await fetch(catalogUrl, { signal: AbortSignal.timeout(15_000) });
if (!response.ok) throw new Error(`Chains HTTP ${response.status}`);
const catalog = await response.json();
export const chainInfo = catalog.chains.find(item => item.chain === chainSlug);
if (!chainInfo || !Number.isSafeInteger(chainInfo.chain_id) || chainInfo.chain_id <= 0) {
  throw new Error('Missing chain or chain_id');
}
export function allows(method) {
  const matches = pattern => pattern.endsWith('*')
    ? method.startsWith(pattern.slice(0, -1)) : pattern === method;
  if (!key) return (chainInfo.public?.methods ?? []).some(matches);
  return (chainInfo.methods?.allow ?? []).some(matches)
    && !(chainInfo.methods?.deny ?? []).some(matches);
}
if (!allows('eth_chainId')) throw new Error('eth_chainId is unavailable');
export const rpcUrl = key
  ? new URL(`./${chainSlug}/${encodeURIComponent(key)}`, catalogUrl).href
  : chainInfo.public?.url;
if (!rpcUrl) throw new Error('Public RPC is unavailable; set BLOCKVECTRA_API_KEY');

viem-client.mjs olarak kaydedin, npm install viem@2 ile kurun, ardından node viem-client.mjs komutunu çalıştırın.

import { createPublicClient, defineChain, http } from 'viem';
import { chainInfo, rpcUrl } from './network.mjs';

export const chain = defineChain({
  id: chainInfo.chain_id,
  name: chainInfo.name,
  nativeCurrency: { name: 'HYPE', symbol: 'HYPE', decimals: 18 },
  rpcUrls: { default: { http: [rpcUrl] } },
});
export const client = createPublicClient({ chain, transport: http(rpcUrl) });
if (await client.getChainId() !== chain.id) throw new Error('RPC chain ID mismatch');
console.error(await client.getBlockNumber());

ethers için ethers-client.mjs olarak kaydedin, npm install ethers@6 ile kurun, ardından node ethers-client.mjs komutunu çalıştırın.

import { JsonRpcProvider } from 'ethers';
import { chainInfo, rpcUrl } from './network.mjs';

const provider = new JsonRpcProvider(rpcUrl, chainInfo.chain_id, { batchMaxCount: 1 });
const network = await provider.getNetwork();
if (network.chainId !== BigInt(chainInfo.chain_id)) throw new Error('RPC chain ID mismatch');
console.log(await provider.getBlockNumber());
provider.destroy();

Foundry veya Hardhat ile dağıtım

Mevcut hyperevm_mainnet kataloğunda ws=false vardır ve methods.allow içinde eth_sendRawTransaction listelenmez. Okumalar için BlockVectra'yı kullanın; dağıtım, yayınlamayı destekleyen bir RPC gerektirir. DEPLOY_RPC_URL değişkenini o sağlayıcının kimlik doğrulamalı HTTP URL'sine ayarlayın. BlockVectra'nın yöntem veya log aralığı sınırlarını paylaştığını varsaymayın. İmzalamadan önce seçilen zincir kimliğini kontrol edin.

: "${DEPLOY_RPC_URL:?Set a broadcasting RPC URL}"
export RPC_URL="$DEPLOY_RPC_URL"
export CHAIN_ID="$(node --input-type=module -e "import { chainInfo } from './network.mjs'; console.log(chainInfo.chain_id)")"

Paylaşılan Foundry veya Hardhat dağıtım eğitimi ile devam edin. Dağıtıcıyı EVM HYPE ile fonlayın ve büyük bir dağıtımdan önce aşağıdaki ikili blok gereksinimlerini gözden geçirin.

HYPE, küçük bloklar ve büyük dağıtımlar

HyperEVM'in resmi ağ kılavuzu, 18 ondalık basamağa sahip HYPE'ı gaz olarak tanımlar (erişim: 2026-10-07). Dağıtıcının HyperEVM üzerinde HYPE tuttuğundan emin olun; tek başına bir HyperCore bakiyesi EVM gaz bakiyesi değildir. Fonları taşırken bağlantılı yerel transfer talimatlarını izleyin.

İkili blok kılavuzu, daha büyük işlemler için hızlı küçük blokları ve daha yavaş büyük blokları tanımlar (erişim: 2026-10-07). Önce dağıtım gazını tahmin edin. Küçük blok bütçesini aşan dağıtımlar için, dağıtıcının mevcut bir HyperCore kullanıcısı olması ve {"type":"evmUserModify","usingBigBlocks":true} Core eylemini imzalaması gerekir; tek başına daha büyük bir işlem gaz limiti ayarlamak büyük blokları seçmez. Küçük bloklara dönmek için daha sonra usingBigBlocks=false durumuna geri getirin.

Bunları destekleyen bir sağlayıcıda, adres modunu kontrol etmek için eth_usingBigBlocks ve büyük blok taban ücreti için eth_bigBlockGasPrice kullanın. Resmi JSON-RPC referansı bu yöntemleri belgeler (erişim: 2026-10-07). Seçilen sağlayıcının yöntemlerini kontrol edin; BlockVectra için /v1/chains kullanın. Yukarıdaki minimal dağıtım küçük bir sözleşmeyi hedefler ve Core hesap modunu değiştirmez.

HyperCore ve HyperEVM verileri

EVM RPC sözleşmelere, makbuzlara ve loglara hizmet verir. HyperCore alım satım verileri ve eylemleri Core API'yi kullanır. Sözleşmeler ön derlemeler aracılığıyla Core durumunu okuyabilir ve CoreWriter aracılığıyla eylemler gönderebilir; bu yolları entegre ederken resmi etkileşim kılavuzunu kullanın (erişim: 2026-10-07). EVM logları, Core emir defteri veya pozisyon sorgularının yerini almaz.

HyperEVM sistem işlemleri (HyperCore'dan HyperEVM'e transferler gibi) standart eth_getBlockByNumber yanıtlarına dahil edilmez ve resmi RPC tarafından eth_getSystemTxsByBlockNumber ve eth_getSystemTxsByBlockHash aracılığıyla ayrı olarak sunulur (erişim: 2026-10-07 tarihli resmi JSON-RPC dokümantasyonuna bakın). BlockVectra'nın HyperEVM blok, işlem ve Data API verileri şu anda sistem işlemlerini içermez; sistem işlemi verisi gerektiğinde doğrudan bu iki resmi RPC yöntemini kullanın.

Resmi hata 10055'i ele alma

Resmi HyperEVM kılavuzu, 10055 kodunu nonce, yetersiz bakiye, yinelenen hash ve düşük fiyatlı değiştirme hataları dahil olmak üzere bir Core/EVM sınır hatası olarak tanımlar (erişim: 2026-10-07). Kurtarma işlemine karar vermeden önce yayıncı RPC'den gelen mesajı inceleyin:

  • Nonce: eth_getTransactionCount değerini bekleyen işlemlerinizle karşılaştırın; tek bir dağıtıcıdan gelen gönderimleri seri hale getirin ve bir sonraki nonce değerini mutabık kılın.
  • Bakiye: dağıtıcının EVM HYPE bakiyesini değer artı gaz maliyetine karşı kontrol edin.
  • Yinelenen hash: başka bir işlem göndermeden önce mevcut işlemi ve makbuzu arayın.
  • Değiştirme ücreti: mevcut nonce ve ücreti doğrulayın, ardından yayıncının değiştirme politikasını kullanın; aynı baytları tekrarlamak ücreti yükseltmez.

10055 tek başına körü körüne yeniden denemeleri haklı çıkarmaz. Hataları ve kurtarma rehberliğini BlockVectra hata referansında ayrı olarak okuyun.

Resmi genel RPC hız sınırları ve 429

Hyperliquid'in resmi hız sınırı dokümantasyonu, rpc.hyperliquid.xyz/evm için IP başına dakikada en fazla 100 EVM JSON-RPC isteği belirtir. JSON-RPC dokümantasyonu ayrıca eth_getLogs çağrısını sorgu başına 50 blok ve en fazla 4 topic ile sınırlar. Erişim: 2026-10-07.

HTTP 429 durumunda, istekleri duraklatın ve önce Retry-After başlığına uyun (saniye veya bir HTTP tarihi). Yoksa, tamamlanmamış aynı parçayı yeniden deneyerek rastgele gecikmeli üstel geri çekilme ve sınırlı bir yeniden deneme sayısı kullanın. Eşzamanlılığı ve yoklama sıklığını azaltın ve log sorgularını uç noktanın sınırı dahilinde parçalara bölün. Yalnızca parçalama hız sınırlarını kaldırmaz; bir IP'yi paylaşan istemcilerin istek hızlarını koordine etmeleri gerekir.

BlockVectra'nın anahtarlı uç noktası için, resmi genel RPC'nin blok aralığını veya dakika başına istek sınırını uygulamak yerine GET /v1/chains üzerinden hyperevm_mainnet'in max_logs_block_range, methods.allow ve methods.deny alanlarını okuyun. İstek hızı, anahtarın cu_per_sec, burst_cu ve ücretsiz plan çağrı sınırına ayrıca tabidir (bir sonraki bölüme bakın). 429 durumunda error.data.reason ve retryable alanlarını inceleyin; request_exceeds_burst, geri çekilme ile değişmeyen yeniden denemeler yerine daha küçük istekler gerektirir.

BlockVectra parametreleri ve hizmet kuralları

BlockVectra, HyperEVM ana ağına JSON-RPC ve REST Data API uç noktaları aracılığıyla hizmet verir:

  1. Zincir parametreleri ve log sınırları: hyperevm_mainnet için GET /v1/chains uç noktasından:
    • Zincir tanımlayıcısı (Slug): hyperevm_mainnet, Chain ID 999.
    • max_logs_block_range: GET /v1/chains içindeki max_logs_block_range alanı tarafından yönetilir. Tek bir eth_getLogs isteği en fazla bu sayıda bloğu kapsayabilir (toBlock − fromBlock + 1). Bu aralığın aşılması, faturalandırılmayan -32602 (eth_getLogs block range too large: max <N> blocks) JSON-RPC hata koduyla birlikte HTTP 200 döndürür.
    • state_window_blocks: GET /v1/chains içindeki state_window_blocks alanı tarafından yönetilir. Durum okuma çağrıları (eth_call ve eth_getBalance gibi), bu alan tarafından bildirilen saklama penceresine tabidir (null olduğunda, hareketli bir pencere sınırı olmaksızın tam durum korunur).
    • Yöntem politikası: methods.allow ve methods.deny tarafından yönetilir. Standart EVM yöntemlerine (eth_blockNumber, eth_getLogs, eth_call, eth_getBalance, eth_getBlockByNumber, eth_getTransactionReceipt vb.) izin verilir; filtre ve abonelik yöntemleri (eth_subscribe, eth_unsubscribe, eth_newFilter, eth_newBlockFilter) reddedilir ve -32601 döndürür (faturalandırılmaz).
  2. Ücretsiz katman hız sınırları ve yükseltme: GET /v1/plans uç noktasından:
    • free.max_calls_per_sec: hesaptaki tüm key'ler, tüm zincirler ve Data API genelinde paylaşılan, saniyede en fazla 25 çağrı.
    • Varsayılan anahtar sınırları: Her API anahtarının bir CU kovası vardır (cu_per_sec yenileme, burst_cu kapasitesi — varsayılanlar 400 CU/s ve ani artış (burst) 1,600 CU). Yöntemler Compute Unit (CU) ağırlıklarına göre ölçülür.
    • Sınırları yükseltme: Bakiye yüklemesinden sonra hesap genelindeki saniye başına çağrı sınırı kaldırılır; her anahtar Compute Unit (CU) hız ve burst sınırlarına tabi kalmaya devam eder. Güncel tarifeler ve faturalandırma birimleri için Fiyatlandırma sayfasına bakın.

Geçmiş logları geriye dönük doldurma: parçalı eth_getLogs ve yeniden deneme mantığı

Geçmiş logları sorgularken, geniş aralıklar hedef zincirin max_logs_block_range değeriyle sınırlandırılmış bitişik parçalara bölünmelidir. İstemci yeniden deneme stratejileri, hata yanıtları içindeki retryable alanını incelemelidir.

Hata yanıtlarında retryable değerlendirmesi

BlockVectra'da JSON-RPC hata nesneleri reason, docs_url ve retryable (boolean) içeren bir error.data yükü barındırır:

  • retryable: true: Hizmet aşırı yükü (overloaded), ücretsiz plan saniye başına çağrı sınırı (free_plan_call_limit), düğüm senkronizasyonu (node_syncing) veya yukarı akışın kullanılamaması (upstream_unavailable) dahil olmak üzere geçici durumlar. İstemciler mevcut olduğunda Retry-After başlığına uymalı veya rastgele gecikmeli üstel geri çekilme uygulamalıdır.
  • retryable: false: Sınırları aşan blok aralığı (-32602 / logs_range_too_large), geçersiz parametreler (invalid_params), eksik API anahtarı (missing_api_key) veya burst kapasitesini aşan istek (-32022 / request_exceeds_burst) gibi geçici olmayan hatalar. Parametreler ayarlanmadan yeniden denemek başarılı olmayacaktır.

Aşağıda bir API anahtarı atlandığında döndürülen yanıt yer almaktadır:

{
  "jsonrpc": "2.0",
  "id": null,
  "error": {
    "code": -32024,
    "message": "missing API key: send it in the request path (/v1/{chain}/<api_key>) or in the x-api-key header",
    "data": {
      "reason": "missing_api_key",
      "docs_url": "https://docs.blockvectra.com/en/errors/#missing_api_key",
      "retryable": false
    }
  }
}

Kapsamlı getLogs taraması yerine Data API uç noktalarını kullanma

Bir uygulama belirli bir adres için işlem geçmişini veya token hareketlerini izlediğinde, eth_getLogs aracılığıyla tarama yapmak max_logs_block_range ile sınırlı sıralı parçalı sorgular göndermeyi ve ham Transfer olay loglarını ayrıştırmayı gerektirir.

BlockVectra Data API, hyperevm_mainnet için önceden indekslenmiş REST uç noktaları sunarak imleç tabanlı sayfalamayla 100.000 bloğa kadar olan pencereleri destekler:

  1. Adres işlemleri: GET /v1/data/hyperevm_mainnet/addresses/{address}/transactions
    • Parametreler: from_block (zorunlu), to_block (zorunlu), direction (isteğe bağlı: from, to, any, varsayılan any), clamp (isteğe bağlı boolean dize, varsayılan false; true olarak ayarlandığında, 100.000 bloğu aşan veya as_of_block değerinden daha yüksek pencereler 409 döndürmek yerine kırpılır), limit (isteğe bağlı, maks 500), cursor (sayfalama belirteci).
  2. Adres token transferleri: GET /v1/data/hyperevm_mainnet/addresses/{address}/transfers
    • Parametreler: standard (zorunlu: erc20 veya erc721; erc1155 adrese göre sorgulanamaz ve 422 no_coverage döndürür), token (isteğe bağlı token sözleşmesi filtresi), from_block (zorunlu), to_block (zorunlu), direction (isteğe bağlı: in, out, any), clamp (isteğe bağlı), limit, cursor.

Yanıt yapısı

Yanıtlar standart zarf şemalarını kullanır:

  • data: Kayıtlar dizisi. İşlemler hash, block_number, block_timestamp, from, to, value, tx_index, gas_limit, gas_used ve status içerir. Transferler token, standard, from, to, block_number, block_timestamp, tx_hash, tx_index ve log_index içerir (ERC-20 için amount, ERC-721 için token_id).
  • next_cursor: Sonraki kayıtlar mevcut olduğunda döndürülen opak sayfalama belirteci (son sayfada yoktur, null değildir).
  • meta: chain, chain_slug, chain_external_id, as_of_block, safe_block, finalized_block, coverage (full veya partial) ve refreshed_at içeren meta veriler.

Kod örneği: Data API sorguları

export BLOCKVECTRA_API_KEY="rgw_your_api_key"

# 1. Query address transaction history (clamp=true prevents 409 errors)
curl -s "https://api.blockvectra.com/v1/data/hyperevm_mainnet/addresses/0x2222222222222222222222222222222222222222/transactions?from_block=0&to_block=50000&clamp=true" \
  -H "x-api-key: $BLOCKVECTRA_API_KEY"

# 2. Query address ERC-20 token transfers
curl -s "https://api.blockvectra.com/v1/data/hyperevm_mainnet/addresses/0x2222222222222222222222222222222222222222/transfers?standard=erc20&from_block=0&to_block=50000&clamp=true" \
  -H "x-api-key: $BLOCKVECTRA_API_KEY"

Gerçek zamanlı izleme: yeni blokları yoklama

Bir HTTP iletimi için, yoklama yaparak blokları izleyin ve max_logs_block_range dahilindeki ardışık parçalar halinde olay loglarını alın. Yalnızca /v1/chains ws=true ve gereken subscriptions girişini bildirdiğinde WebSocket seçin. Bir HTTPS alıcısına teslimat için webhook push kullanın.

Dağıtılan Hello sözleşmesini çalıştırmak için LOG_ADDRESS değerini onun adresine ayarlayın. Yayıncı RPC aracılığıyla ping() gönderin, ardından bu sayfadaki geriye dönük doldurma betiğiyle makbuzun bloğunu geriye dönük doldurun. Yeni olaylar için son tamamlanan parçadan devam edin.

cast send "$CONTRACT_ADDRESS" "ping()" --rpc-url "$DEPLOY_RPC_URL" \
  --private-key "$DEPLOYER_PRIVATE_KEY"

Yoklama akışı

  1. En son zincir tepesini incelemek için eth_blockNumber'a periyodik hafif çağrılar yapın.
  2. Döndürülen blok numarasını önceden işlenen lastSeenBlock ile karşılaştırın.
  3. currentBlock > lastSeenBlock ise, [lastSeenBlock + 1, currentBlock] aralığını en fazla max_logs_block_range boyutunda parçalara bölün. Her parçayı başarıyla işledikten sonra lastSeenBlock değerini kalıcı hale getirin; başarısızlık durumunda tamamlanmamış parçayı yeniden deneyin. (blockHash, transactionHash, logIndex) ile tekilleştirin ve yeniden düzenlemeleri mutabık kılmak için yeniden bağlandıktan sonra bir çakışmayı yeniden oynatın.
  4. viem'in watchBlockNumber veya watchBlocks işlevi, bir HTTP iletimi altında HTTP yoklamasını yerel olarak uygular ve pollingInterval parametresi (1000 ms gibi) aracılığıyla özelleştirmeye olanak tanır.

Sınırlı parçalar halinde olay loglarını yoklama

network.mjs ve viem-client.mjs yanına poll-logs.mjs olarak kaydedin. BLOCKVECTRA_API_KEY, LOG_ADDRESS ve FROM_BLOCK değerlerini ayarlayın, ardından node poll-logs.mjs komutunu çalıştırın. Bu sonlu örnek, tepeyi beş saniye arayla 12 kez örnekler ve sıralı parçalar halinde her yeni aralığı sorgular. Bir hata, başarısız parçayı ilerletmeden önce betiği durdurur.

import { isAddress } from 'viem';
import { client } from './viem-client.mjs';
import { chainInfo, allows } from './network.mjs';

const address = process.env.LOG_ADDRESS;
const start = process.env.FROM_BLOCK;
if (!address || !isAddress(address)) throw new Error('Set LOG_ADDRESS');
if (!/^(0x[0-9a-f]+|[0-9]+)$/i.test(start ?? '')) throw new Error('Set FROM_BLOCK');
if (!allows('eth_getLogs')) throw new Error('eth_getLogs requires an available keyed endpoint');
if (!Number.isSafeInteger(chainInfo.max_logs_block_range) || chainInfo.max_logs_block_range <= 0) {
  throw new Error('Invalid max_logs_block_range');
}
const max = BigInt(chainInfo.max_logs_block_range);
let from = BigInt(start);
for (let poll = 0; poll < 12; poll++) {
  const head = await client.getBlockNumber();
  while (from <= head) {
    const to = from + max - 1n < head ? from + max - 1n : head;
    const logs = await client.getLogs({ address, fromBlock: from, toBlock: to });
    console.log(JSON.stringify({ from: from.toString(), to: to.toString(), logs },
      (_, value) => typeof value === 'bigint' ? value.toString() : value));
    from = to + 1n;
  }
  if (poll < 11) await new Promise(resolve => setTimeout(resolve, 5_000));
}

Her çıktı tamamlanmış bir parçayı kaydeder. Devam etmek için FROM_BLOCK değerini onun to + 1 değerine ayarlayın; dayanıklı tüketiciler olayları ve imleci birlikte kaydetmeli, tekilleştirmeli ve yukarıda açıklandığı gibi yeniden düzenlemeleri uzlaştırmalıdır. 429 veya diğer yeniden denenebilir arızalar için, aynı tamamlanmamış parçaya sınırlı geri çekilme rehberliğini uygulayın.

İlgili rehberler

Sonraki adımlar

Son güncelleme:

Bu sayfada