Разработка платформы аналитики NFT

Разработка платформы аналитики NFT

NFT-аналитика сложнее DeFi-аналитики в одном конкретном аспекте: у каждого токена уникальная цена. В DeFi пул Uniswap даёт тебе чёткий price feed. В NFT тебе нужно оценить актив, у которого последняя продажа была три месяца назад, а floor — это floor всей коллекции, а не этого конкретного токена с редким трейтом. Построить корректную модель оценки — половина работы.

Источники данных и их ограничения

On-chain события

Базовые события, которые нужно индексировать:

• Transfer(address from, address to, uint256 tokenId) — для ERC-721
• TransferSingle / TransferBatch — для ERC-1155
• OrderFulfilled (Seaport 1.5) — продажи через OpenSea
• TakerBid / TakerAsk — LooksRare v2
• EvProfit — Blur

Проблема: у каждого маркетплейса свои события со своей структурой. Seaport — самый сложный, там одно событие OrderFulfilled может кодировать bundle-продажу нескольких NFT за одну транзакцию с произвольными ERC-20. Разбор этих данных требует полного декодирования consideration и offer arrays по ABI.

The Graph vs self-hosted индексирование

The Graph — очевидный выбор для начала. Существующие субграфы: OpenSea (unofficial), NFT sales aggregator subgraphs на hosted service. Ограничения: hosted service закрывается в пользу decentralized network, где query стоят GRT. Для высоконагруженной аналитики стоимость запросов становится значимой.

Self-hosted через Ponder или Envio — Ponder (TypeScript-фреймворк для on-chain indexing) позволяет писать обработчики событий как обычный TypeScript, хранит данные в PostgreSQL. Envio — аналог с фокусом на скорость (написан на OCaml/Rust). Для платформы с кастомными метриками self-hosted индексер предпочтительнее: полный контроль над схемой данных.

Дуальный подход: исторические данные — из Dune Analytics или Reservoir API (агрегирует продажи со всех маркетплейсов), real-time — через WebSocket подписку на события через Alchemy или QuickNode.

Модели оценки и метрики

Rarity scoring

Стандартная формула — statistical rarity:

rarity_score(token) = Σ (1 / trait_frequency) для всех трейтов

Это то, что делает rarity.tools. Проблема: не учитывает корреляцию между трейтами. Токен с редкой комбинацией двух common трейтов может быть редче, чем показывает простая формула.

Улучшенный подход — information content rarity (IC score):

IC(trait) = -log2(P(trait))
rarity_score = Σ IC(trait_i)

Работает корректнее при неравномерных распределениях.

Ценовые метрики

Wash trade detection

Одна из ключевых фич аналитической платформы. Паттерны для детекции:

• Одни и те же адреса покупают и продают между собой (граф транзакций с циклами)
• Продажи через 1–3 блока после покупки по нерыночной цене
• Финансирование покупателя из того же источника, что и продавец (Tornado Cash / mixer, или прямой перевод)
• Повторные паттерны: A→B→A→B с повышением цены

Реализуется через граф-анализ на адресах — Neo4j или встроенный граф в DuckDB достаточно эффективны. Для on-chain heuristics используют from/to в событиях Transfer + анализ funding source через трассировку транзакций (trace_transaction в Geth/Erigon).

Технический стек платформы

Инфраструктура индексирования

Ethereum node (Erigon) 
  → Ponder indexer (TypeScript)
  → PostgreSQL (TimescaleDB extension для time-series)
  → Redis (кэш floor prices, trending collections)
  → ClickHouse (аналитические агрегаты, OLAP-запросы)

TimescaleDB критична для метрик с временными рядами: continuous aggregates позволяют считать hourly/daily OHLCV без полного пересчёта при каждом запросе. ClickHouse оправдан при объёмах > 100M событий — аналитические запросы на нём в 10–100x быстрее PostgreSQL.

API слой

GraphQL через Hasura поверх PostgreSQL — для большинства запросов достаточно. Кастомные resolver'ы через Hasura Actions для сложных вычислений (rarity score, wash trade score).

Для real-time данных — WebSocket через Hasura subscriptions или кастомный сервер на Node.js с pub/sub через Redis Streams.

Enrichment pipeline

NFT метаданные не всегда on-chain. Нужен pipeline:

1. Из tokenURI() контракта достаём URL (IPFS CID или HTTP)
2. Fetch метаданных с IPFS gateway / HTTP
3. Парсинг attributes array
4. Хранение в PostgreSQL с вычисленным rarity score
5. Обновление при обнаружении новых токенов (Transfer из zero address)

Проблема: IPFS fetch ненадёжен. Нужны retry с exponential backoff, fallback на несколько gateway (Cloudflare, dweb.link, nftstorage.link), и таймаут на уровне 5–10 секунд.

Frontend

Next.js 14 с App Router. Ключевые страницы:

• Collection overview: floor chart (Recharts/TradingView lightweight), volume bars, holder distribution pie
• Token detail: rarity rank, trait comparison, price history, similar sales
• Wallet analytics: portfolio valuation, P&L по коллекциям, unrealized gains
• Market trends: trending by volume/floor change, new mints heatmap

Для чартов с большим объёмом данных — TradingView Lightweight Charts (WebGL-рендеринг) быстрее Recharts на 10k+ точках.

Что сложно и долго

Историческая синхронизация — проиндексировать все NFT-транзакции с 2017 года по сегодня занимает несколько недель даже на быстрой ноде. Используют снапшоты от Dune/Reservoir для бутстрапа, затем догоняют live данными.

Multi-chain — поддержка Ethereum + Polygon + Base + Solana требует 4 разных индексера с разными ABI и структурами событий. Solana особенно болезненна: там нет EVM, события — это program logs в base64.

Accurate pricing — агрегировать продажи правильно трудно. Нужно учитывать currency (ETH, WETH, USDC, BLUR токен), конвертировать в USD по историческому курсу на момент продажи, исключать wash trades. Каждый шаг добавляет вероятность ошибки.

Реалистичный срок для MVP (одна сеть, основные метрики, базовый UI): 6–8 недель. Полная мультичейн платформа с wash trade detection и portfolio analytics: 3–4 месяца.