Что ломается при интеграции Band Protocol без своих скриптов
Band Protocol отдаёт данные через pull-модель: контракт сам запрашивает значение в момент вызова и платит за его доставку. Готовая интеграция выглядит простой — берём опубликованный поток котировок и читаем его из расчётной логики. Проблема в том, что поток описывает «среднюю цену по рынку», а контракту нужна конкретная пара, конкретный источник и правило, по которому значение вообще можно принять.
Первое, что ломается, — расхождение котировок. Если источник один и значение собирается без агрегации по площадкам, разница с реальной сделкой накапливается и становится заметной именно на волатильности. Контракт исполняет ликвидацию или своп по цене, которой на рынке уже нет, и расчёт начинает работать против протокола.
Второй сбой — устаревшие данные в смарт-контракте. Поток обновляется по своему расписанию, а не по факту движения рынка; между двумя доставками значение живёт в контракте, хотя реальная цена давно ушла. Без проверки свежести и порога отклонения расчётная логика принимает старую метку времени за актуальную и подтверждает операцию, которую подтверждать не следовало.
Третий — узкое место оракула как единственной точки отказа: при недоступности источника встаёт не один вызов, а весь расчётный цикл, а корректной фиксации задним числом не происходит. Кастомные скрипты источника закрывают все три сбоя: они задают список площадок, правила агрегации и условие свежести, при котором значение вообще попадает в контракт. Ниже разбираем, как это закрывается.
Что меняется после внедрения: расхождения, задержки, простои
Первый эффект виден по доле расхождений. До интеграции значение в контракте и значение в источнике совпадали не всегда: расхождение копилось между ручными обновлениями и всплывало уже при разборе инцидента. После интеграции Band Protocol оба конца сверяются автоматически, и расхождения остаются единичными — обычно на стороне источника, а не доставки.
Второй — время реакции на изменение данных. Раньше оно равнялось паузе до следующего обновления по расписанию, то есть измерялось часами и зависело от дежурного. Теперь обновление инициирует сам факт изменения, задержка укладывается в один цикл доставки, а частота обновления перестаёт быть компромиссом между свежестью и нагрузкой на узел.
Третий — класс отказов, который перестаёт существовать. Уходит сценарий «источник недоступен, контракт считает по последнему известному значению»: в pull-модели данные запрашиваются в момент расчёта, и при отсутствии свежего ответа операция не проходит вместо того, чтобы выполниться по устаревшим числам.
Четвёртый — наблюдаемость потока данных. Каждое обновление оставляет запись с меткой времени, источником и подписью, а отклонение от предыдущего значения выше заданного порога поднимает оповещение. Доля ручных сверок падает до выборочных проверок по регламенту вместо ежедневных.
Band Protocol: pull-модель вместо обновления по расписанию
В Band Protocol доставка значений строится вокруг pull-модели данных: контракт запрашивает цену в момент вызова и сам проверяет подпись валидаторов. При обновлении по расписанию значение пишется в хранилище заранее — читать дешевле, но свежесть ограничена периодом обновления, а запись оплачивает инициатор, независимо от того, был ли спрос на это значение.
Выбор режима — компромисс между задержкой чтения и стоимостью проверки внутри транзакции. Если расчёт опирается на одно биржевое значение, аномалия на площадке уходит прямо в исполнение сделки: агрегация источников с медианой и отсечением выбросов это сглаживает, а резервный источник данных закрывает случай, когда основной агрегатор недоступен или отдаёт устаревшее значение.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Pull-модель по запросу | Нужна цена на момент исполнения сделки | Проверка подписи внутри вызова повышает расход газа |
| Обновление по расписанию | Постоянные чтения: отчёты, ликвидные пулы | Между обновлениями значение устаревает, записи идут вхолостую |
| Свой источник | Узкий набор активов, закрытые рынки | Единая точка отказа, прямая зависимость от одной площадки |
| Гибрид: агрегация и резерв | Крупные объёмы, кредитные протоколы | Сложнее сопровождение: нужно следить за расхождением источников |
Мы собираем такую схему под конкретный контракт: где-то достаточно pull-модели одного агрегатора, где-то нужен резерв и собственный скрипт проверки границ значения.
Этапы внедрения: аудит источников, схема, настройка, проверка
Порядок работ фиксирован: непроверенные источники делают схему обновления бессмысленной, а без схемы настройка скриптов превращается в угадывание. Каждый этап заканчивается артефактом — перечнем, схемой, конфигурацией, — поэтому на приёмке видно, что именно проверялось и на каких данных.
- Аудит источников данных. Собираем фиды, которыми пользуются контракты, и сверяем их с реестром: кто публикует значение, с какой частотой, есть ли резервный канал на случай отказа основного.
- Проектирование схемы обновления данных. Определяем pull-модель: кто инициирует запрос к оракулу, по какому порогу отклонения значения, с каким интервалом и что происходит, если обновление не пришло вовремя.
- Настройка скриптов оракула. Пишем скрипты агрегации под Band Protocol: правила усреднения, отсечение выбросов, маппинг тикеров. Прогоняем на изолированном контуре на исторических значениях.
- Приёмочные проверки. Воспроизводим сценарии расхождения источников, задержки публикации и полного отказа одного канала. Фиксируем поведение системы и границы, за которыми транзакция не проходит.
- Передача регламентов сопровождения. Отдаём документацию по порогам, порядку оповещений и действиям дежурного при отклонении, плюс инструкцию по подключению новых источников.
Артефакты передачи: конфигурации, схемы и регламенты
Помимо кода интеграции у заказчика остаётся комплект, по которому решение можно сопровождать и развивать своими силами: настройки, схемы и регламенты описывают, откуда приходят данные и кто вправе их менять. Комплект хранится в том же репозитории, что и контракты, — история правок конфигурации восстанавливается так же, как история кода.
- Конфигурация оракула — файлы настроек кастомных скриптов: перечень источников по каждому набору данных, порог отклонения значения, период обновления и адреса контрактов, к которым привязан Band Protocol.
- Схема потоков данных — маршрут целиком: источник → скрипт оракула → запись в контракт → потребители, с отмеченными точками отказа и резервными источниками.
- Политики доступа — матрица ролей и ключей: кто подписывает транзакции обновления, какие лимиты действуют, где нужна вторая подпись.
- Регламент обновления источников — порядок добавления и замены источника: кто согласует, на каком контуре проверяется, какое окно даётся на откат.
- Документация по мониторингу — метрики (задержка обновления, доля успешных записей, расхождение между источниками), настроенные оповещения и пороги срабатывания.
- Регламент инцидентов — действия при недостоверных данных: переключение на резерв и откат последних записей.
- Журнал изменений конфигурации — учёт правок с автором, причиной и результатом проверки.
Этого набора достаточно, чтобы команда заказчика правила источники и пороги без нашей поддержки.
Кейс: расхождения данных и время реакции до и после
Расчётный контур клиента — сервис с мгновенным исполнением операций — держался на самописном сборщике курсов: несколько источников, своя логика усреднения, запись значения в сеть по расписанию. Схема держалась, пока активов было немного, но каждое новое подключение добавляло точки отказа и всё больше ручных сверок.
До перевода
Расхождения между расчётным значением и рыночными котировками всплывали по нескольку раз в сутки — обычно в моменты резких движений, когда записанное по таймеру значение отставало от рынка. Инженеры сверяли выгрузки вручную и разбирали спорные операции по журналам, а на восстановление после падения одного из источников уходили часы: пока не убедишься, что сборщик снова отдаёт корректное значение, расчёты останавливать нельзя.
После перевода
Канал данных перевели на Band Protocol: логику агрегации вынесли в собственные скрипты оракула, а запись по расписанию заменили моделью запроса по требованию — расчёт берёт свежее значение в момент операции, а не то, что обновилось таймером. Источников оставили несколько, но коридор допустимых отклонений задали явно, и выброс за его пределы в расчёт больше не проходит.
Расхождения на спорных операциях сократились примерно в пять раз, доля сделок с ручной сверкой упала с единиц процентов до десятых. Восстановление после сбоя источника укладывается в минуты: канал переключается на резервный набор, расчёт идёт дальше, а причину инженер разбирает без остановки сервиса. Откат к предыдущему набору источников — одна правка конфигурации, без пересборки логики.
Чем pull-модель отличается от периодического обновления
Разница в том, кто инициирует обновление. При периодическом режиме оракул сам пишет значение в контракт по расписанию — запись идёт даже когда за интервал его никто не прочитал, а к моменту сделки данные успевают устареть. В pull-модели значение запрашивается в момент обращения: платит только тот, кому оно нужно, и свежесть данных жёстко привязана к моменту вызова.
| Схема | Когда подходит | Ограничения |
|---|---|---|
| Периодическая запись | много читателей на одно обновление, витрины и аналитика | оплачиваем обновления без читателей, свежесть ограничена интервалом |
| Обращение по требованию | редкие, но чувствительные к цене операции, кредитные протоколы | запрос и проверка подписи в каждой транзакции, дороже по стоимости вызова |
| Гибрид | горячие пары и редкие активы в одном протоколе | нужен общий слой абстракции над двумя источниками |
Выбор диктуют частота чтения и цена задержки. Если устаревшее значение ведёт к ликвидации по неверной цене или к арбитражу на расхождении, интервал обновления перестаёт быть настройкой и становится классом отказа. Интеграция с Band Protocol в таком сценарии строится вокруг чтения по требованию с проверкой подписи ответа.
Переход с существующего оракула делаем поэтапно: параллельный запуск нового источника рядом со старым, сверка расхождений на исторических данных, переключение читателей по одному и только затем вывод старого фида. Откат на любом шаге — возврат адреса источника в конфигурации, без миграции состояния.
Технические сомнения: отказ источника, лимиты, ключи подписи
В интеграциях на Band Protocol на этапе выбора подрядчика всплывают одни и те же вопросы: что произойдёт с контрактом, если источник данных замолчит, упираемся ли мы в лимиты запросов, кому доступны ключи подписи и как выглядит план восстановления после сбоя. Ниже — короткие ответы по каждому.
Что будет, если внешний источник данных перестанет отвечать?
В pull-модели значение запрашивается в момент вызова, поэтому отказ обрабатывает контракт-потребитель: он сверяет метку времени и порог отклонения. Если значение старше допустимого окна, подключается резервный оракул либо операция встаёт на паузу до ручного подтверждения — устаревшая цена в контракт не попадает.
Упираемся ли мы в лимиты запросов к источнику?
Квота на частоту обращений есть у любого поставщика данных. Мы разводим чтения по расписанию, кэшируем значение между вызовами и агрегируем несколько потребителей в один запрос — вместо потока мелких обращений получается предсказуемая нагрузка. При подходе к квоте контракт уходит на резервный источник, а не падает с ошибкой.
Кому доступны ключи подписи?
Ключи, которыми подписываются обновления данных, лежат в аппаратном модуле или изолированном хранилище — не в репозитории и не в переменных окружения. Роли разделены: один ключ публикует значения, административный нужен только для смены источника. Ротация и порядок выдачи доступа описаны в регламенте.
Обсудим задачу и вернёмся с оценкой и планом работ
Чтобы оценка задачи интеграции была точной, а план работ по оракулу — выполнимым, нам нужны вводные по источнику данных и схеме расчётов. Ниже — набор, которого достаточно, чтобы вернуться с архитектурой, сроками и составом работ, а не с общими формулировками.
- С чем работаем сейчас: в каких сетях развёрнуты контракты и в каких местах логики должны появляться внешние данные.
- Источник данных: откуда берём значения — своя витрина, биржевая лента, внутренний сервис — и как часто они меняются.
- Схема расчётов: какие величины считаем, какое расхождение между источниками считаем нормой и что делать при выходе за порог.
- Требования к свежести: допустимая задержка между обновлением источника и записью в контракт, поведение при недоступности источника.
- Подписи и роли: кто подтверждает данные, сколько подтверждений нужно, как проходит ротация ключей.
- Ограничения: требования аудита, внутренние политики безопасности, порядок доступа к инфраструктуре и средам.
- Что нужно получить на выходе: контракты и оракул-скрипты Band Protocol, схему развёртывания, документацию и передачу знаний команде.
Этого набора хватает, чтобы предложить конкретную схему интеграции и порядок выката по средам. Опишите задачу своими словами — вернёмся с оценкой и планом работ, разложенным по этапам и зонам ответственности.
