Вступ

З моменту зростання DeFi у 2019 році до його поступової зрілості до 2024 року проблеми з даними незмінно були основною проблемою для розробників. Це пов'язано з тим, що робота DeFi залежить від точних даних у ланцюжку в режимі реального часу, а якість даних безпосередньо впливає на безпеку, ефективність та користувацький досвід протоколів. Дані займають центральне місце в обміні цінностями та є наріжним каменем механізмів довіри протоколів. Для смарт-контрактів дані функціонують як вхідні факти, але самі смарт-контракти не можуть активно перевіряти автентичність даних. Натомість вони повністю залежать від даних, наданих зовнішніми джерелами. Ця характеристика означає, що якщо вхідні дані підроблені або неточні, смарт-контракт пасивно приймає їх, що потенційно може призвести до системних ризиків. Тому забезпечення децентралізації, надійності та зручності використання даних залишається постійним викликом. Проблеми пов'язані з двома основними проблемами: по-перше, більшість даних контролюється централізованими установами або платформами; По-друге, доступ до даних ускладнений, оскільки підтримання надійності по всьому трубопроводу — від джерела до каналів передачі до кінцевого пункту призначення — пов'язане зі значними проблемами.

Як міст між взаємодією даних на ланцюжку та позаланцюжковою взаємодією даних, оракули часто стають основною метою атак. Після того, як оракул був підконтрольований, зловмисники можуть зловживати неправдивою інформацією про ціни або ринок, щоб здійснювати масштабні економічні атаки, такі як маніпуляція оракулом та атаки з флеш-кредитом, які часто траплялися у 2021 і 2022 роках. Навіть до 2024 року ця загроза не зникає, як показують останні випадки з участю UwU Lend та Banana Gun. Ці події продовжують нагадувати нам, що якість і безпека даних оракула визначають успіх або невдачу окремих протоколів і безпосередньо впливають на стабільність усього екосистеми DeFi.

Ця стаття буде зосереджена на застосуванні оракулів в блокчейні, типах атак та методах запобігання загальним маніпуляціям оракулом. Вона спрямована на освіту читачів щодо основних концепцій та важливості оракулів, підвищення свідомості про безпеку та надання практичних рекомендацій розробникам щодо безпечного інтегрування оракулів у смарт-контракти.

Основні концепції Оракулів

Визначення та роль оракулів

Оракул - це критичний інтерфейс між блокчейном та зовнішнім світом. Він відповідає за імпорт даних з-поза ланцюжка в блокчейн, таких як ринкові ціни, погодну інформацію або результати подій, що дозволяє розумним контрактам отримувати доступ до зовнішньої інформації. З урахуванням вроджено закритого характеру блокчейнів, оракули відіграють важливу роль у сферах, таких як DeFi, ринки прогнозування, страхування та геймінг. Окрім вирішення обмежень блокчейну, оракули сприяють взаємодії між розумними контрактами та даними реального світу, розширюючи сферу застосування технології блокчейну. Однак оракули також стикаються з певними викликами та проблемами:

• Точність оракулів є критичною. Якщо джерело даних ненадійне або компрометоване, це може призвести до некоректного виконання смарт-контрактів і фінансових втрат.
• Оракули самі можуть стати об'єктом атак, наприклад, шляхом маніпулювання даними оракула для передачі хибної інформації, що призводить до маніпуляцій на ринку і порушення роботи протоколу.
• Хоча децентралізовані мережі оракулів можуть зменшити одночасні точки відмови, тривають дискусії щодо їх ступеня децентралізації та надійності. Підвищення надійності та безпеки оракулів залишається ключовим технологічним викликом.

Розуміючи основне визначення та роль оракулів, ми коротко розглянемо типи оракулів, їх використання та ризики безпеки, з якими вони стикаються.

Типи оракулів: Централізовані проти децентралізованих

