कुल आपूर्ति को स्कैन करके खोज को सूचीबद्ध करना (Listing Discovery By Scanning Total Supply)

यदि कोई इंडेक्सर नहीं है, तो प्रत्येक रिफ्रेश एक चेन स्कैन है

बेयर क्रिप्टो मार्केटप्लेस क्लाइंट को totalSupply() + टोकनआईडी लूप के साथ खुली लिस्टिंग मिलती है, किसी इवेंट इंडेक्स या सबग्राफ के साथ नहीं। प्रत्येक चरण पर अतिरिक्त कॉल की जाती हैं, जैसे 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.
```छोटे रिंकीबी संग्रह पर चलने वाला लूप मेननेट पैमाने पर उत्पाद सुविधा नहीं है।

## एल्गोरिथम सत्य

`getListings` पहले `getTokenSupply()` को `totalSupply` तक पढ़ता है, फिर `maxToken` से 1 तक उतरता है। प्रत्येक टोकन के लिए बेचे गए/खुले/लिस्टिंग चेक होते हैं और यदि आवश्यक हो तो `getListingInfo` होते हैं। यहां तक ​​कि खाली टोकन श्रेणियां भी आरपीसी को जला देती हैं।```text
Cost model (approx)
  cost ≈ totalSupply × calls_per_token × polls_per_minute
  UI cards may add metadata/IPFS reads on top
```## 30 सेकंड का पोल और पुराना यूआई

रिजर्व कंटेनर माउंट पर `getListings` चलता है और `setInterval(..., 30000)` के माध्यम से पुनरावृत्त होता है। प्रोफ़ाइल के समान, यह ~30 के दशक में संपत्तियों को स्कैन करता है; दर्शक और कार्ड 10-15 के अंतराल का उपयोग करते हैं। जब उपयोगकर्ता खरीदारी देखता है, तो पोल के लिए ग्रिड पुराना रह सकता है - या दर-सीमा के कारण खाली रह सकता है।

## इन्फ्रा विफलता मोड

संपूर्ण स्कैन रीड नोड (रिंकबी इन्फुरा HTTP/WSS) पर जाता है। जब कोटा पूरा हो जाता है, तो आंशिक प्रयास/पकड़ पथ `wasSold=false` या खाली स्ट्रिंग लौटा सकते हैं; ग्रिड चुपचाप झूठा हो जाता है. रेपो में कुंजियाँ दफनाने से समस्या बढ़ जाती है - दस्तावेज़ में प्रोजेक्ट आईडी कभी नहीं लिखी जाती है; 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 क्लाइंट प्रत्येक विज़िटर के ब्राउज़र से संपूर्ण आपूर्ति को स्कैन नहीं करता है; इंडेक्स + एपीआई है। बेअर क्रिप्टो आईए में उत्पाद संदर्भ की प्रतिलिपि बनाता है, खोज बुनियादी ढांचे की नहीं - यह एक जानबूझकर (या कम से कम पूर्वदृष्टिकोण) व्यापार-बंद है।

## इस एपिसोड में सबसे भ्रमित करने वाला मैचअप```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_calls?
2. जब आपूर्ति 10× बढ़ जाती है तो प्रति मतदान लागत क्या होगी?
3. दर-सीमा होने पर यूआई किस खाली/गलत स्थिति में आता है?
4. खरीद के बाद ग्रिल कितने सेकंड तक बासी रह सकती है?
5. कौन सी घटनाओं को अनुक्रमित किया गया है और स्कैनिंग समाप्त कर दी गई है?

इस अनुभाग से याद रखने योग्य बातें

1. लिस्टिंग खोज कुल आपूर्ति स्कैन है; यह OpenSea सूचकांक नहीं है.
2. N×RPC × 30s पोल इन्फ्यूरा कोटा और पुराने UI को अपरिहार्य बनाता है।
3. एडीआर: प्रोटोटाइप स्वीकृति, इंडेक्सर ट्रैकिंग - चुपचाप स्केल नहीं करता है।

प्रत्येक टोकनआईडी के लिए पूछना, बाज़ार के लिए नहीं; यह एक लोड टेस्ट है.