DORA: Distributed Oracle Agreement (Український переклад)

19 min readMar 4, 2024

Оригінал статті тут.

Наступна публікація в блозі — це документ DORA litepaper. Щоб отримати докладніший опис нашого розподіленого протоколу Oracle, завантажте повний документ тут.

Що таке Oracle (Оракул)? Навіщо це потрібно?

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

Від недетермінізму до детермінізму

Чи можемо ми мати інструкцію getCurrentPrice(“BTC”) на такому комп’ютері? НІ. Чому? Тому що вихідні дані цієї інструкції відрізнятимуться залежно від того, коли ця інструкція виконується та звідки витягуються ціни. Це порушує угоду, оскільки порушує фундаментальну властивість нашого комп’ютера бути детермінованим.

Отже, що можна зробити, щоб вирішити цю проблему? Один із способів вирішити цю проблему — отримати весь контекст для інструкції як вхідні дані. Наприклад, у нас буде така інструкція, як getPrice(“BTC”, “SomeExchange”, “11:59:59 UTC 7 Dec 2022”). У цій інструкції ми чітко вказуємо, яку ціну ми маємо отримати та звідки. Однак у нас ще є кілька проблем, які потрібно вирішити.

Питання архівності (Archival)

Ми припускаємо, що незалежно від того, коли ми виконаємо цю інструкцію, ми отримаємо той самий результат. Що, якщо ми спробуємо виконати цю інструкцію через десять років, а «SomeExchange» не матиме цих даних? Що, якби, гіпотетично, «SomeExchange» зберігав лише п’ять років даних через свою політику збереження даних на той час? Що, якби з цим фрагментом даних трапилося пошкодження даних? По суті, нам потрібен надійний і незмінний архів, щоб ми отримували точно той же результат, навіть якщо ми виконаємо цю інструкцію через десять років. Що ж, один такий механізм ми вже знаємо. Сам блокчейн! Ми можемо мати інструкцію putPrice(CommodityCode,source,time,value) для збереження значення CommodityCode, отриманого з джерела в певний час, у самому блокчейні, яке можна безпечно отримати пізніше.

Автентичність (Authenticity)

Однак ми все ще маємо проблему. Як ми знаємо, що значення справді походить із джерела, отриманого в той час? Якщо саме джерело підписує та засвідчує, що в даний момент ціна CommodityCode є цінністю, тоді ми закінчили. Ось як справді працюють деякі оракули. На жаль, не всі джерела інформації цифрово підписують свої дані та поміщають їх у блокчейн. Крім того, те, що джерело даних підписує свої дані, не означає, що підписані дані насправді точні. У такому випадку нам потрібен набір об’єктів, які можуть поставити штамп автентичності та засвідчити, що значення справді є ціною CommodityCode у джерелі та в часі.

Агрегація (Aggregation)

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

Так що ж таке DORA (Distributed Oracle Agreement, Розподілена Угода Oracle)?

ЗАВАНТАЖИТИ WHITEPAPER PDF | ПЕРЕГЛЯНУТИ ПРЕЗЕНТАЦІЇ

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

За відсутності помилок Візантійського типу достатньо лише одного вузла, який збирає інформацію з кількох джерел. Однак за наявності візантійських розломів нам знадобиться кілька вузлів. Коли всі вузли можуть надати одне значення як вхідні дані, а деякі вузли є візантійськими, проблема для решти чесних вузлів узгодити єдине репрезентативне значення називається проблемою DORA (Distributed Oracle Agreement, Розподілена Угода Oracle). Формально кажучи:

Протокол DORA cеред n нод p1, p2, p3 ….. pN , з кожним вузлом , що має входи Vi або задану домовлену відстань D , гарантує, що:

1.[Завершення, Termination] : усі чесні вузли згодом узгоджують певне значення.
2. [Угода, Agreement] : вихідне значення S для всіх вузлів однакове.
3. [Валідність, Validity] : Hmin ≤ S ≤ Hmax , де Hmin та Hmax позначають мінімальне та максимальне значення від чесних вузлів. Ми позначаємо вихідне значення DORA як Supra-value або S-value або S.