Оракули можна широко класифікувати за двома моделями реалізації: централізовані та децентралізовані. Централізовані оракули, такі як Oraclize, зазвичай покладаються на один джерело даних для надання інформації поза ланцюжком блоків. Вони поєднують апаратні та програмні рішення, використовуючи технології, такі як TLSNotary та Android Proof, щоб забезпечити точність даних. Ці оракули відзначаються ефективністю та стабільною продуктивністю. Однак їх залежність від одного довіреного джерела підірвує децентралізований характер блокчейну, вводить одноточкові гальма і обмежує масштабованість, створюючи виклики як у сфері безпеки, так і в розширюваності.

У порівнянні, децентралізовані оракули, такі як Chainlink, надають перевагу безпеці системи та прозорості довіри. У архітектурі Chainlink збір та перевірка даних здійснюються кількома незалежними вузлами, розподіленими між різними учасниками, що зменшує ризик відмови одного центру. Співпрацюючи з операціями на ланцюгу та поза ланцюжком, Chainlink забезпечує різноманіття та надійність даних. Такий децентралізований дизайн особливо ефективний у фінансових застосуваннях, підвищуючи стійкість оракула до атак. Однак такий підхід включає компроміси у ефективності та вартості, що робить його менш підходящим для використання у випадках з низькою частотою.

Важливість децентралізованих оракулів полягає у зменшенні ризику маніпуляції джерелом даних та запобіганні потенційним зловживанням одним довіреним сторонам. Децентралізація забезпечує те, що оракули більше не залежать від кількох джерел даних, але покращують безпеку та надійність даних за допомогою кількох розподілених вузлів. Однак, децентралізовані оракули також стикаються з викликами, такими як забезпечення ефективних механізмів стимулювання на довгострокову перспективу та забезпечення загальної стабільності мережі оракулів. Далі ми розглянемо ризики безпеки, пов'язані з децентралізованими оракулами, та їх потенційні рішення.

Принципи роботи та ризики оракулів

Оракули з різними джерелами даних: поза ланцюжком та на ланцюжку

У операціях Oracle джерело та метод передачі даних безпосередньо впливають на їх безпеку та надійність. Оракули отримують дані з двох типів джерел: поза ланцюжком та у ланцюжку. Походження та методи отримання даних відрізняються між цими двома підходами:

• Дані поза ланцюгом: Швидкість відповіді на волатильність для даних поза ланцюгом залежить від характеристик джерела даних та механізму передачі. Наприклад, дані поза ланцюгом про ціни з бірж зазвичай швидко оновлюються. Однак інші дані поза ланцюгом (такі як дані з традиційних фінансових ринків або дані, отримані в результаті складних обчислень) можуть зазнавати затримок. Передача даних поза ланцюгом часто ґрунтується на обмеженій кількості привілейованих установ, які передають дані на блокчейн. Таким чином, важливо забезпечити, щоб ці установи не зловживали своїм статусом і не надсилали неправильні оновлення під тиском. Ця залежність потенційно загрожує достовірності та використовуваності даних на децентралізованих блокчейнах.
• Дані на ланцюжку: Дані на ланцюжку не потребують привілейованого доступу і завжди оновлюються, що надає сильні можливості в реальному часі. Однак ця ж характеристика робить їх дуже вразливими до маніпуляції з боку зловмисників, що може призвести до катастрофічних наслідків. Розробники можуть легко отримати доступ до даних на ланцюжку, запитуючи децентралізовані біржі (DEXs), щоб розрахувати ціни в реальному часі.

Оракули на ланцюжку та офф-ланцюжкові оракули
Вибір між джерелами даних поза ланцюжком і в ланцюжку залежить від конкретних вимог проекту та внутрішніх компромісів кожного підходу. Розробники повинні ретельно оцінити та вирішити пов'язані ризики. Ця потреба в балансі призводить до постійних досліджень більш безпечних та надійних методів обробки даних. У наступних розділах будуть розглянуті принципи роботи оракулів та їх потенційні вразливості.

