Оракулы на TON

Оракулы — это «мосты» между блокчейном и реальным миром, поставляющие данные о ценах, погоде и других off-chain событиях. Без оракулов DeFi-протоколы не могут функционировать: DEX нужны цены для маржинальных позиций, лендинг-протоколам — для определения ликвидаций. На TON тема оракулов особенно актуальна из-за асинхронной модели, которая усложняет обеспечение актуальности данных.

Смарт-контракты на блокчейне живут в изолированном мире: они могут читать данные из блокчейна, но не могут обращаться к внешним источникам — биржевым ценам, погодным данным, курсам валют. Оракулы решают эту проблему, доставляя внешние данные в блокчейн. Без оракулов невозможны lending-протоколы (нужны цены для ликвидации), деривативы, страхование и большинство DeFi-приложений.

Модели архитектуры оракулов

Существуют два основных подхода к доставке данных в блокчейн:

Push-модель

Узлы оракула непрерывно публикуют обновлённые данные в смарт-контракт на блокчейне. Данные всегда доступны on-chain, но каждое обновление стоит газа — даже если никто в данный момент не запрашивает цену.

Pull-модель

Данные хранятся вне блокчейна (в децентрализованном кэше). Когда смарт-контракту нужна свежая цена, потребитель прикрепляет подписанные данные к своей транзакции. Контракт проверяет подпись и использует данные. Газ тратится только при реальном использовании.

Оракулы на TON преимущественно используют pull-модель — это эффективнее с точки зрения газа и хорошо подходит для асинхронной архитектуры TON.

RedStone на TON

RedStone стал первым оракулом, интегрированным с TON (2024). Его архитектура полностью основана на pull-модели.

Как работает RedStone

1. Data Sources (биржи, агрегаторы) передают цены узлам RedStone
2. Узлы подписывают данные криптографически и помещают их в децентрализованный кэш
3. dApp через SDK извлекает нужные данные из кэша
4. Пользователь прикрепляет подписанные данные к транзакции
5. Смарт-контракт проверяет подпись on-chain и использует данные

Типы контрактов RedStone

RedStone предоставляет несколько типов контрактов для разных сценариев:

Два режима работы

• On-the-fly processing — данные обрабатываются в момент вызова функции, не сохраняются в хранилище контракта. Минимальный расход газа, но данные доступны только в рамках текущей транзакции.
• Persistent storage — данные записываются в хранилище контракта для последующего чтения другими контрактами. Выше расход газа, но данные доступны между транзакциями.

Pyth Network на TON

Pyth Network — кроссчейн-оракул, работающий на множестве блокчейнов, включая TON. В отличие от RedStone, Pyth использует выделенный смарт-контракт на TON для хранения и обновления ценовых данных.

Архитектура Pyth

Система Price Feed IDs

Каждый актив в Pyth идентифицируется уникальным hex-идентификатором (Price Feed ID). Например, для TON/USD и BTC/USD существуют свои фиксированные идентификаторы, по которым протокол запрашивает цену конкретного актива.

Получение данных

Pyth предлагает два способа чтения цен:

1. Чтение кэшированных данных — контракт хранит последние обновлённые цены. Быстрый доступ, но данные могут быть не самыми свежими.
2. Запрос через Hermes — для получения максимально свежих данных dApp обращается к Hermes API, получает подписанное обновление, рассчитывает комиссию за обновление и отправляет транзакцию с новыми данными в контракт Pyth на TON.

Сравнение оракулов

Оба оракула используют pull-модель и обеспечивают достаточную свежесть данных для DeFi-приложений. Выбор между ними зависит от конкретных потребностей протокола: интеграционного SDK, поддерживаемых фидов и предпочтений по архитектуре.

Оракулы в DeFi-протоколах TON

Оракулы играют ключевую роль в работе DeFi-протоколов на TON:

Lending (EVAA)

Lending-протоколы, такие как EVAA, используют ценовые фиды оракулов для:

• Расчёта коэффициентов залога — определение стоимости обеспечения в долларах
• Триггеров ликвидации — если стоимость залога падает ниже порога, позиция ликвидируется
• Определения максимальной суммы займа — на основе текущих цен активов

DEX

Децентрализованные биржи могут использовать данные оракулов для:

• Референсных цен — сравнение текущей цены пула с рыночной
• Защиты от манипуляций — обнаружение аномальных отклонений от рыночных цен
• TWAP-оракулов — средневзвешенная по времени цена для уменьшения волатильности

Деривативы и синтетические активы

Протоколы синтетических активов полностью зависят от оракулов для определения цены базового актива, по которой происходят расчёты позиций.

Безопасность оракулов

Оракулы — критический компонент инфраструктуры, и их безопасность напрямую влияет на безопасность всех зависящих протоколов.

Основные риски

Рекомендации по безопасности

1. Проверка свежести — всегда проверяйте timestamp данных оракула и отклоняйте устаревшие обновления
2. Мульти-источниковая верификация — по возможности используйте данные от нескольких оракулов и сравнивайте значения
3. Circuit breakers — автоматическое приостановление операций при аномальных отклонениях цены
4. Ограничение ценового диапазона — отклонение обновлений, выходящих за разумные пределы

Ключевые выводы

1. Оракулы — мост между off-chain данными и смарт-контрактами; без них невозможны lending, деривативы и большинство DeFi-приложений
2. Оракулы на TON используют pull-модель — данные доставляются по запросу, а не публикуются непрерывно, что экономит газ
3. RedStone — первый оракул на TON, использует прикрепление подписанных данных к транзакциям с on-chain верификацией подписей
4. Pyth Network — кроссчейн-оракул с выделенным контрактом на TON; предлагает как кэшированные, так и свежие данные через Hermes API
5. Безопасность оракулов критична — проверяйте свежесть данных, используйте несколько источников и внедряйте circuit breakers
6. DeFi-протоколы (EVAA, DEX) зависят от оракулов для расчёта залогов, ликвидаций и референсных цен

Частые ошибки

1. Полагаются на единственный источник данных (один оракул) без fallback-механизма: если оракул выйдет из строя, весь протокол остановится.
2. Не проверяют freshness (свежесть) данных оракула: устаревшая цена может привести к некорректным ликвидациям или арбитражным атакам.
3. Используют цену из одного DEX-пула как оракул, что уязвимо к манипуляциям через flash-свопы.
4. Не учитывают задержку асинхронной доставки данных оракула: между запросом и получением ответа цена может значительно измениться.