Репрезентативне значення

Зверніть увагу, що ми не тільки вимагаємо, щоб усі вузли сходилися до одного значення, але воно має бути репрезентативним значенням. Згадана вище властивість валідності стверджує, що S має бути десь між мінімальним і максимальним значенням від чесних вузлів. Однак це не здається репрезентативним. Як будь-яке значення між мінімальним і максимальним значеннями від чесних вузлів можна назвати репрезентативним значенням від усіх чесних вузлів? Це правильне запитання. Можна припустити, що взяття середнього значення всіх значень може бути хорошим кандидатом для створення репрезентативного значення. Така думка цілком слушна, але все ж наївна.

Мало того, що в нас є вузли Візантійського типу, ми навіть не знаємо, які з них є вузлами Візантійського типу, а які чесними. Під час обчислення середнього значення, навіть якщо вкрадається одне значення від вузла Візантійського типу, результат може довільно відхилятися від середнього всіх чесних значень. Медіана пропонує надійну альтернативу як репрезентативне значення, оскільки це статистичний агрегатор, який може допускати пошкодження даних до 50%. На жаль, за наявності до 1\3 вузлів Візантійського типу, гарантія, надана у вищезгаданій валідній властивості, є найкращою можливою гарантією, яку може надати будь-хто. Будь ласка, зверніться до вайтпеперу DORA для офіційного підтвердження цього.

Архітектура Supra Oracle

Служба Supra Oracle передбачає наявність SMR (State Machine Replication, реплікація кінцевого автомата), також відомої як блокчейн-сервіс.

Що ж таке SMR?

Неформально кажучи, SMR (State Machine Replication, реплікація кінцевого автомата) пропонує таку службу впорядкування, що будь-яке повідомлення, надіслане цій службі впорядкування, стає частиною загального замовлення, і кожен вузол, який читає повідомлення з цієї служби, спостерігає за тим самим набором повідомлень у тому самому загальному порядку.

Архітектура Tribe-Clan (Плем’я-Клан)

Плем’я (Tribe) — це набір вузлів. Плем’я може продовжувати безпечно функціонувати та досягати прогресу в послугах, які воно пропонує, доки кількість вузлів, які стають Візантійськими, менше ніж 1/3
усіх вузлів.

З Племені ми рівномірно випадковим чином малюємо підмножини вузлів. Кожну таку підмножину ми називаємо Кланом (Clan). Кожен Клан малюється таким чином, що ймовірність мати половину або більше Візантійських вузлів у Клані є незначною. Наш протокол DORA розроблено таким чином, що за звичайних обставин нам потрібно лише, щоб Клан обчислив і погодив S-value. Це означає, що DORA може працювати з меншою кількістю вузлів і витримувати більший відсоток вузлів, які перетворюються на Візантійські.

Товарний шардинг (Commodity Sharding)

Провайдеру Oracle може знадобитися надати репрезентативне значення ціни для багатьох товарів, торгових пар, таких як BTC/USD, ETH/USD тощо. Оскільки ми вимагаємо, щоб лише Клан запускав протокол DORA, ми розподіляємо відповідальність за різні торгові пари порівну між різними Кланами. Наприклад, якщо нам потрібно агрегувати та надавати S-value для 100 різних торгових пар, і якби у нас було 4 Клани, то кожному Клану можна було б дати відповідальність за обчислення S-value для 25 торгових пар.

Протокол DORA

Тепер давайте подивимося, як працює один раунд протоколу DORA.

Збір даних

Кожному вузлу Клану призначається набір джерел даних для отримання значення ціни торгової пари. Як ви можете бачити на зображенні вище, кожен вузол отримує дані з кількох джерел даних. Чому так? Ну, Клан може працювати правильно, лише якщо менше половини вузлів клану є Візантійськими. Як приклад, уявіть сценарій, коли у нашому клані є 51 вузол, 25 із яких уже стали Візантійськими. Все йде нормально. Тепер уявіть, що у нас є така конструкція, де кожен вузол отримує дані лише з одного джерела даних.

