Ценовой оракул: администратор и смена источника
Проверки цены и uptime имеют определённый смысл только для выбранного источника. Если администратор заменит feed, прежние предположения о паре, decimals и сроках могут перестать действовать. В уроке создадим конфигурационный договор оракулов библиотеки и разберём переход между версиями.
Конфигурация пока редакционная. Реальные адреса не подставлены, административных транзакций нет. Базовый CourseCatalog сохраняет прежние функции; управление ценовым источником относится к отдельному модулю PricePolicy, который вводится явно как расширение проекта.
Адрес вместе с назначением
Запись источника содержит сеть, адрес интерфейса, назначение пары, допустимый масштаб, параметры временного решения и ссылку на действующий профиль. Один адрес без этих данных не объясняет, как интерпретировать ответ. Даже стандартное название метода не превращает любой integer в цену нужного актива.
Если библиотека использует proxy-интерфейс предусмотренного feed, она понимает его роль и способы обновления. Прямое обращение к конкретной внутренней реализации может иметь другие ограничения. Выбор делается по первичной документации, а не копированием адреса из случайного старого примера.
{
"policyVersion": "library-price-v1",
"pair": "BTC/USD",
"feedAddress": "VERIFIED_FEED_ADDRESS",
"feedDecimals": "8",
"maxAgeSeconds": "SELECTED_MAX_AGE",
"useSequencerGuard": true,
"uptimeAddress": "VERIFIED_UPTIME_ADDRESS"
}Это схема с явными незаполненными полями. В действующем клиенте метки отвергаются. Политика uptime имеет свой сетевой профиль и grace, которые добавятся после выбора сети, а не автоматически выводятся из ценового адреса.
Кто может изменить правило
Замена источника влияет на результаты новых предложений и иногда на возможность действий. Такое полномочие отличается от публикации учебного текста. Проект может разделить эти роли либо передать их одному управляемому администратору, но решение должно быть явным.
В отдельном PricePolicy предусматривается собственная административная граница и события конфигурационного изменения. Мы не добавляем setter в исходный CourseCatalog без объяснения. Издательское право исходного контракта не означает автоматически право поменять цену, транспорт и uptime сразу во всех модулях.
Процедура может включать предварительное объявление и задержку активации, если продукт выбирает такой договор. Это не универсальная обязательная функция любого feed. Если задержки нет, пользователям и операторам всё равно нужны идентичность новой версии и история принятого решения.
Согласованные поля
Адрес BTC/USD и decimals выбираются вместе с проверкой назначения. Изменение только одного из них способно изменить результат на порядки. Аналогично maxAge должен соответствовать новому источнику и цели. Переезд на другую сеть требует её uptime-профиля, а не прежнего адреса технического feed.
Частичное конфигурационное обновление опасно для нескольких участников. Браузер может показывать новую оценку, сервер — создавать счёт по старой, а контракт — принимать третий профиль. Поэтому ревизия является согласованным набором правил. Каждый расчёт сохраняет, какую ревизию использовал.
Для своего учебного проекта библиотека выбирает единый источник истины конфигурации и явную передачу версии участникам. Отдельные кэши допустимы, если их актуальность и применение определены. Просто перезаписать последний JSON-файл недостаточно для объяснения уже созданных предложений.
Старые предложения
Предложение на 18 USD уже превратилось в конкретный счёт в сатоши. Администратор заменил источник для новых предложений. По нашему договору старый счёт сохраняет зафиксированную сумму и исходное основание. Он не пересчитывается задним числом через новую пару или масштаб.
Если продукт хочет отозвать незавершённые предложения при смене политики, это отдельное правило с понятным интерфейсом. Его нельзя применять незаметно к уже принятому платежу. История конфигурации помогает различить допустимое истечение, административный отзыв и ошибку расчёта.
Для читателя важнее итоговая сумма и срок, чем внутренний номер источника. Но оператор способен открыть основание и объяснить, почему две близкие по времени заявки получили разный результат. Сохранённые входы не требуют обращаться к будущему значению feed для восстановления старого решения.
Изменённый масштаб
Новый источник выражает похожую цену с другим числом десятичных знаков. Конфигурационный переход меняет масштаб и предусмотренную формулу согласованно. Если система поддерживает только прежний профиль, она отклоняет новый выбор до активации, а не надеется, что арифметика угадает единицы.
Содержательно одинаковая котировка при разных масштабах может давать тот же результат расчёта. Однако это не доказывает одинакового происхождения или режима обновления. Досье сохраняет назначение, качество источника и временные ограничения отдельно от числовой совместимости.
Также не считаем поле description автоматическим удостоверением официальной принадлежности. Любой подходящий контракт способен сообщить похожую строку. Назначение адреса устанавливается документированным выбором и процессом библиотеки; метод описания помогает исследованию, но не заменяет этот канал доверия.
Отзыв и резервный маршрут
Если текущий источник признан неподходящим, новые зависимые действия могут приостановиться. Резервный источник вводится по тем же правилам выбора и версии, а не случайным fallback на первое доступное число. Такой переход сохраняется в истории, чтобы цена предложения была объяснимой.
Ошибки старой конфигурации не удаляются из журнала ради чистого интерфейса. Если обнаружено неверное назначение пары, библиотека определяет, какие предложения затронуты и какие прикладные решения нужны. Новый правильный адрес не исправляет уже созданные записи автоматически.
Восстановление администратора также отличается от сохранения данных feed. Досье описывает полномочия и управляемые процедуры без реальных ключей в статье. Секрет управления никогда не является частью публичного манифеста учебного выпуска.
Текущий API Reference отмечает answeredInRound как deprecated-поле прежней модели вычисления ответов. Поэтому при редактуре адаптера нельзя бездумно объявлять любую старую проверку этого поля обязательной современной гарантией для всех feeds. Изучается конкретный действующий профиль и сохраняются действительно нужные условия. Аналогично прямые методы старого aggregator могут отличаться от рекомендуемого proxy-интерфейса. Конфигурация должна описывать эти решения, а не только компилирующийся набор вызовов. В нашем PricePolicy происхождение, пара, масштаб, свежесть и L2-условия выражены независимо; сами API-поля не подменяют их прикладной смысл.
Подготовленный переход
Результат — версия PricePolicy, выбранные роли изменения, атомарный набор параметров и правила старых предложений. Ожидаемые разборы включают неправильную пару, неподдерживаемый масштаб, частичное обновление и осознанную замену для будущих счётов. Исполнения административных функций не было.
Первичные правила интерфейса раскрыты в Data Feeds API Reference, свойства выбора — в Selecting Quality Data Feeds. Следующая глава рассмотрит асинхронный внешний процесс и переход от исторического Functions к современной CRE, сохраняя этот принцип явной конфигурации.