Коли стандартних оракулів недостатньо
Протокол DeFi з TVL $50 млн втратив $2 млн через маніпуляцію оракулом на неліквідному токені. Атакуючий взяв flash loan, смикнув ціну в пулі з низькою ліквідністю та обманув контракт. За даними Chainlink Research, понад 90% зломів DeFi пов'язані з оракулами. Chainlink і Pyth покривають 95% потреб у цінових даних, але для нішевих активів, унікальних off-chain даних або приватних метрик готові рішення не підходять. Наша команда має 5+ років досвіду в розробці оракулів та реалізувала 30+ проєктів — від простих цінових фідів до ZK-верифікованих систем для інституційних клієнтів. Ми розробляємо кастомні оракули під ключ — гнучку альтернативу Chainlink, стійку до маніпуляцій.
Чому Chainlink не вирішує всі проблеми?
- Неліквідний або нішевий актив. Chainlink не додає feed для токена з TVL менше $1 млн. Ми підключаємо будь-який актив, включаючи токени з TVL від $10 тис.
- Off-chain дані: спортивні результати, погода, страхові індекси — все, що не є ціною. Для кожного джерела даних потрібна індивідуальна інтеграція із забезпеченням достовірності.
- Приватні дані: корпоративні метрики, TradFi дані з ліцензійними обмеженнями — не можна віддавати публічному оракулу. Ми будуємо ізольовані мережі нод з шифруванням.
- Агрегація по-особливому: медіана за довільним набором джерел, VWAP за кастомний період, фільтрація викидів. Стандартні фіди дають лише просту медіану.
- On-chain дані з верифікацією: дані з іншої мережі, підтверджені ZK-proof. Це дозволяє безпечно передавати активи між L2 та L1.
Як захистити оракул від flash loan маніпуляцій?
Flash loan атака — одна з найпоширеніших: зловмисник позичає велику суму, маніпулює ціною на DEX з низькою ліквідністю та використовує спотворені дані оракула для виведення коштів. Ми застосовуємо комбінацію захистів:
- TWAP замість spot — time-weighted average price за останні N хвилин (зазвичай 10-30). Рухати TWAP складніше: потрібно утримувати ціну протягом часу.
- Медіана за множиною джерел — використовуємо не менше 5 незалежних джерел (централізовані біржі, DEX, агрегатори). Вплив одного DEX мінімізовано.
- Circuit breakers — якщо ціна відхиляється більш ніж на 5% від попередньої, оновлення блокується і вимагається ручне втручання. Для стабільних монет поріг знижуємо до 2%, для волатильних — до 10%.
- Об'ємне зважування — ігноруємо джерела з об'ємом нижче заданого порогу (наприклад, $100 тис. на годину).
- Private mempool — часті оновлення відправляються безпосередньо в блокчейн, минаючи публічний mempool, що запобігає front-running.
Докладніше про flash loan attack.
| Атака | Захист |
|---|---|
| Flash loan | TWAP + volume weighting |
| Front-running | Private mempool |
| Sybil | M-of-N signature scheme (мінімум 3 з 5 нод) |
| Data spoofing | Multi-source median + circuit breakers (поріг 5%) |
Коли використовувати ZK-оракул?
Для проєктів з високими вимогами до trustlessness використовуємо ZK-based oracle. Нода надає ZK-proof, що доводить коректність отримання та агрегації даних, без розкриття самих даних. Цей напрям активно розвивається: наприклад, DECO (TLS-based ZK) та концепція zkOracle з SNARK-верифікацією, заснованою на ZK-proof доказах. Перевага ZK-оракула над класичним — у 6 разів вища безпека завдяки математичним доказам без довіри до нод. Верифікація даних через ZK-proofs усуває ризик Sybil-атак та маніпуляцій.
| Параметр | Класичний оракул | ZK-оракул |
|---|---|---|
| Довіра до нод | Потрібна (підписи) | Ні (математичний доказ) |
| Вартість газу | Низька (близько 50k gas на апдейт) | Вища (верифікація proof ~300k gas) |
| Складність розробки | Середня | Висока (потрібне знання SNARKs) |
| Зрілість | Продакшн-рівень | Експериментальна, але швидко розвивається |
Як ми розробляємо кастомний оракул: етапи
- Аналіз вимог — специфікація типів даних, джерел, частоти оновлень (від 1 секунди до 1 години) та рівня безпеки. Визначаємо необхідну кількість нод (рекомендуємо не менше 7).
- Проєктування архітектури — вибір схеми підписів (M-of-N з ECDSA або BLS для агрегації), визначення механізму агрегації (медіана, TWAP, VWAP), налаштування circuit breakers. Для ZK-рішень проєктуємо схему доказів з використанням commitment schemes.
- Розробка смарт-контракту оракула — on-chain агрегатор з підтримкою підписів, агрегації та аварійних зупинок. Контракт проходить фаззинг-тестування інструментами Echidna та Foundry.
- Розробка off-chain нод — надійний збір даних з 3+ джерел на актив, підпис та відправка. Середній час доставки даних — 2–5 секунд, що в 3 рази швидше за типового публічного оракула. Використовуємо REST та WebSocket для різних типів даних.
- Тестування та аудит — крім unit-тестів, проводимо тести на маніпуляції (симуляція flash loan, затримка нод) та зовнішній аудит безпеки від партнерів. Гарантуємо 99.9% uptime оракула.
- Деплой та моніторинг — розгортання в mainnet, налаштування алертів за затримками (якщо апдейт не прийшов за 10 секунд) та відхиленнями (відхилення від еталона більше 1%).
Що входить у розробку кастомного оракула
— Архітектурна документація та схема підписів. — Вихідні коди смарт-контракту агрегатора та off-chain нод. — Інструкція з розгортання та інтеграції. — Налаштування моніторингу та алертів (затримки, відхилення). — Навчання команди замовника роботі з оракулом. — Технічна підтримка на етапі запуску (2 тижні).
Орієнтовні терміни та вартість
Розробка кастомного оракула займає від 4 до 12 тижнів. Конкретний термін залежить від кількості джерел даних (3–10), необхідного рівня trustlessness (M-of-N або ZK), кількості цільових блокчейнів (Ethereum, Polygon, Arbitrum). Для простого цінового фіда з 5 джерелами — 4–6 тижнів. Для ZK-рішення з кросс-чейн верифікацією — 8–12 тижнів. Пишіть для безплатної оцінки вашого проєкту та розрахунку вартості.