А що, якщо джерело даних стане Візантійським? Навіть чесний вузол, якщо він отримує дані з одного візантійського джерела, демонструє візантійську поведінку. Сміття на вході, сміття на виході. Тож тепер ми маємо 26 із 51 вузла, які демонструють візантійську поведінку. Зараз немає жодної гарантії, чи може Клан взагалі виробляти будь-яку цінність, і якщо це так, чи буде ця вартість десь близькою до ідеальної репрезентативної ціни товару. Це робить Oracle фактично марним.

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

Також варто зауважити, що існує кілька вузлів, які отримують дані з кожного джерела даних. Чому так? Ну, уявіть, що ми зараз у ситуації, коли джерело даних є чесним, але вузол Візантійський. Ціна, надана чесним джерелом даних, може взагалі не враховуватися під час розрахунку S-значення (S-value). Ось чому ми гарантуємо, що існує кілька шляхів, якими ця інформація може потрапити в обчислення. Тепер нам потрібно розглянути ще один нюанс.

Наприклад, якщо у нас є загалом 10 джерел даних, і кожен вузол повинен слухати принаймні 3 джерела даних, як ми можемо бути впевнені, що ціни з кожного джерела даних враховують свій шлях у остаточному обчисленні? Що робити, якщо всі вузли прослуховують перші 3 джерела даних і ніхто не прослуховує решту 7? Щоб уникнути цієї ситуації, призначення джерел даних для вузлів виконується за допомогою VRF (Verifiable Random Function, випадкова функція, що перевіряється). Таким чином ми можемо гарантувати, що всі джерела даних передають свої дані приблизно однаковій кількості вузлів у Клані.

Агрегація на рівні вузлів (Node-Level Aggregation)

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

Роль Агрегаторів (Aggregators)

Як тільки вузол обчислив значення, тепер нам потрібно знайти спосіб для всього клану узгодити одне єдине значення. Оскільки різні вузли слухають різні набори джерел даних, значення, обчислені різними вузлами, можуть відрізнятися. Ось тут і вступає в гру Агрегатор. Ми позначаємо набір вузлів із Племені як агрегатори.

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

Отже, що робить агрегатор? Передбачається об’єднати значення з усіх вузлів в одне репрезентативне значення для ціни даного товару. Зауважте, що майже певна половина вузлів Клану можуть бути Візантійськими, і вони можуть ніколи не надсилати свої значення агрегатору. Тож ми знаємо, що чесний агрегатор може розраховувати на отримання принаймні fc + 1 значення, де f в це максимальна кількість Візантійських вузлів у клані розміром 2 fc + 1.

Припустимо, що він чекає першого fс + 1 значення, щоб почати. Чи може він запропонувати середнє арифметичне цього значення як S-значення? Проблема в тому, що агрегатор не може бути впевнений, що все це fc + 1 значення надходять із лише чесних вузлів. Візантійський вузол, бажаючи маніпулювати S-значенням, може надсилати яке завгодно велике значення. Оскільки затримки мережевого зв’язку є непередбачуваними, це значення може надійти раніше, тому воно включається в набір fc + 1 значення. Середнє арифметичне тепер може стати як завгодно великим через включення цього єдиного нечесного значення.

Чи працює медіана? Мабуть, ні. У клані такого розміру 2fc + 1, аж до fc вузли могли перетворитися на Візантійські. Тому не виключено, що якщо агрегатор чекає першого fc + 1 значення для обчислення S-значення, то стільки, скільки ((fc+1)\2) нечесні цінності можуть пробитися в цьому наборі fc + 1 значення.