Короткий приклад розробки Oracle

У цьому розділі наводиться спрощений сценарій розвитку, щоб допомогти читачам зрозуміти використання оракулів у блокчейні. У реальному розвитку розумних контрактів блокчейну є кілька способів, за допомогою яких розумний контракт може отримувати доступ до цінових даних від оракулів. Загальні методи включають безпосереднє викликання контракту оракула або використання технологій, таких як Chainlink CCIP (Cross-Chain Interoperability Protocol). Основні відмінності між цими методами полягають в тому, що:

1. Якщо цільове застосування знаходиться на тому ж блокчейні, розробники зазвичай безпосередньо викликають договір оракула для швидкого отримання актуальної інформації про ціни в режимі реального часу.
2. Для мульти-ланцюжкових додатків DeFi часто використовується Chainlink CCIP. CCIP забезпечує безпечний спосіб передачі даних між різними блокчейнами в крос-ланцюжкових сценаріях.

Тут ми демонструємо використання прямого виклику контракту оракула. Уявіть, що ви розробник розумного контракту в екосистемі Ethereum і вам потрібно отримати дані про ціну ETH/USD, використовуючи оракул у вашому контракті. Спочатку ви визначите інтерфейс для підключення до контракту оракула і напишете функцію для отримання даних про ціну.

Цей простий приклад контракту показує, як PriceConsumer Contract отримує дані про ціни в режимі реального часу та використовує їх для прийняття рішень. Це дає базове розуміння того, як смарт-контракти взаємодіють з оракулами для доступу до даних про ціни. Далі ми проаналізуємо пов'язані з цим ризики з двох точок зору:

З погляду внутрішнього контракту, використовуючи оракули, атакувальники можуть зловживати низьколіквідними ринками або малими біржами для маніпулювання цінами ETH/USD за допомогою великих транзакцій, що спричиняє аномальні коливання цін. Оскільки деякі оракули спираються на агрегацію даних з кількох торгових платформ, ці аномальні коливання можуть швидко поширюватися на метод fetchPrice() PriceConsumer, що призводить до спотворення цін. Ця ситуація зазвичай виникає, коли джерела даних оракулів є занадто централізованими, а ризики недостатньо диверсифіковані, що робить систему більш вразливою до маніпулювання цінами.

З погляду зовнішнього контракту, аналіз потрібно проводити враховуючи різні сценарії застосування. Припустимо, що контракт PriceConsumer використовується на платформі кредитування, де користувачі можуть заставити ETH як заставу, щоб позичити інші активи. Атакувальники спочатку використовують швидкі кредити, щоб позичити великі суми коштів та тимчасово заставити ці кошти в автоматичних ринкових мейкерах (AMM) або інших ліквідних пулах. Якщо у AMM низька глибина торгівлі, велика кількість одного активу, що швидко входить у пул, безпосередньо призведе до зміни ціни.

У цьому сценарії великі транзакції зловмисника змінюють ціну, звітувану AMM, яка потім відображається в маніпульованій ціні оракулу. Після маніпулювання ціною зловмисник може заробити різними способами, такими як:

1. Ліквідація застави в кредитних протоколах: Спроможна ціна може спровокувати ліквідацію певних заставних активів. Атакуючий може потім придбати ці активи за низькою ціною під час ліквідації, щоб отримати прибуток.
2. Арбітраж між платформами: Якщо маніпульована ціна створює значну різницю в цінах між платформами, зловмисник може використати цю різницю для здійснення прибуткових арбітражних угод.

Після завершення своєї діяльності зловмисник може негайно зняти кошти, відновити ціну AMM та погасити флеш-кредит зі відсотками, завершивши процес маніпуляції.

