Как ценовые оракулы DeFi агрегируют и публикуют данные

Оракул связывает информацию вне блокчейна с кодом, который выполняется в сети. Кредитный протокол может считывать feed для оценки залога, а контракт дериватива — использовать ориентир для расчетов или ограничения риска. Контракт видит значение в состоянии сети, но сам не анализирует все внешние книги заявок и не выбирает справедливую цену.

Под «ценой» может подразумеваться пара актива и валюты котировки, заданный протоколом курс погашения или другой показатель. Это не обязательно цена продажи крупной позиции. См. руководство по влиянию цены и проскальзыванию в DEX-свопах и сравнение mark price с последней сделкой. Здесь речь о распространенных EVM push-feeds, а не о едином правиле для DeFi.

В Offchain Reporting от Chainlink узлы oracle обмениваются наблюдениями вне сети и согласуют отчет. Кворум подписывает его, передатчик отправляет транзакцию, а агрегатор проверяет подписи и публикует ответ, идентификатор раунда и временную метку. Документация Offchain Reporting описывает публикацию медианы наблюдений в этой архитектуре.

Контракт-потребитель обычно не повторяет всю агрегацию, а вызывает latestRoundData() по адресу proxy feed. Агрегатор за proxy может измениться. Сверьте нужную сеть и feed в руководстве по EVM и справочнике API. Много узлов не означает независимые источники: они могут использовать одни и те же биржи или провайдеров.

Многие push-feeds совмещают порог отклонения и heartbeat. Заданное процентное изменение относительно последнего опубликованного ответа может вызвать новый отчет; heartbeat может запросить обновление по истечении времени и без крупного движения. Актуальный каталог Data Feeds и страница адресов feed показывают параметры для конкретного актива, сети и feed.

Это условия конкретного feed, а не универсальное обещание обновления каждые N секунд. Малое изменение может не достичь порога, а запрошенный отчет еще нужно собрать, передать и включить в блок. Поэтому heartbeat не гарантирует точное время доставки и не исключает устаревшие данные. Протоколу нужна собственная максимальная давность, подходящая активу и применению.

latestRoundData() возвращает ID раунда, answer, startedAt, updatedAt и answeredInRound; справочник API помечает последнее поле как устаревшее. answer — целое число с фиксированной точкой, а не обязательно читаемая сумма в долларах. Проверьте decimals() и описание нужного feed. Если условный BTC/USD feed с 8 decimals возвращает 6,725,000,000,000, это 67 250 долларов за BTC.

Decimals feed и токена — разные единицы. Количество ERC-20 может иметь 18 знаков, а ценовой ответ — 8; до умножения масштабируйте каждое значение по его единицам. BTC/USD означает доллары за биткоин, USD/BTC — обратную единицу. Для производной пары масштабируйте оба feed и делите в правильном порядке; пример деноминации цены выводит BTC/EUR из BTC/USD и EUR/USD.

updatedAt показывает время обновления последнего раунда. Потребитель может сравнить его с временной меткой текущего блока и отклонить ответ старше заданного приложением предела. В зависимости от feed можно проверить ненулевое время, положительный ответ для актива с положительной ценой и разумные границы. Слишком узкие границы могут отклонять нормальные движения рынка.

Представим условный рынок кредитования: четыре единицы залога и коэффициент 75%. Последний ответ 200,000,000,000 при 8 decimals означает $2 000 за единицу, а лимит займа равен 4 × $2,000 × 75% = $6,000. Если рынок падает до $1 820, это снижение на 9%. При условных пороге отклонения 10% и heartbeat 60 минут новый отчет мог еще не требоваться; по более низкой цене лимит — $5 460.

Если приложение отклоняет цены старше пяти минут, а раунду двадцать минут, оно может запретить новые займы вместо использования $2 000. Проверка не обновляет feed, а меняет доступные действия при слишком старых данных. Для займа, вывода, ликвидации и погашения могут быть разные реакции, поскольку остановка всего тоже опасна. Числа и триггеры условны и не описывают текущие настройки или рекомендации.

Во многих L2 пользователи отправляют транзакции через sequencer. При сбое или восстановлении транзакции могут задерживаться, обычное использование прерываться, а ожидающие заявки исполняться после изменения рынка. Свежий на вид ценовой ответ L2 не доказывает доступность исполнения и возможность для всех действовать одновременно.

Chainlink описывает отдельный feed статуса sequencer L2: answer == 0 означает работу, answer == 1 — простой. startedAt отмечает смену состояния; пример потребителя проверяет статус и после восстановления ждет период ожидания, заданный приложением, прежде чем читать цену. Проверьте адрес и особенности сети в руководстве L2 Sequencer Uptime Feeds. Период ожидания не гарантирует обновление цены или завершение отложенных транзакций.

Кворум, медиана, отклонение, heartbeat, ограничение давности и статус sequencer отвечают на узкие вопросы. Они не гарантируют ликвидность рынка, верную идентификацию актива, независимость источников или исполнимую цену для заданного объема. Свежая временная метка может сопровождать неверное или манипулируемое значение; старое значение может оставаться близким к спокойному рынку.

Ни один триггер не устраняет разрывы цены, перегрузку сети или ошибки масштабирования, выбора пары, проверки свежести и ликвидации. Рекомендации по выбору качественных Data Feeds предлагают оценивать ликвидность и зависимости и обрабатывать старые, задержанные, отсутствующие и неожиданные данные. Остаются риски контракта, управления, мостов, залога и ликвидации. Цена oracle для стейблкоина также не гарантирует погашение по номиналу; см. руководство о depeg.

Определите сеть, proxy feed, пару активов, валюту котировки, decimals ответа и адрес контракта. Убедитесь, что описание feed соответствует активу, и не копируйте адрес из другой сети. При необходимости изучите модель источников и историю обновлений. Chainlink отмечает, что агрегаторы могут различаться между сетями, поэтому важны исходный код и настройки.

Затем проследите, как контракт использует ответ: преобразование количества и единиц цены, проверку updatedAt, максимальную давность и реакцию на недопустимое значение. В L2 проверьте uptime feed, время восстановления, период ожидания и отложенные транзакции. Разберите на реальном коде случаи устаревшей цены и простоя/восстановления. Различия ценовых полей объясняет сравнение mark price и последней сделки.