Так що ж — наразі уся надія втрачена? На щастя, ні; тут є срібний обрій. Навіть у гіршому випадку, коли скільки завгодно fс з fс + 1 цінності могли бути Візантійськими, нам гарантована принаймні одне чесне значення. Магія полягає в тому, щоб використовувати цей факт. Проблема обчислення середнього або медіани з першого набору fс + 1 отриманих значень, полягає в тому, що нечесні значення можуть бути як завгодно великими або як завгодно малими порівняно з чесними значеннями. Ми можемо вирішити цю проблему, вимагаючи, щоб навіть у найгіршому випадку з одним чесним значенням, це значення діяло як якір для інших значень, так що інші значення, навіть якщо вони недобросовісні, не можуть довільно відхилятися від чесного значення.

Ось де дистанція узгодження (agreement distance) D вступає в гру.

Дистанція узгодження (Agreement Distance)

Враховуючи домовлену відстань D, ми говоримо, що два значення v1 і v2 погоджуються між собою, якщо |v1–v2|≤ D. Тобто, якщо різниця між двома значеннями не перевищує дистанцію узгодження, то кажуть, що вони узгоджуються одне з одним.

Набір значень CC кажуть, що утворює когерентний кластер (кластер узгодження), якщо ∀v1,v2∈CC:|v1–v2|≤D. Іншими словами, когерентний кластер — це набір значень, де всі значення цього набору узгоджуються між собою.

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

Ця варіація DORA називається DORA-CC (Distributed Oracle Agreement with Coherent Cluster) і формально визначається наступним чином:

Протокол DORA-CC серед cеред n вузлів p1, p2, p3 ….. pN, з кожним вузлом , що має входи Vi, для заданої дистанції узгодження D, гарантує, що:
1. [Завершення, Termination] : усі чесні вузли згодом узгоджують певне значення.
2. [Угода, Agreement] : вихідне значення S для всіх вузлів однакове.
3. [Валідність, Validity] : Hmin — D ≤ S ≤ Hmax + mathcal D, де Hmin та Hmax позначають мінімальне та максимальне значення від чесних вузлів.

Хвилинку! Яка у нас є гарантія, що ми завжди зможемо сформувати узгоджений кластер розміру fc+1? Ну, гарантії тут немає. Однак ми спостерігаємо, що за нормальних обставин ціни на певну торгову пару з різних джерел даних дуже близькі. Отже, якщо ми встановимо нашу дистанцію узгодження D достатньо великий, щоб значення з чесних джерел даних погоджувалися між собою за звичайних обставин, узгоджений кластер fc+1 цінності можуть бути сформовані. Що стосується ненормальних обставин, то ми повернемося до них пізніше.

Голосування та Публікація Значень (Voting and Value Posting)

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

Агрегатор надсилає середнє значення разом із значеннями, підписаними вузлами, до всіх вузлів Клану для перевірки та затвердження. Важливо, щоб агрегатор надсилав кластер значень і середнє значення всім вузлам Клану, а не лише на fс + 1 вузлів, які сприяли формуванню кластера. В іншому випадку, якщо є Візантійський вузол, який зробив внесок у кластер, він може утримувати свій голос, таким чином зупинивши прогрес протоколу.

Тепер кожен вузол може підтвердити, що значення були внесені вузлами Клану завдяки цифровим підписам. Вони також можуть підтвердити, що набір значень справді формує узгоджений кластер на узгодженій відстані, і що середнє значення, надіслане агрегатором, справді є середнім значенням кластера. Оскільки Клан має принаймні 2fс+1 вузлів, ми впевнені, що отримаємо принаймні fс+1
голосів схвалення, таким чином дозволяючи агрегатору сформувати сертифікат кворуму. Після формування сертифіката кворуму середнє значення публікується як S-значення для даного раунду узгодження на SMR. Всі чесні вузли побачать S-значення, опубліковане для раунду, і завершать раундд.

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

Що ж робити в такому випадку? Що ж, коли ви вважаєте, що не можете перемогти у битві, відступайте.

Резервний протокол (The Fallback Protocol)

Ініціювання резервного варіанту

Отже, які вузли вирішують, коли відступати? Усі. Усі вузли клану запускають таймер резервного варіанту, щойно надсилають свої значення агрегаторам. У дикій ситуації, будь-якому агрегатору може бути неможливо сформувати кластер узгодження певного розміру fс+1.