Далі, ми розглянемо більш глибоку дискусію, проаналізуємо конкретні випадки атак оракулів, їхні методи та дослідимо їх руйнівний вплив на протоколи DeFi та екосистеми on-chain, розкриваючи основну логіку та ключові технічні деталі.

Ризики, що виникають безпосередньо та опосередковано через Оракули

Хоча маніпулювання ринком та атаки на оракули можуть мати подібні наслідки, такі як спотворення цін та втрати активів, їх методи та точки відмови відрізняються. Більшість втрат у просторі блокчейну випливають з маніпулювання ринком, а не з вроджених дизайнерських проблем у оракулів. Основні відмінності наступні:

• Маніпуляція на ринку передбачає штучне змінювання подання та попиту з метою завищення або заниження цін на активи. Серед поширених тактик використовуються штучна торгівля та маніпулювання на крос-ринках. Наприклад, активи з низькою ліквідністю більш схильні до маніпуляцій, що може призвести до проблем з погашенням боргів та ризиками ліквідності для протоколів ДеФі.
• Атаки Oracle нарушають джерела даних оракула, що призводить до повідомлення цін, несумісних з фактичним ринком. Це може бути спричинено наміреним маніпулюванням, недостатнім джерелом даних або вразливостями безпеки оракула. Зловмисники використовують розбіжності між кормом і фактичними ринковими цінами для маніпулювання операціями в протоколах DeFi, таких як колатералізація або ліквідація.

Давайте проаналізуємо цей випадок:

У суті маніпулювання ринком досягається шляхом зміни фактичних ринкових цін, причому оракули вірно відображають ці маніпульовані ціни, тоді як атаки на оракули передбачають надання неправильних цін, тоді як ринкові ціни залишаються нормальними. Після того, як ми зрозуміли відмінність між оракулами та маніпулюванням цінами, наступним кроком буде вивчення різниці між збором даних в ланцюжку та позаланцюжковим збором даних, щоб краще зрозуміти, як оракули передають дані.

Випадки атак, пов'язані з Oracle

Серед численних випадків атак на оракули, поширеними типами є маніпулювання цінами, сполучені з викривленнями оракулів, помилки даних поза ланцюжком та експлуатація вразливостей дизайну протоколу. Нижче ми обговорюємо два типових випадки: інцидент маніпулювання цінами UwU Lend, який розкрив вразливості онлайн-оракулів перед зловживанням, та випадок збою оракула поза ланцюжком Synthetix, який продемонстрував глибокий вплив помилок зовнішніх даних на онлайн-контракти.

Подія маніпулювання ціною позики UwU

10 червня 2024 року UwU Lend, платформа з цифрового кредитування активів, яка базується на ланцюгах EVM, постраждала від атаки, в результаті чого втратили майже 19,3 мільйона доларів. Цей інцидент виклав потенційні вразливості в механізмах оракулів в рамках протоколів DeFi.

UwU Lend використовував криптовалюту під назвою sUSDE, ціна на яку визначалася оракулом цін. Як важлива складова частина протоколу кредитування, головною відповідальністю оракула було отримувати та надавати точні цінові дані, щоб забезпечити, що ключові операції, такі як кредитування та ліквідація, базувались на справедливих та стабільних цінах. Однак цей важливий механізм став вхідною точкою для атаки.

Атакувальник змінив ринкову ціну sUSDE, проводячи масштабні операції обміну в ліквідному пулі Curve Finance. Ця дія спотворила дані цінових оракулів, на яких підтримується UwU Lend. Розширюючи завищену вартість sUSDE, атакувальник використовував її як заставу для вилучення інших активів з UwU Lend, що в результаті призвело до значного зменшення активів платформи.

Кореневою причиною цього інциденту було недостатнє проектування UwU Lend для запобігання маніпуляціям оракулом. Ця вразливість дозволила зловмиснику маніпулювати ринковою ціною, спотворювати дані, що надходять від оракула, і здійснити цілеспрямований атаку. Цей випадок підкреслює поширене недоліків у платформах DeFi - слабкі механізми запобігання маніпуляціям в оракулах, особливо в умовах ринку з низькою ліквідністю, де такі ризики більш помітні.

