totalSupply のスキャンによるリスト検出 (Totalsupply)

インデクサーがない場合、各更新はチェーン スキャンになります

Bare Crypto マーケットプレイス クライアントは、イベント インデックスやサブグラフではなく、totalSupply() + tokenId ループを使用して公開リストを検索します。 wasNftSold、isListingOpenByTokenId、getLastListingByTokenId などの追加の呼び出しが各ステップで行われます。供給が増えるとコストは直線的に増加しますが、実際にはさらに悪化します。予備コンテナはこれを約 30 秒ごとに繰り返します。```text 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

## 最初に説明した概念```text
📦 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.
```小規模な Rinkeby コレクションで実行されるループは、メインネット規模の製品機能ではありません。

## アルゴリズムの真実

`getListings` は、まず `getTokenSupply()` から `totalSupply` までを読み取り、次に `maxToken` から 1 まで下降します。トークンごとに、販売/オープン/上場チェックと、必要に応じて `getListingInfo` が行われます。空のトークン範囲でも RPC を書き込みます。```text
Cost model (approx)
  cost ≈ totalSupply × calls_per_token × polls_per_minute
  UI cards may add metadata/IPFS reads on top
```## 30 秒のポーリングと古い UI

予約コンテナーのマウントで `getListings` を実行し、`setInterval(..., 30000)` を繰り返します。プロフィールと同様に、所持品を 30 秒以内にスキャンします。ビューアとカードは 10 ～ 15 秒の間隔を使用します。ユーザーが購入を確認している間、グリッドは投票のために古いままになるか、レート制限により空のままになることがあります。

## Infura 障害モード

スキャン全体は読み取りノード (Rinkeby Infura HTTP/WSS) に送られます。クォータに達すると、部分的な try/catch パスは `wasSold=false` または空の文字列を返す場合があります。グリッドは静かに false になります。リポジトリにキーを埋め込むと、問題がさらに複雑になります。プロジェクト ID はドキュメントに決して書き込まれません。 env + ルート制限は ADR の一部です。```text
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 の違い

OpenSea クライアントは、各訪問者のブラウザからの供給全体をスキャンしません。インデックス+APIがあります。 Bare Crypto は、ディスカバリー インフラストラクチャではなく、IA の製品リファレンスをコピーします。これは意図的な (または少なくとも結果論的な) トレードオフです。

## このエピソードで最も混乱を招く対戦```text
❌ 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

独自のシステムのチェックリスト

1. getListings ラウンドのトークンあたりの eth_call は何回ですか?
2. 供給が 10 倍に増加した場合、投票あたりのコストはいくらになりますか?
3. レート制限が発生すると、UI はどのような空の状態または不正な状態になりますか?
4. 購入後、グリルは何秒間劣化したままになりますか?
5. どのイベントがインデックス付けされ、スキャンが排除されますか?

このセクションで覚えておくべきこと

1. リストの検出は totalSupply スキャンです。 OpenSea インデックスではありません。
2. N×RPC × 30 秒のポーリングにより、Infura クォータと古い UI が避けられなくなります。
3. ADR: プロトタイプの受け入れ、インデクサーの追跡 — サイレントにスケールしません。

マーケットプレイスではなく、各 tokenId を要求します。負荷テストです。