Згодом таймер резервного варіанту закінчується. Коли таймер вузла закінчується, він надсилає голос за резервний варіант всім агрегаторам. Згодом у нас буде агрегатор принаймні з fс+1 голосами за резервний варіант, що дозволяє сформувати сертифікат кворуму для резервного варіанту, і він опублікує його на SMR. Будь-який вузол, який спостерігає повідомлення про резервний варіант для раунду SMR, перемикається на резервний протокол.

Резервний Протокол

Ми розуміємо, що ситуація трохи нестійка, і саме тому ми вирішили перейти на резервний варіант. Так що ж нам робити? Виводимо вагомих гравців на арену! На даний момент ми залучаємо все Плем’я до участі в обчисленні S-значення.

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

Тут все дещо відрізняється. Ми знаємо, що ми вже в ситуації, коли ми не зможемо сформувати узгоджений кластер. Тож агрегатор тепер чекає першого 2ft+1 вузлів Племені для надсилання своїх значень. Тут ми припускаємо розмір Племені 3ft+1 щонайбільше ft вузлів, які можуть перетворитися на Візантійські. З 2ft+1 значень, принаймні ft+1 цих значень має бути з чесних вузлів. Тому зараз ми використовуємо медіану цих значень, оскільки знаємо, що медіана буде пов’язана з чесними значеннями.

Решта процесу йде по відомому шляху. Агрегатор пропонує цю медіану як S-значення для цього раунду разом із набором 2ft+1 отримані значення з цифровим підписом. Вузли Племені перевіряють і надсилають свої голоси схвалення назад до агрегатора, агрегатор формує сертифікат кворуму з 2ft+1 голосів, а потім розміщує в SMR.

Чому ми маємо кілька агрегаторів?

Давайте розглянемо модель, де у нас є єдиний агрегатор. Розглянемо сценарій, коли цей агрегатор є Візантійським. Цей агрегатор не може опублікувати неправильне повідомлення S-значення через вимогу, щоб більшість вузлів Клану підтверджували та голосували за S-значення, обчислене агрегатором. Однак агрегатор може спричинити проблеми з живучістю, якщо не запропонує S-значення, або не подаючи узгод S-значення для SMR. Модель із кількома агрегаторами вирішує цю проблему, гарантуючи наявність принаймні одного чесного агрегатора в наборі агрегаторів.

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

Але тепер у нас є кілька агрегаторів, які можуть публікувати
S-значення на SMR. Який із них буде зарахований? Це просто, перший! Що, якщо значення опубліковано візантійським агрегатором? Це не має значення. Агрегатори не можуть підробити підпис будь-якого з чесних вузлів. Отже S-значення все одно (i) або буде на максимальній відстані від чесного значення, або (ii) буде між двома чесними значеннями.

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

Початок відліку DORA (Tick-Start DORA)

Чи помітили ви, що один раунд погодження не залежить від жодного з попередніх раундів? Ми можемо використовувати цей факт на нашу користь.

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

Затримки мережі, як і погода, непередбачувані. Через асинхронний характер зв’язку в межах кланових вузлів можливо, що значення з різних раундів будуть публікуватися в хаотичному порядку. Наприклад, значення раунду 4 може відображатися в SMR перед значенням раунду 3. На практиці 4-й раунд буде мати свіже значення, тому інформація, отримана з 3-го раунду після того, як стане доступним значення 4-го раунду, може бути неактуальною. Виходячи з цього припущення, ми можемо заощадити на деяких непотрібних обчисленнях та комунікації.

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

Виявлення аномалії (Anomaly Detection)

Автоматичні вимикачі

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

Одним з популярних механізмів є автоматичний вимикач. Основна функція дуже проста. Позначимо Sr як значення S-значення раунду r. Функція автоматичного вимикача |Sr–Sr−1|Sr−1≥thr спрацьовує і перериває ланцюг (або зупиняє торгівлю), коли Sr
відхиляється від Sr−1 більше, ніж певний відсотковий поріг, визначений thr.