Варто зазначити схожість між цим інцидентом і нападами на митні кредити. Напади на митні кредити, як правило, передбачають створення аномалій цін за допомогою значних, краткострокових капіталовкладень, тим самим порушуючи механізми зворотного зв'язку ціни оракулів, щоб досягти арбітражу активів або інших зловживань. Ця схожість ще більше підкреслює важливість міцних анти-маніпуляційних конструкцій в оракулах, критичних компонентах безпеки систем DeFi.

У майбутньому платформи DeFi повинні зосередитися на стратегіях, таких як агрегація даних про ціни з кількох джерел, оптимізація частоти оновлення цін та моніторинг аномальних цін при побудові оракульних механізмів. Покращення можливостей боротьби з маніпуляціями може знизити системні ризики, що виникають внаслідок відмови одного пункту або волатильності ринку.

Сбій оракула Synthetix

25 червня 2019 року Synthetix, протокол ліквідності деривативів на Ethereum, зазнав критичної помилки в своїй власній системі цінового оракулу поза ланцюжком, що призвело до того, що одна транзакція згенерувала непередбачувані величезні прибутки. Synthetix покладався на конфіденційні джерела для отримання цінових даних, агрегування та публікації цін на ланцюжку з фіксованими інтервалами, щоб надавати користувачам торгівельні ціни на синтетичні активи в довгий або короткий строк.

Однак, один з каналів цін помилково повідомив обмінний курс корейської воні (KRW) в 1 000 разів більше його фактичної вартості. Система не змогла відфільтрувати ці аномальні дані, що призвело до прийняття та публікації неправильної ціни в ланцюжку. Торговий бот виявив цю помилку і швидко виконав операції купівлі та продажу на ринку sKRW, накопичуючи величезний прибуток за рахунок арбітражу. Швидке виявлення проблеми командою дозволило їм домовитися з трейдером, який повернув прибуток в обмін на винагороду за виявлення помилки, уникнувши можливих втрат, що перевищують 1 мільярд доларів.

Незважаючи на те, що команда Synthetix вжила заходів для агрегації даних про ціни з кількох джерел, щоб захиститися від неточностей з одного джерела, цей інцидент підкреслив вбудовані ризики оракулів даних поза ланцюжком. Коли джерела даних на верхньому рівні допускають помилки, контракти в ланцюжку не мають уявлення про процес розрахунку ціни і, отже, не можуть автоматично виявляти аномалії.

Запобіжні заходи

Вищезазначені випадки підкреслюють, що виклики, з якими стикаються оракули, виходять за межі точності джерел даних, включаючи опір маніпуляціям та безпеку інтеграції даних поза ланцюжком. Таким чином, запобігання атакам на оракулах має вирішальне значення. Підвищення безпеки, надійності та можливостей запобігання маніпуляціям оракулів стає ключовим фактором при їх проектуванні та використанні. У цьому розділі ми досліджуємо ефективні заходи для протидії різним типам атак та зміцнення загальної безпеки систем оракулів.

1. Використовуйте кілька джерел даних для забезпечення точності даних

Аналіз справи: У випадку випадкової маніпуляції цінами в UwU Lend зловмисники успішно маніпулювали оракулом ціни UwU Lend, впливаючи на ціну sUSDE в пулі Curve Finance. Використовуючи вразливість маніпулювання цінами, зловмисники видобули активи, які система не змогла правильно оцінити. Якби UwU Lend використовував кілька джерел даних для визначення ціни sUSDE, система могла б перевірити ціни через інші джерела, зменшуючи ризик нападу.

