Pyth Network — это децентрализованный оракул рыночных цен, который агрегирует котировки напрямую от первичных поставщиков (криптобиржи, маркет-мейкеры, институциональные торговые фирмы) и распространяет их в десятки сетей. Ключевая особенность — on-demand (pull)-модель обновлений: конечное приложение само инициирует доставку свежего значения в свою сеть и платит комиссию за обновление. Для пользователей Solana это даёт низкую задержку и предсказуемость, а для мультичейн-dApp — унифицированный доступ к тем же потокам цен.
Бэкграунд по сети см. Архитектура Solana: Объяснение Высокой Производительности, PoH, Sealevel, параллельное исполнение — Sealevel (Solana): параллельное исполнение, рантайм и планировщик, модель аккаунтов — Solana: модель аккаунтов — PDAs, read/write-локи, rent-exempt, ALTs, сетевой транспорт — Solana QUIC: транспорт транзакций, приоритет и устойчивость к спаму, конвейер лидера — Solana TPU: конвейер приёма и исполнения транзакций — от QUIC до финализации.
Pyth Network — ценовой оракул «первичных» данных (first-party)
- First-party: публикации делают сами источники рынка — биржи и маркет-мейкеры.
- On-demand обновления (pull): контракт потребителя «подтягивает» последнее значение тогда, когда это нужно протоколу.
- Price + Confidence: фиды отдают не только цену, но и доверительный интервал (confidence), полезный для контроля риска.
- Мультичейн-доставка: единый канал публикаций и кросс-чейн аттестации; в Solana интеграция нативна, смежные темы — Local Fee Market (Solana): локальные рынки комиссий и priority fees и Priority Fee (Solana): приоритетная комиссия за compute units (CU) и «чаевые» валидатору.
Чем Pyth отличается от классических оракулов
| Аспект | Классическая push-модель | Pyth (pull / first-party) |
|---|---|---|
| Кто публикует | Ноды-агрегаторы | Первичные источники + агрегатор |
| Когда обновлять | По расписанию/порогам сети оракула | По запросу dApp (когда нужно протоколу) |
| Что отдают | Цена (часто без ширины спрэда) | Цена + confidence (ширина интервала неопределённости) |
| Стоимость обновления | «Распределённо» по донаторам газа/операторам | Платит тот, кто инициирует апдейт (пользователь/протокол) |
| Латентность | Зависит от расписания | Ниже при высокочастотных рынках (обновляете по требованию) |
Идея «pull»: не держать в каждой сети постоянно горячий и дорогой поток апдейтов, а приносить свежее значение ровно тогда, когда протокол проводит критичную операцию (ликвидация, обмен, коллатерализация).
Архитектура (высокоуровнево)
- Паблишеры (поставщики данных). Биржи и маркет-мейкеры подписывают свои котировки и публикуют в общий слой агрегации.
- Агрегатор. Из множества подписанных апдейтов собирается консенсусная цена и confidence (индикатор разброса/доверия).
- Кросс-чейн доставка. Последнее агрегированное значение и «доказательство» его корректности доставляется в целевые сети (в Solana — нативно, в других сетях — через аттестации).
- Контракт-консьюмер. Протокол (лендинг, DEX, деривативы) вызывает метод «update price» для конкретного фида и получает актуальную цену в своём состоянии.
На стороне Solana обновления хорошо вписываются в конвейер Solana TPU: конвейер приёма и исполнения транзакций — от QUIC до финализации; доставка и дозирование трафика обеспечивает Solana QUIC: транспорт транзакций, приоритет и устойчивость к спаму.
Price + Confidence: зачем два числа
Pyth, помимо «средней» цены, отдаёт confidence — ширину доверительного интервала (условно, оценка «шумности» рынка в момент апдейта). Типичные практики:
- Порог относительной ширины. Протоколы часто проверяют confidence/price ≤ k перед использованием цены (например, при ликвидации).
- Защитные рейлы. Если confidence широк, можно fallback-нуть на TWAP/последнюю стабильную точку или увеличить приоритет комиссии для ускорения включения (см. Priority Fee (Solana): приоритетная комиссия за compute units (CU) и «чаевые» валидатору).
- Склейка с лимитами протокола. Для редких рынков с низкой ликвидностью допускается больший confidence/price.
Итог: вы получаете не «голую» среднюю, а цену с мерой достоверности — это важно для устойчивости ликвидаций и защиты пользователей.
On-demand (pull)-обновления: как это выглядит в коде протокола
- В «горячих» путях (ликвидации, крупные свопы) контракт сначала вызывает «доставку свежей цены» для нужного ассета.
- После апдейта читает из локального хранилища price + confidence и принимает решение (разрешить операцию/отклонить/снизить лимит).
- В «холодных» путях (учёт, справочные расчёты) протокол может принимать слегка устаревшие значения, проверяя, что они в пределах допустимого «staleness».
Поскольку конкуренция в Solana формируется локально вокруг «горячих» аккаунтов, этот паттерн не «раздувает» комиссии сети целиком (см. Local Fee Market (Solana): локальные рынки комиссий и priority fees).
Основные сценарии применения
- Лендинги. Оценка стоимости коллатераля и маржинальных позиций, триггеры ликвидаций, лимиты LTV.
- Деривативы и перп-DEX. Маркировочные цены, клиринг, триггеры funding-платежей.
- Спотовые DEX/агрегаторы. Квоты, лимиты отклонения, маршрутизация между пулами.
- Стейблкоины/токенизированные активы. Нормализация корзин/NAV, стейбл-котировки к различным валютам.
Дизайн интеграции: рекомендации разработчикам
- Не игнорируйте confidence. Введите пороги по активам и ветвления логики (вплоть до паузы).
- Контролируйте «staleness». Всегда проверяйте, насколько старо значение; фиксируйте допустимый горизонт.
- Минимизируйте write-конфликты. Разносите хранение цен по аккаунтам так, чтобы операции разных рынков не писали в один и тот же объект (см. Sealevel (Solana): параллельное исполнение, рантайм и планировщик и Solana: модель аккаунтов — PDAs, read/write-локи, rent-exempt, ALTs).
- Планируйте приоритет. В «очагах» конкуренции используйте аккуратную доплату (Priority Fee (Solana): приоритетная комиссия за compute units (CU) и «чаевые» валидатору); вне очагов повышать приоритет бессмысленно.
- Fallback-стратегии. TWAP, последняя стабильная точка, «circuit-breaker» при ненормальной ширине confidence.
Надёжность и доверие
- Первичные подписи. Поставщики публикуют цены от своего имени; агрегатор учитывает вклад множества источников.
- Кворум и устойчивость к выбросам. Консенсусный агрегат сглаживает единичные аномалии.
- Кросс-чейн аттестации. На целевых сетях контракт проверяет корректность «доказательства», прежде чем принять обновление.
- Наблюдаемость. Протоколы должны логировать время получения апдейта, ширину confidence и «степень устаревания» — полезно для пост-мортемов.
Производительность в Solana
- Ingress по QUIC. Стабильная доставка апдейтов и вызовов обновлений (см. Solana QUIC: транспорт транзакций, приоритет и устойчивость к спаму).
- Параллельные партии. Разные рынки (аккаунты цен) исполняются одновременно, если не пересекаются по записи — выигрываем латентность (Sealevel (Solana): параллельное исполнение, рантайм и планировщик).
- Локальные рынки. Если один и тот же аккаунт цены становится «горячим» (массовые апдейты), образуется локальная очередь — её можно обойти шардированием хранилища и планированием апдейтов (Local Fee Market (Solana): локальные рынки комиссий и priority fees).
Риски и анти-паттерны
- Игнорирование confidence. Самая распространённая ошибка, ведущая к «грязным» ликвидациям.
- Чтение без обновления. Использование стейла в критичных путях — причина арбитража/ущерба.
- Единый «центральный» аккаунт. Пишете все цены в один объект — получите блокировки и хвосты p95/p99.
- Шторм ретраев. Спам «доставками» повышает долю дропов на ingress и не ускоряет включение — делайте 1–3 аккуратных ретрая по слотам.
- Непродуманные лимиты. Жёсткие стоп-правила без TWAP/фоллбэка могут «замораживать» протокол при любой турбулентности.
Метрики для мониторинга
| Метрика | Почему важна | Как реагировать |
|---|---|---|
| Время с последнего апдейта (staleness) | Старые цены = риск неправильных решений | Повышать частоту on-demand обновлений в горячие часы |
| Отн. ширина confidence | Индикатор «качества» цены | Пороговые алерты, включение защитных рейл-правил |
| p95/p99 времени включения апдейта | UX/надёжность критичных операций | Планировать приоритет в очагах, уменьшать write-конфликты |
| Доля неудачных апдейтов | Проблемы ingress/дубликаты/лимиты CU | Снизить шторм, оптимизировать инструкции и аккаунты |
| Расходы на апдейты | Юнит-экономика интеграции | Бандлинг апдейтов, кэширование, «холодные» пути без доставки |
Сравнение подходов: когда Pyth удобнее, а когда — нет
- Удобнее, когда важна низкая задержка в момент операции и вы готовы платить за апдейт ровно там, где он нужен (ликвидации, крупные свопы).
- Сложнее, если вам нужен постоянный поток цен в сети без участия контракта-потребителя (тогда придётся строить сервис-обновлятор/кипер).
- Нужно планирование, если рынок «тонкий»: ширина confidence может быть высокой — заложите рейлы/пороги и fallback.
FAQ
Нужно ли обновлять цену перед каждой операцией? Только там, где критичность высока (ликвидации, клиринг, крупные свопы). Для справочных расчётов достаточно свежести в заданном окне.
Почему в оракуле есть confidence, а не только цена? Чтобы автоматически учитывать качество/достоверность котировки в моменте и защищать пользователей в турбулентности.
Поднимет ли приоритет комиссия ускорение в любой ситуации? Нет. Priority Fee (Solana): приоритетная комиссия за compute units (CU) и «чаевые» валидатору помогает только в локальном очаге конкуренции; вне его переплата бессмысленна (см. Local Fee Market (Solana): локальные рынки комиссий и priority fees).
Можно ли хранить все цены в одном аккаунте «для простоты»? Технически — да, но вы потеряете параллелизм и упрётесь в локальные очереди. Разносите состояние (см. Sealevel (Solana): параллельное исполнение, рантайм и планировщик).
Мини-глоссарий
- First-party oracle — оракул, где источники данных публикуют котировки напрямую.
- Pull (on-demand) обновления — модель, при которой потребитель сам инициирует доставку цены в сеть.
- Confidence — доверительный интервал/ширина неопределённости цены.
- Staleness — давность последнего апдейта в локальном состоянии протокола.