Оракулы на TON
Оракулы — это «мосты» между блокчейном и реальным миром, поставляющие данные о ценах, погоде и других off-chain событиях. Без оракулов DeFi-протоколы не могут функционировать: DEX нужны цены для маржинальных позиций, лендинг-протоколам — для определения ликвидаций. На TON тема оракулов особенно актуальна из-за асинхронной модели, которая усложняет обеспечение актуальности данных.
Смарт-контракты на блокчейне живут в изолированном мире: они могут читать данные из блокчейна, но не могут обращаться к внешним источникам — биржевым ценам, погодным данным, курсам валют. Оракулы решают эту проблему, доставляя внешние данные в блокчейн. Без оракулов невозможны lending-протоколы (нужны цены для ликвидации), деривативы, страхование и большинство DeFi-приложений.
Модели архитектуры оракулов
Существуют два основных подхода к доставке данных в блокчейн:
Push-модель
Узлы оракула непрерывно публикуют обновлённые данные в смарт-контракт на блокчейне. Данные всегда доступны on-chain, но каждое обновление стоит газа — даже если никто в данный момент не запрашивает цену.
Pull-модель
Данные хранятся вне блокчейна (в децентрализованном кэше). Когда смарт-контракту нужна свежая цена, потребитель прикрепляет подписанные данные к своей транзакции. Контракт проверяет подпись и использует данные. Газ тратится только при реальном использовании.
| Характеристика | Push-модель | Pull-модель |
|---|---|---|
| Расход газа | Высокий (постоянные обновления) | Низкий (только по запросу) |
| Свежесть данных | Всегда on-chain | On-demand (при использовании) |
| Задержка | Минимальная | Зависит от потребителя |
| Пример | Chainlink (Ethereum) | RedStone, Pyth (TON) |
Оракулы на TON преимущественно используют pull-модель — это эффективнее с точки зрения газа и хорошо подходит для асинхронной архитектуры TON.
RedStone на TON
RedStone стал первым оракулом, интегрированным с TON (2024). Его архитектура полностью основана на pull-модели.
Как работает RedStone
- Data Sources (биржи, агрегаторы) передают цены узлам RedStone
- Узлы подписывают данные криптографически и помещают их в децентрализованный кэш
- dApp через SDK извлекает нужные данные из кэша
- Пользователь прикрепляет подписанные данные к транзакции
- Смарт-контракт проверяет подпись on-chain и использует данные
Типы контрактов RedStone
RedStone предоставляет несколько типов контрактов для разных сценариев:
| Контракт | Назначение | Когда использовать |
|---|---|---|
| Price Manager | Управление множеством ценовых фидов | Протоколы с несколькими активами |
| Single Feed Manager | Оптимизированный контракт для одного фида | Максимальная газовая эффективность |
| Price Feed | Индивидуальный ценовой фид | Простая интеграция одного актива |
Два режима работы
- On-the-fly processing — данные обрабатываются в момент вызова функции, не сохраняются в хранилище контракта. Минимальный расход газа, но данные доступны только в рамках текущей транзакции.
- Persistent storage — данные записываются в хранилище контракта для последующего чтения другими контрактами. Выше расход газа, но данные доступны между транзакциями.
RedStone поддерживает основные криптоактивы — BTC, ETH, TON и другие. Для актуального списка поддерживаемых фидов обращайтесь к официальной документации RedStone.
Pyth Network на TON
Pyth Network — кроссчейн-оракул, работающий на множестве блокчейнов, включая TON. В отличие от RedStone, Pyth использует выделенный смарт-контракт на TON для хранения и обновления ценовых данных.
Архитектура Pyth
Система Price Feed IDs
Каждый актив в Pyth идентифицируется уникальным hex-идентификатором (Price Feed ID). Например, для TON/USD и BTC/USD существуют свои фиксированные идентификаторы, по которым протокол запрашивает цену конкретного актива.
Получение данных
Pyth предлагает два способа чтения цен:
- Чтение кэшированных данных — контракт хранит последние обновлённые цены. Быстрый доступ, но данные могут быть не самыми свежими.
- Запрос через Hermes — для получения максимально свежих данных dApp обращается к Hermes API, получает подписанное обновление, рассчитывает комиссию за обновление и отправляет транзакцию с новыми данными в контракт Pyth на TON.
При чтении кэшированных данных из контракта Pyth всегда проверяйте timestamp — данные могут быть устаревшими. Для критичных операций (ликвидации, крупные сделки) рекомендуется запрашивать свежее обновление через Hermes.
Сравнение оракулов
| Аспект | RedStone | Pyth |
|---|---|---|
| Модель | Pull (данные прикрепляются к вызову) | Pull (Hermes + on-chain контракт) |
| Свежесть | On-demand (при каждом вызове) | On-demand + кэш on-chain |
| Верификация | Криптографические подписи | Кроссчейн-аттестация |
| Интеграция | TypeScript SDK | Dedicated SDK |
| On-chain хранение | Опционально (два режима) | Да (контракт хранит последние цены) |
| Кроссчейн | Мультичейн поддержка | Нативный кроссчейн (Wormhole) |
Оба оракула используют pull-модель и обеспечивают достаточную свежесть данных для DeFi-приложений. Выбор между ними зависит от конкретных потребностей протокола: интеграционного SDK, поддерживаемых фидов и предпочтений по архитектуре.
Оракулы в DeFi-протоколах TON
Оракулы играют ключевую роль в работе DeFi-протоколов на TON:
Lending (EVAA)
Lending-протоколы, такие как EVAA, используют ценовые фиды оракулов для:
- Расчёта коэффициентов залога — определение стоимости обеспечения в долларах
- Триггеров ликвидации — если стоимость залога падает ниже порога, позиция ликвидируется
- Определения максимальной суммы займа — на основе текущих цен активов
Подробнее о том, как EVAA использует ценовые данные для работы lending-протокола, читайте в уроке о lending и EVAA (M06-L03).
DEX
Децентрализованные биржи могут использовать данные оракулов для:
- Референсных цен — сравнение текущей цены пула с рыночной
- Защиты от манипуляций — обнаружение аномальных отклонений от рыночных цен
- TWAP-оракулов — средневзвешенная по времени цена для уменьшения волатильности
Деривативы и синтетические активы
Протоколы синтетических активов полностью зависят от оракулов для определения цены базового актива, по которой происходят расчёты позиций.
Общий обзор DeFi-архитектуры и роли оракулов в экосистеме описан в уроке DeFi overview (M06-L01). Связь оракулов с кроссчейн-мостами рассматривается в уроке о мостах (M11-L04).
Безопасность оракулов
Оракулы — критический компонент инфраструктуры, и их безопасность напрямую влияет на безопасность всех зависящих протоколов.
Основные риски
| Риск | Описание | Защита |
|---|---|---|
| Манипуляция данными | Злоумышленник подаёт ложные цены | Мульти-источниковая верификация, медианные цены |
| Устаревание данных | Контракт использует старую цену | Проверка timestamp, максимальный возраст данных |
| Single point of failure | Один оракул-провайдер выходит из строя | Использование нескольких оракулов |
| Flash loan атаки | Манипуляция ценой через мгновенные займы | TWAP вместо spot-цен, circuit breakers |
Рекомендации по безопасности
- Проверка свежести — всегда проверяйте timestamp данных оракула и отклоняйте устаревшие обновления
- Мульти-источниковая верификация — по возможности используйте данные от нескольких оракулов и сравнивайте значения
- Circuit breakers — автоматическое приостановление операций при аномальных отклонениях цены
- Ограничение ценового диапазона — отклонение обновлений, выходящих за разумные пределы
Безопасность оракулов — одна из самых частых причин эксплойтов в DeFi. Даже надёжный оракул может быть скомпрометирован через манипуляцию источниками данных или задержку обновлений. Всегда закладывайте защитные механизмы в архитектуру протокола.
Ключевые выводы
- Оракулы — мост между off-chain данными и смарт-контрактами; без них невозможны lending, деривативы и большинство DeFi-приложений
- Оракулы на TON используют pull-модель — данные доставляются по запросу, а не публикуются непрерывно, что экономит газ
- RedStone — первый оракул на TON, использует прикрепление подписанных данных к транзакциям с on-chain верификацией подписей
- Pyth Network — кроссчейн-оракул с выделенным контрактом на TON; предлагает как кэшированные, так и свежие данные через Hermes API
- Безопасность оракулов критична — проверяйте свежесть данных, используйте несколько источников и внедряйте circuit breakers
- DeFi-протоколы (EVAA, DEX) зависят от оракулов для расчёта залогов, ликвидаций и референсных цен
Частые ошибки
- Полагаются на единственный источник данных (один оракул) без fallback-механизма: если оракул выйдет из строя, весь протокол остановится.
- Не проверяют freshness (свежесть) данных оракула: устаревшая цена может привести к некорректным ликвидациям или арбитражным атакам.
- Используют цену из одного DEX-пула как оракул, что уязвимо к манипуляциям через flash-свопы.
- Не учитывают задержку асинхронной доставки данных оракула: между запросом и получением ответа цена может значительно измениться.