Розширений аналіз: Цей інцидент включав маніпулювання цінами та виявив проблеми, пов'язані з недостатньою ліквідністю. Коли у токена відсутня достатня ринкова ліквідність, поверхнева глибина торгів зробить його ціну легкою мішенню для невеликої кількості трансакцій, тим самим збільшуючи вразливість оракула. Отже, при запуску нових токенів команди проекту повинні ретельно оцінювати ринкову ліквідність, щоб запобігти спотворенню цін та пов'язаним з цим ризикам безпеки. Наприклад, протоколи позик, такі як Aave, Kamino та Scallop, накладають більш суворі обмеження на токени з низькою ліквідністю у своїх дизайнах, щоб забезпечити стабільність та безпеку ринку.

Підхід оптимізації: Для забезпечення точності даних протоколи повинні використовувати стратегію багато джерел даних, включаючи кілька децентралізованих оракулів, таких як Chainlink або Band Protocol, для агрегування даних з різних бірж або ліквідності пулів. Цей підхід зменшує вплив на загальну безпеку системи, якщо будь-яке окреме джерело даних буде маніпульоване.

2. Децентралізовані агрегатори даних для забезпечення безпеки передачі даних

Аналіз справи: Відмова оракула Synthetix позачергово підкреслила ризики помилок у джерелах даних поза ланцюжком. У цьому випадку була повідомлена неправильна ціна Корейського вона (KRW), що дозволило торговому боту використовувати помилку для арбітражу. Якби Synthetix використовував децентралізований агрегатор даних, інші децентралізовані джерела даних могли би оперативно виправити проблему, навіть якщо одне джерело даних поза ланцюжком зазнало збою.

Підхід до оптимізації: Схоже на поліпшення в Uniswap V3, використання децентралізованих агрегаторів даних може покращити безпеку передачі даних. Шляхом використання криптографічних протоколів (таких як TLS) та перевірки підпису, спільно з децентралізованими реле-вузлами, системи можуть запобігти атакам людини посередині та фальсифікації даних. Наприклад, у оракула Chainlink кожне джерело даних перевіряється кількома незалежними вузлами та захищається методами шифрування, щоб забезпечити цілісність та незмінність переданих даних.

4. Модульний дизайн в архітектурі додатків для зменшення ризиків однієї точки відмови

Аналіз ситуації: Багато інцидентів нападу вказують на недоліки у модульному дизайні протоколів DeFi, які часто не мають достатньої кількості захисних механізмів. Шляхом ретельного проектування та будівництва незалежних модулів можна запобігти тому, щоб нападники використовували одну вразливість, щоб завдати катастрофічної шкоди всій системі. Наприклад, у випадку з відмовою Synthetix off-chain оракула, якби розробницька команда заздалегідь розробила модульну систему оповіщення, то вона могла б швидше виявити та виправити аномальні дані.

Підхід оптимізації: Для підвищення стійкості до атак розробники можуть використовувати шаровані архітектури під час процесу розробки та забезпечити незалежну роботу кожного модуля (джерело даних, логіка валідації, модуль передачі). Наприклад, як у Uniswap V3, зберігання інформації про ціни з різних ліквідних пулів у окремих пулах спостереження дозволяє протоколу порівнювати ціни в різних пулах, зменшуючи ризик маніпуляцій у будь-якому окремому пулі. У практичній розробці такі техніки, як інтерфейсна інкапсуляція та впровадження залежностей, можуть відокремити модуль валідації даних від іншої логіки, забезпечуючи гнучкість та підтримуваність системи.

5. Адаптивні механізми захисту в розумних контрактах

Хоча більшість оракулів покладаються на статичні заходи оборони, смарт-контракти можуть приймати адаптивні стратегії оборони для протидії високодинамічним методам атаки. Наприклад, відстежуючи частоту аномальних цінових коливань, система може визначити, чи відбувається атака, та викликати додаткові механізми перевірки або відкату відповідно до таких аномалій. Цей адаптивний підхід може автоматично захищати систему від потенційних втрат під час раптових цінових маніпуляцій.

