totalSupply Tarayarak Listing Keşfi (Listing Kesfi Totalsupply Tarayarak)

Indexer yoksa her yenileme bir zincir taramasıdır

Bare Crypto marketplace istemcisi açık listing'leri bir olay indeksi veya subgraph ile değil, totalSupply() + tokenId döngüsüyle bulur. Her adımda wasNftSold, isListingOpenByTokenId ve getLastListingByTokenId gibi ek çağrılar yapılır. Supply büyüdükçe maliyet doğrusal — aslında daha kötü — büyür; Reserve container bunu ~30 saniyede bir tekrarlar.

getListings(sold=false)
  maxToken ← NFT.totalSupply()
  for tokenId = maxToken … 1:
    wasSold?  open?  isListing?
    → maybe getListingInfo(tokenId)
         ↓
  N tokens × M RPC calls / poll
  poll every ~30s (Reserve / Profile)
         ↓
  Infura rate-limit → empty / stale grid

Bu bölüm, OpenSea-benzeri ızgaranın arkasındaki keşif algoritmasını ve neden bir ADR konusu olduğunu keser.

Kavramlar ilk geçtiği yerde

📦 totalSupply Taraması
Listing kümesini, arz üst sınırından geriye tokenId döngüsüyle keşfetmek.

📦 N×RPC
Her token için birden fazla eth_call; poll ile çarpılınca kota tüketimi.

📦 Stale Listing
Satılmış veya iptal edilmiş ilanın UI'da hâlâ açık görünmesi; poll gecikmesi veya kısmi hata.

📦 Infura Rate Limit
Projeye bağlı istek kotası; aşılınca çağrılar başarısız olur veya yavaşlar.

Küçük Rinkeby koleksiyonunda çalışan döngü, mainnet ölçeğinde ürün özelliği değildir.

Algoritma gerçeği

getListings önce getTokenSupply() ile totalSupply okur, sonra maxToken'dan 1'e iner. Her token için sold/open/listing kontrolleri ve gerekirse getListingInfo gelir. Boş token aralıkları bile RPC yakar.

Cost model (approx)
  cost ≈ totalSupply × calls_per_token × polls_per_minute
  UI cards may add metadata/IPFS reads on top

30 saniyelik poll ve stale UI

Reserve container mount'ta getListings çalıştırır ve setInterval(..., 30000) ile yineler. Profile benzer şekilde sahip olunanları ~30s'de tarar; Viewer ve kartlar 10–15s aralıklar kullanır. Kullanıcı bir satın alma görürken ızgara bir poll boyunca eski kalabilir — veya rate-limit yüzünden boşalabilir.

Infura başarısızlık modu

Tüm tarama okuma düğümüne (Rinkeby Infura HTTP/WSS) gider. Kota dolunca kısmi try/catch yolları wasSold=false veya boş string döndürebilir; ızgara sessizce yanlışlaşır. Anahtarları repoya gömmek sorunu büyütür — dokümantasyonda proje kimliği asla yazılmaz; env + rota sınırlaması ADR'nin parçasıdır.

ADR: Listing discovery
  Accepted (prototype): scan totalSupply client-side
  Rejected (then): subgraph / event indexer
  Consequence: rate limits, stale polls, O(supply) cost
  Follow-up: index Transfer/Listing events; paginate

OpenSea farkı

OpenSea istemcisi her ziyaretçinin tarayıcısından tüm arzı taramaz; indeks + API vardır. Bare Crypto ürün referansını IA'da kopyalar, keşif altyapısını kopyalamaz — bu bilinçli (veya en azından sonradan görülen) trade-off'tur.

Bu bölümde en çok karışan eşleştirmeler

❌ totalSupply taraması = üretim keşif stratejisi
✓ Prototip; indexer yokluğunun semptomu

❌ 30s poll gerçek zamanlı piyasadır
✓ Poll, stale listing ve kota riskidir

❌ try/catch ile yutulan RPC hatası = güvenli UI
✓ Sessiz yanlış listing daha tehlikelidir

❌ Infura anahtarını client bundle'a gömmek pratiktir
✓ Sızıntı + ortak kota; env ve proxy düşünün

Kendi sisteminizi denetleme listesi

1. Bir getListings turunda token başına kaç eth_call var?
2. Supply 10× artınca poll başına maliyet ne olur?
3. Rate-limit olduğunda UI hangi boş/yanlış duruma düşüyor?
4. Satın alma sonrası ızgara en fazla kaç saniye stale kalabilir?
5. Hangi olaylar indekslense tarama kalkar?

Bu bölümden aklında kalması gerekenler

1. Listing keşfi totalSupply taramasıdır; OpenSea indeksi değildir.
2. N×RPC × 30s poll Infura kotasını ve stale UI'yı kaçınılmaz kılar.
3. ADR: prototip kabul, indexer takip — sessizce ölçeklenmez.

Her tokenId için sormak, pazar yeri değil; yük testidir.