Що ламається під час інтеграції 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, схему розгортання, документацію та передавання знань команді.
Цього набору вистачає, щоб запропонувати конкретну схему інтеграції та порядок викочування за середовищами. Опишіть задачу своїми словами — повернемося з оцінкою та планом робіт, розкладеним за етапами й зонами відповідальності.