Практичне застосування: Деякі протоколи DeFi реалізують механізми “threshold alert” для виявлення значних коливань цін в реальному часі. Якщо коливання цін перевищує задане порогове значення, система автоматично ініціює додаткові процеси перевірки або спрацьовує відкати, щоб запобігти ескалації маніпуляцій. Наприклад, протокол Balancer використовує поріг відхилення ціни; якщо ціна виявляється надто високою або низькою, він призупиняє певні транзакції до подальшого підтвердження валідності ціни.

Розглядаючи обговорення оптимізації дизайну і застосування оракулів, ми можемо дослідити конкретні рішення в межах додатків DeFi. Далі ми розглянемо механізм часово зваженого середнього курсу в Uniswap V2 та його вдосконалення в V3.

Випадки оптимізації безпеки в додатках DeFi Oracle

Безпека оракулів — це основна проблема для протоколів DeFi. Багато DeFi-протоколів впровадили цінні інновації для ефективного запобігання атак оракулів. Наприклад, Uniswap надав нові ідеї для розробки оракулів через її оптимізацію в генерації цін на ланцюжку та захисні механізми. Порівняння Uniswap V2 та V3 демонструє, як технічні поліпшення можуть підвищити можливості протидії маніпулюванню оракулів, пропонуючи чіткий шлях для безпечного проектування смарт-контрактів.

TWAP в Uniswap V2

Uniswap V2 вперше ввів оракула TWAP (Time-Weighted Average Price), що дозволяє розробникам на ланцюжку отримувати цінові дані від децентралізованих бірж (DEX). TWAP - це оракул на ланцюжку, який бере свої дані з торгівельних даних на ланцюжку самої Uniswap без залучення будь-яких даних поза ланцюжком.

У UniswapV2Pairконтракт, the_оновити()функция - это основная частная функция, ответственная за обновление резервов и накопителей цен для торговых пар. Ее основная цель - использовать накопитель цен с учетом времени для предотвращения атак оракулов.

Основна ідея цієї функції полягає в обмеженні можливості атакувальника маніпулювати цінами на одній точці в часі, реєструючи зміни цін, взважені в часі, для кожного блоку. Зокрема, функція розраховує різницю в часі (час пройшов) між поточним часом і останньою оновленням, множить цю різницю на поточну ціну торгової пари, а потім додає результат до накопичувачів ціни (ціна0КумулятивнаОстанняі price1CumulativeLast) Ця накопичена інформація записує середньозважену ціну за час, щоб згладити можливі коливання ціни. Оскільки ціна накопичується протягом певного періоду, зловмисникам потрібно постійно працювати через кілька блоків, щоб значно змінити ціну, тим самим збільшуючи вартість маніпулювання.

Крім того, функція оновлює накопичувачі цін тільки якщо час пройшовбільше 0, що означає, що ціна буде оновлюватися лише один раз на блок. Цей дизайн обмежує частоту операцій атакувача протягом короткого проміжку часу. Щоб ефективно маніпулювати ціною, атакувачам потрібно буде постійно втручатися протягом кількох блоків, а не одного блоку, що додатково зменшує ймовірність маніпуляцій.

З погляду безпеки цей механізм є надійним. Функція включає перевірки переповнення, щоб забезпечити, що максимальні значення резервів не перевищують системні ліміти, а також кумулятивні розрахунки цін також захищені від переповнення. Ці елементи конструкції роблять зовнішнє маніпулювання значно складнішим.

Проте версія V2 оракула має певні практичні обмеження. Наприклад, офіційний контракт надає лише останні накопичені значення цін, що вимагає від розробників фіксації та отримання історичних даних про ціни, накладаючи високий технічний бар'єр. Крім того, оракул V2 не записує безпосередньо глибину торговельної пари. Глибина торговельної пари є критичною для стабільності оракула в умовах атак — менша глибина спрощує маніпулювання цінами.

