Модульний дизайн
Найпростіший спосіб забезпечити доступність інформації для смарт-контрактів - це безпосереднє внесення даних в сховище. Цей підхід добре працював для великих інтервалів оновлення та невеликої кількості активів. Однак у сфері децентралізованих фінансів (DeFi) з'являється все більше токенів, а сучасні протоколи похідних вимагають значно нижчого часу затримки, що підвищує витрати на підтримку простої моделі.
Саме тому RedStone пропонує абсолютно новий модульний дизайн, в якому дані спочатку вводяться в шар доступності даних, а потім витягуються на ланцюг. Це дозволяє передавати велику кількість активів з високою частотою на більш доступний шар і вносити їх на ланцюг лише тоді, коли це вимагається протоколом.
3 способи інтеграції В залежності від архітектури смарт-контракту та бізнес-вимог, ми можемо подавати дані за допомогою трьох різних моделей:
1\. **RedStone Core**: дані динамічно вводяться в транзакції користувачів, досягаючи максимальної газової ефективності і забезпечуючи відмінний користувацький досвід, оскільки весь процес вписується в одну транзакцію.
2\. **RedStone Classic**: дані передаються до ланцюгового сховища через релеї. Призначений для протоколів, які працюють за традиційною моделлю оракулів і бажають повного контролю над джерелом даних і умовами оновлення.
3\. **RedStone X**: спрямований на потреби найбільш високорозвинених протоколів, таких як постійні, опціони та похідні, шляхом усунення ризику передпроходження та надання поточних котирувань цін вже у наступному блоку після взаємодії користувачів.
Data Flow
Цінові котирування надходять з різних джерел, таких як офф-чейн DEX (Binance, Coinbase та Kraken і т.д.), on-chain DEX (Uniswap, Sushiswap, Balancer і т.д.) та агрегатори (CoinmarketCap, Coingecko, Kaiko). Наразі у нас інтегровано більше 50 джерел.
Дані агрегуються в незалежних вузлах, які обслуговують постачальники даних за допомогою різних методик (наприклад, медіана, TWAP, LWAP) та заходів безпеки, таких як виявлення викидів. Очищені та оброблені дані потім підписуються операторами вузла, гарантуючи їхню якість.
Котирування передаються як на платформі Streamr, так і безпосередньо на відкриті шлюзи з відкритим кодом, які можуть бути легко запущені за потреби.
Дані можуть бути внесені на ланцюг або за допомогою спеціалізованого ретранслятора, який працює за попередньо визначеними умовами (наприклад, серцевий ритм або відхилення цін), за допомогою бота (наприклад, виконання ліквідацій) чи навіть кінцевими користувачами, що взаємодіють з протоколом.
Усередині протоколу дані розпаковуються та перевіряються криптографічно, перевіряючи як походження, так і мітки часу.
Data Format
На вищому рівні передача даних в середовище EVM вимагає додавання додаткового навантаження до транзакції користувача та обробки повідомлення на ланцюгу.
Data packing (off-chain data encoding)
Упакування даних (кодування даних офф-чейн).
1. Необхідно отримати актуальні дані з децентралізованого кеш-шару, забезпеченого мережею Streamr та легкими вузлами кешу RedStone.
2. Дані упаковуються в повідомлення відповідно до наступної структури.
3. Пакет додається до початкового повідомлення транзакції, підписується і відправляється в мережу.
Data unpacking (on-chain data verification)
Розпакування даних (перевірка даних на ланцюжку)
1. Додані пакети даних вилучаються з msg.data.
2. Для кожного пакета даних ми:
Перевіряємо, чи підпис був створений довіреним постачальником
Перевіряємо мітку часу, перевіряючи, чи інформація не застаріла
3. Потім, для кожного запитаного потоку даних ми:
Розраховуємо кількість отриманих унікальних підписників
Вилучаємо значення для кожного унікального підписника
Розраховуємо агреговане значення (зазвичай медіану).
On-chain aggregation
Агрегація на ланцюжку Для підвищення безпеки системи оракулів RedStone ми створили механізм агрегації на ланцюжку. Цей механізм додає додатковий вимогу до передачі принаймні X підписів від різних авторизованих постачальників даних для заданого потоку даних. Значення різних постачальників потім агрегуються перед поверненням у споживацький контракт (зазвичай для агрегації використовується розрахунок медіани). Таким чином, навіть якщо деякий невеликий підмножник постачальників скорумпує (наприклад, 2 з 10), це не повинно суттєво вплинути на агреговане значення.
Types of values
Ми підтримуємо два типи даних, які можна отримати в контракті:
1. Числові значення 256 біт (використовується за замовчуванням).
2. Масиви байтів з динамічним розміром.
Security considerations
Рекомендації з безпеки:
-
Не перезаписуйте функцію getUniqueSignersThreshold, якщо ви не абсолютно впевнені в її роботі.
-
Звертайте увагу на логіку перевірки мітки часу. У деяких випадках важливо кешувати останні значення в сховищі вашого контракту, щоб уникнути арбітражних атак, зокрема, для синтетичних DEX.
-
Увімкніть механізм безпечного оновлення для вашого контракту (ідеально на основі багато-підпису чи DAO).
-
Моніторте реєстр служб даних RedStone і швидко модифікуйте логіку авторизації підписувачів у ваших контрактах у разі змін (ми також повідомимо вас, якщо ви є платником).
Детальна інформація про RedStone Oracles
Для повного розуміння RedStone ми рекомендуємо відвідати сторінку за посиланням нижче. Надана інформація надасть вам необхідні знання для ефективного спілкування про RedStone та його функції.