Розробка інструменту оцінки рарити NFT
Коли користувач дивиться на свій токен з колекції з 10 000 штук, перше питання — наскільки він рідкий. "Рідкий" здається очевидним поняттям, але за ним стоїть нетривіальна математика: різні алгоритми розрахунку дають різні рейтинги для одного й того ж токена, і вибір методології прямо впливає на сприйняту вартість.
Методології розрахунку рарити
Trait Rarity Score — базовий та найпоширеніший підхід. Для кожного атрибуту токена беремо його рідкість: 1 / (кількість_токенів_з_цим_ознакою / загальна_пропозиція). Підсумковий score це сума по всім ознакам. Проблема: колекції з різною кількістю ознак несумісні, а токени з великою кількістю ознак отримують перевагу просто за їх кількість.
Statistical Rarity — добуток ймовірностей ознак. Токен рідкий тільки якщо всі його ознаки рідкі одночасно. Це інтуїтивно чесніше, але математично придушує токени з однією екстремально рідкою ознакою.
Jaccard Distance / Information Content — більш академічні підходи, використовувані в інструментах типу Rarity Sniper та трекерах на базі rarity.tools. Information Content обчислює −log2(p) для кожної ознаки, що дає більш збалансований розподіл без вибухового зростання score для унікальних ознак.
Trait Normalization — корекція на середню кількість ознак у колекції. Якщо середній токен має 5 атрибутів, а конкретний — 8, його score ділиться на поправочний коефіцієнт. Реалізовано в OpenRarity — відкритому стандарті, який зараз активно просуває OpenSea.
Для серйозного інструменту має сенс показувати кілька методологій паралельно — користувач сам вибирає, яку вважати авторитетною.
Джерела даних та індексування
Метаданні NFT-колекцій зберігаються або в IPFS (CID колекції), або на централізованих серверах (через tokenURI). Для розрахунку рарити потрібно завантажити та спарсити метаданні всієї колекції.
Стратегія збору даних:
- Читаємо
contractURIабоtokenURI(0..n)з контракту через batch RPC calls (eth_call multicall через Multicall3) - Для IPFS — резолвимо gateway (Cloudflare IPFS, Pinata, або власний IPFS-нод) та завантажуємо JSON батчами
- Обробляємо edge-cases: токени з
nullознаками (вважаються як окремий атрибут "None"), ознаки з числовими значеннями (потребують біннінгу або окремої обробки), оновлення метаданих після reveal
Індекс будуємо в PostgreSQL або Redis: таблиця token_traits(collection_id, token_id, trait_type, trait_value) + агрегати по кожній ознаці. Перерахунок рарити після оновлення метаданих — інкрементальний.
Реалізація та API
Бекенд-сервіс на Node.js/Go приймає адресу контракту, визначає цепочку (через chainId), завантажує та індексує колекцію, обчислює scores за обраними методологіями. Результат — ендпоінт /rarity/{contract}/{tokenId} з повним breakdown по ознакам.
Фронтенд відображає:
| Атрибут | Значення | Зустрічається | Rarity score |
|---|---|---|---|
| Background | Cosmic Purple | 3.2% | 31.25 |
| Eyes | Laser | 0.8% | 125.0 |
| Mouth | Gold Grill | 1.5% | 66.67 |
Плюс загальний ранг токена в колекції та перцентиль рідкості.
Важлива деталь: кешуємо результати агресивно. Метаданні колекції після reveal не змінюються — TTL можна ставити дуже великим. Перший розрахунок колекції на 10k токенів займає секунди, повторні запити — мілісекунди.
Інтеграція з маркетплейсами
Якщо інструмент вбудовується в уже існуючий маркетплейс або NFT-дашборд, рарити-score передається як атрибут при відображенні токена. OpenRarity надає npm-пакет @openrarity/rarity-scorer для клієнтської інтеграції без власного бекенду — підходить для невеликих колекцій, які повністю помістяться в пам'ять браузера.