Uniswap V3

Щоб вирішити обмеження свого попередника, Uniswap покращив функціональність оракулів у своїй версії V3. Контракти V3 зберігають накопичені значення цін протягом часу та додають можливість зберігання історичної інформації про ціни, підтримуючи до 65 535 записів. Це усунуло необхідність розробників зберігати історичні дані вручну.

Крім того, оракул версії V3 записує часово-зважені значення ліквідності для різних рівнів комісій. Це дозволяє розробникам вибирати ліквідність пулів з вищими обсягами як джерела цінових посилань, забезпечуючи більшу точність цін. Усі логічні елементи, пов'язані з оракулом, увібрані в бібліотеку Oracle, що дозволяє контрактам автоматично записувати накопичені ціни та інформацію про ліквідність для кожної угоди без необхідності зовнішнього обслуговування користувача.

Ще одним важливим удосконаленням є коригування методу розрахунку ціни. У Uniswap V2 розрахунки TWAP базувалися на арифметичному середньому, тоді як V3 використовує геометричне середнє. Порівняно з арифметичним середнім, геометричне середнє забезпечує більшу стабільність в реалізації та краще підходить для середовищ з високою волатильністю цін, подальше зменшуючи ризик маніпуляції.

Майбутні тенденції

Атакувальники Oracle включають організовані групи, незалежних хакерів та потенційних внутрішніх злочинців, що співпрацюють з зовнішніми сторонами. Такі атаки зазвичай вимагають помірної технічної складності, що потребує від атакувальників базового розуміння технології блокчейну та смарт-контрактів і конкретних навичок експлуатації вразливостей. При зниженні технічних бар'єрів складність атак Oracle зменшується, що дозволяє хакерам з меншою технічною експертизою брати в них участь.

Атаки оракулів великими мірками залежать від автоматизації. Більшість зловмисників використовують автоматизовані інструменти для сканування та аналізу даних на ланцюгу, швидко виявляючи та використовуючи уразливості безпеки, такі як коливання ціни або затримки даних в оракулах. Наприклад, арбітражні боти та автоматизовані скрипти можуть реагувати на зміни ціни за мілісекунди, забезпечуючи зловмисникам прибуток до того, як ринок вирівняється. З ростом децентралізації блокчейн-мереж ці автоматизовані методи стають все більш ефективними, що робить атаки оракулів більш точними і складніше виявити.

Зазираючи в майбутнє, надійність даних оракула та стійкість до маніпуляцій, ймовірно, покращаться завдяки широкому впровадженню стандартизованих механізмів ціноутворення, таких як середньозважена за часом ціна (TWAP) та криптографічно підписана перевірка даних із кількох джерел. Хоча це може знизити здійсненність атак оракулів, можуть з'явитися нові загрози, зокрема складні методи, які поєднують різні методи арбітражу для обходу перевірок безпеки. Розробники DeFi повинні залишатися пильними, оскільки майбутнє безпеки оракула залежить від постійного вдосконалення децентралізованих заходів захисту даних і проактивного захисту від нових векторів атак.

Висновок

У цій статті досліджено критичну роль оракулів у системах DeFi та їх вразливість щодо безпеки, досліджуючи типи оракулів, приклади розробки, кейси та запобіжні заходи. Аналіз зосереджувався на двох ключових напрямках: атаки оракулів на основі швидких кредитів та випадкові атаки, виникають внаслідок невдач оракулів. Через це дослідження ми продемонстрували фундаментальне значення оракулів у архітектурі безпеки DeFi та їхню потребу в опорі від маніпуляцій, надаючи практичні методи запобігання атакам на оракули.

Відмова відповідальності: Зміст цієї статті носить лише посилальний характер і призначений для навчання та обміну знаннями про атаки на оракула. Він не є керівництвом для фактичних операцій або навчальних випадків.