Історія перевірки узгодженостей

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

Якщо ми розглянемо всі S-значення у заданому вікні історії Wx, ми можемо придумати узагальнену формулу, як зазначено на зображенні вище. Так як thr є параметром для автоматичного вимикача, Sr є постійним параметром, який контролює допустиме відхилення.

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

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

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

Крос-відносини (Cross-Relations)

Багато торгових пар на ринку корелюють між собою, тому будь-які зміни в однієї тогрової пари можуть впливати на ціни корельованих товарів, торгових пар. Наприклад, нехай x буде BTC/USD, y буде ETH/USD та z буде BTC/ETH. Легко побачити, що в ідеалі ми б мали x–y=0.

Звичайно, на практиці ми матимемо x–yz ≤ Dr для деякої кореляційної відстані Dr. Тоді, якщо ми виявимо x–yz > Dr, ми знаємо, що щось не в порядку. Такий багатофакторний аналіз є чудовою зброєю в нашому арсеналі для судового аналізу. Якщо ми призначимо усі три торгові пари різним Кланам, супротивник має бути достатньо могутнім, щоб контролювати три Клани, щоб уникнути будь-якого виявлення.

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

Рандомізація (Randomization)

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

Однак наш дизайн робить це настільки складним, наскільки це можливо. Як засіб пом’якшення, у Supra ми пропонуємо різні методи рандомізації, щоб тримати супротивника в невідомості.

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

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

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

Імовірнісна безпека та живучість

Під час кожного перемішування Клани випадковим чином вибираються з Племені за допомогою рівномірного розподілу. Оскільки Плем’я може мати до 1\3. Візантійські вузли, ймовірність наявності принаймні одного Клану 1\2 або більше візантійських вузлів не дорівнює нулю. Нам потрібно зафіксувати розмір Племені та кількість Кланів у Племені таким чином, щоб імовірність того, що будь-який Клан матиме візантійську більшість, була незначною.

Наприклад, якщо ми маємо 625 вузлів у Племені та 5 Кланів у Племені, кожен з яких має 125 вузлів, ймовірність того, що будь-який із Кланів матиме більшість Візантійських вузлів, буде менше 35 на мільйон. Якщо тривалість епохи становить 2 дні, частота відмов буде близько одного разу за 156 років.

Зі збільшенням розміру Племені ймовірність провалу для фіксованої кількості Кланів зменшується.

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

Наприклад, якщо ми виберемо 12 агрегаторів з Племені із 502 вузлів, ймовірність відсутності жодного чесного агрегатора буде менше 1,5 на мільйон. Навіть якщо епоха триватиме один день, частота збоїв буде менше, ніж раз на 1800 років!

Зі збільшенням кількості агрегаторів ймовірність відмови експоненціально падає.

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

Ключові аспекти нашого дизайну Oracle:

Наш дизайн враховує можливість виникнення Візантійських вад у деяких джерелах даних.
Наша новаторська ідея використання дистанції узгодження та використання SMR дозволяє протоколу DORA бути стійким до більшого відсотка Візантійських помилок (51%), в порівнянні з традиційним лімітом толерантності до відмов у розмірі 33%.
Оскільки для функціонування протоколу DORA потрібен менший відсоток чесних вузлів, він дозволяє нам успішно масштабуватися за допомогою шардингу торгових пар.
Модель з кількома агрегаторами дозволяє уникнути затримок, які можуть виникнути в моделі з одним агрегатором через Візантійський агрегатор.
Рандомізація в нашому дизайні обмежує повноваження супротивника.
Ми пропонуємо різноманітні послуги виявлення аномалій, включаючи кросс-кореляцію для покращених можливостей виявлення аномалій і шахрайства.

Якщо ви хочете розгадати технічні таємниці нашого дизайну Oracle за допомогою офіційного опису, теорем і доказів, перегляньте повну технічну документацію DORA.

Оригінал статті: