Razor (RAZOR) - децентрализованная сеть оракулов

Все, что предоставляет внешние данные в цепочку блоков, называется «Oracle». Сеть Razor состоит из валидаторов, которые фиксируют свои токены в качестве «ставки» и предоставляют данные в сеть. Честные валидаторы награждаются, а те, кто сообщает непоследовательно, наказываются.

Ядро Razor Network - это набор смарт-контрактов, которые могут работать на любом блокчейне, совместимом с Ethereum. Razor полагается на базовый блокчейн для обеспечения определенных свойств, таких как устойчивость к цензуре, безопасность от атак на разделы сети и т. д.

Цель Razor Network - предоставить децентрализованный способ проверки и передачи данных в блокчейн. Поскольку целая экономика строится на основе блокчейна, который в значительной степени зависит от внешних данных, чрезвычайно важно, чтобы данные предоставлялись и агрегировались децентрализованно, чтобы избежать многих видов атак.

Децентрализованный оракул, такой как Razor, может столкнуться с различными видами атак:

  1. Атака захвата путем контроля над большинством валидаторов;
  2. Взятка атака;
  3. Взятка сигнального нападения;
  4. Предоставление недействительного или скомпрометированного источника данных;
  5. Делать недействительные запросы к оракулу;
  6. Цензура отчетов честных валидаторов.

Помимо защиты от таких атак, Razor Network имеет следующие особенности:

  1. Оракул, быстрый и надежный;
  2. Охватывает большое количество вариантов использоания, позволяя получать результаты как вручную, так и автоматически.

Чем отличается Razor Network от других оракулов?

Сравнение децентрализованных сетей оракулов

Как видно из таблицы выше, есть два типа децентрализованных оракулов:

  1. Оракулы, которые имеют быстрое время разрешения, но теоретически небезопасны в игре;
  2. Оракулы с медленным временем разрешения, но теоретически безопасны в игре.

Рынок явно нуждается в быстром и безопасном оракуле. Сеть Razor заполняет этот пробел.

Razor - это децентрализованный оракул, в отличие от Provable (ранее Oraclize), который является централизованным оракулом. Такие централизованные решения не включаются в сравнение.

Как сеть достигает цели децентрализации?

Децентрализация - важная цель сети. Это связано с тем, что централизация наделяет небольшую группу объектов большой властью, что делает возможным множество атак и ставит под угрозу надежность протокола.

Мы поощряем децентрализацию протокола следующими способами:

  1. Справедливое и широкое распространение токенов.
  2. Протокол не разрешен. Мы или кто-либо еще не имеем права решать, кому разрешено или иным образом участвовать в сети.
  3. Опирается на децентрализованный, устойчивый к цензуре базовый блокчейн.
  4. Запросы псевдослучайно назначаются валидаторам, что затрудняет сговор и подкуп.
  5. Схема фиксации раскрытия для выявления «голосов» и механизм спора обеспечивает защиту от атак с подкупом.

Какие запросы можно выполнять с помощью Razor?

Razor можно использовать для выполнения двух типов запросов:

  1. Запросы в автоматическом режиме.
  2. Запросы в ручном режиме.

Это позволяет Razor охватить большое количество вариантов использования.

Для запросов в автоматическом режиме клиент должен предоставить URL-адрес, указать, как должен быть обработан ответ, чтобы получить результат. Назначенные валидаторы автоматически получат URL-адрес, проанализируют результаты и отправят их в сеть. Поскольку ручное вмешательство не требуется, запросы в автоматическом режиме обрабатываются относительно быстрее.

ПРИМЕР ЗАПРОСА В АВТОМАТИЧЕСКОМ РЕЖИМЕ:

URL: https://api.gemini.com/v1/pubticker/ethusd

Селектор: «последний»

С другой стороны, запросы в ручном режиме не требуют исходного URL. Назначенные валидаторы должны вручную получить данные и передать их в сеть. Такие запросы подходят для таких приложений, как рынки прогнозирования, где ставки высоки и приемлем более длительный период разрешения. Кроме того, точный URL-адрес может быть недоступен для такого запроса во время его формирования.

ПРИМЕР ЗАПРОСА В РУЧНОМ РЕЖИМЕ:

Вопрос: Кто победил на выборах в США в 2020 году?

Источник данных (необязательно): основные СМИ США и общеизвестные источники.

Как запросы назначаются разным валидаторам?

Запросы псевдослучайно назначаются разным валидаторам.

  • Чем выше относительная ставка валидатора, тем выше шансы этого конкретного валидатора получить шанс участвовать в текущей эпохе. Таким образом, подмножество валидаторов выбирается в каждом раунде лотереей, чтобы избежать проблем с масштабируемостью и связанных атак. Уравнение, которое это определяет:

Где PRN - генератор псевдослучайных чисел с использованием детерминированного алгоритма.

S - ставка валидатора

Sm - максимальная ставка, сделанная в настоящее время в сети.

D - автоматически регулируемый коэффициент сложности.

  • Если в лотерее выбран валидатор, ему будет псевдослучайно назначен запрос.

Например, предположим, что в эту эпоху мы будем обрабатывать 4 запроса. Все валидаторы генерируют псевдослучайное число от 0 до 1. Если сгенерированное число находится в диапазоне от 0 до 0,25, первое задание будет назначено этому валидатору. Если он находится между 0,25 и 0,5, вторая работа и так далее.

Как безопасным образом генерируются псевдослучайные числа?

Для различных операций протокола нам необходимо генерировать псевдослучайные числа без доверия. Алгоритм должен быть детерминированным, чтобы расчет можно было выполнить и проверить на блокчейне.

В настоящее время мы используем хэши блоков Ethereum для генерации случайности. Это детерминировано, поскольку хэши блоков публично известны и поддаются проверке.

Хеш блока - это, по сути, случайное 256-битное число. Разделив его на 2 ^ 256, мы получим случайное число от 0 до 1. Затем оно используется для различных вычислений в протоколе.

Как протокол обеспечивает защиту от различных атак с целью подкупа и сговора?

В протоколе есть несколько контрмер для предотвращения таких атак.

  • Commit - раскрыть механизм

Когда валидаторы сообщают о точке данных, они сообщают об этом секретным образом, в состоянии фиксации эпохи. Они создают «хэш» точки данных вместе с секретом и сообщают этот хеш. Следовательно, никто, кроме самого валидатора, не знает своего голоса. Это делает процесс отчетности незаметным и позволяет избежать влияния голосов других валидаторов на чьи-либо голоса.

В состоянии раскрытия эпохи все валидаторы раскрывают секрет вместе со своим голосованием. Хэш этого должен соответствовать хешу, сообщенному валидатором в состоянии фиксации, в противном случае он не будет принят смарт-контрактом.

Если кто-то преждевременно раскроет свой секрет во время состояния «фиксации», любой может сообщить об этом в смарт-контракт и сократить свою долю. Следовательно, валидаторы сильно лишены стимулов делиться своими секретами. Из-за этого механизма становится сложно доказать взяткодателю, что вы проголосовали тем или иным образом.

  • Механизм разрешения споров

Злоумышленник может подкупить большую часть доли ненадежным способом и может поставить под угрозу результаты оракула. Чтобы предотвратить это, в Razor Network есть встроенный механизм разрешения споров.

Любой результат оракула можно оспорить, заплатив «Облигацию спора», которая может быть выплачена коллективно. Диспутеры получают вознаграждение в размере 50% от суммы залога, если они успешно оспаривают раунд.

Если залог успешно оплачен в течение периода спора, запрос вступает в раунд спора. В раунде диспута ставки выше, размер штрафа за бессвязное голосование выше, а на запросы валидаторы отвечают вручную. Результаты раунда диспута могут быть оспорены. Количество акций, участвующие, и количество облигаций спора удваиваются каждый раунд. Если спорщик выигрывает спор, его залог возвращается, в противном случае он конфискуется и передается согласованным валидаторам.

Благодаря этому механизму, даже если злоумышленник скомпрометирует оракул, результат, скорее всего, будет оспорен честным лицом. Чтобы скомпрометировать раунд спора, злоумышленнику придется заплатить двойную взятку. Даже если им это удастся, этот раунд, вероятно, снова будет оспорен и так далее. Это может продолжаться до тех пор, пока вся сеть не примет участие в раунде спора. Если в ходе этого раунда также не удается разрешить спор, сеть разделяется на две сети, и рынок принимает решение о честной вилке.

Как протокол обеспечивает защиту от атак с недействительными запросами?

Клиент должен заплатить «залог срока действия» за запрос в Razor. Это в дополнение к комиссии за транзакцию за запрос. Залог действительности будет конфискован, если запрос будет исключен как недействительный, иначе он будет возвращен клиенту после того, как результаты будут окончательно определены.

Поскольку расследование запроса требует ручного вмешательства, это можно сделать только в раундах споров и вручную.

Злоумышленник может сделать неверный запрос в сеть следующими способами:

  • Неверный источник данных

Злоумышленник может предоставить источник данных, который не отвечает, предоставляет ненадежные данные или не заслуживает доверия.

  • Неверный запрос

Сам запрос может быть недействительным. Например, «Это утверждение верно?» неверный запрос.

Как протокол обеспечивает защиту от различных сетевых атак?

Разделение сети, атаки eclipse, атаки цензуры

Razor - это набор смарт-контрактов, работающих на базовом блокчейне. Задача базового блокчейна - защитить себя от таких атак. Мы будем использовать либо основную сеть Ethereum, которая защищена от таких атак, либо решение масштабируемости с такими же свойствами.

  • Нападения впереди

Смарт-контракты были тщательно разработаны, чтобы сделать предварительный запуск невозможным или индифферентным по сравнению с обычной транзакцией.

  • Атака удержания транзакции

Валидатор может проголосовать за эпоху (e). Майнер может приостановить эту транзакцию на (n) эпох и добыть ее в эпоху (e + n). Это может повредить честному валидатору, поскольку транзакции в сети Razor чувствительны ко времени, а результат потока данных может отличаться в эпоху (e) и (e + n).

Чтобы этого не происходило, эпоха включается во все транзакции в сети, и только транзакции текущей эпохи считаются действительными. Это дополнительная мера предосторожности, поскольку в сети, устойчивой к цензуре, блокировка атак не удастся.

Как устраняются потенциальные уязвимости смарт-контрактов?

  • Нет уязвимых мест

В этих типах уязвимостей смарт-контракт застревает в состоянии, потому что функция изменения состояния требует газа, превышающего лимит газа в сети.

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

Многие вычисления доверяются валидаторам.

  • Повторные атаки

При разработке смарт-контрактов учитываются атаки повторного входа.

  • Прочие ошибки и уязвимости

Смарт-контракты будут проверяться, чтобы убедиться, что они не содержат ошибок.

Смарт-контракт / сетевая архитектура

Ниже показана упрощенная архитектура сети и смарт-контрактов. На иллюстрации показан случай, когда клиентское приложение размещено в той же цепочке блоков, что и смарт-контракты Razor Network. Случай, когда приложение находится в другой сети, не показан.

Смарт-контракты и сетевая архитектура

  1. Функции различных контрактов:

State Manager: управление состоянием сети;

Stake Manager: ставка и снятие ставок, штрафы и награды.

  1. Менеджер голосования: управление зарегистрированными голосами: фиксация и раскрытие
  2. Диспетчер блоков: создание новых блоков в сети Razor;
  3. Диспетчер заданий: очередь диспетчера контрактов ожидающих запросов и результатов обработанных запросов.
  4. Делегатор: контракт с прокси обеспечивает доступ к последнему контракту с менеджером заданий.

Как достигается требуемая масштабируемость?

Razor использует базовый блокчейн для различных функций, таких как:

  1. Достижение консенсуса на низком уровне;
  2. Хостинг смарт-контрактов EVM;
  3. Хранение данных;
  4. Защита от атак с двойным расходом;
  5. Избегает атак цензуры;
  6. Избегает атак на разделы.

Поскольку все операции и связь в Razor происходят через транзакции в цепочке блоков, базовая цепочка блоков должна быть способна обрабатывать требования к емкости в дополнение к желаемым функциям, упомянутым выше.

Как децентрализованное приложение может использовать Razor? Что такое информационный поток?

Как рынок прогнозирования может использовать Razor Network Oracle:

  1. Алиса создает новый контракт на ставки: «Кто победит на выборах в США в 2020 году?»
  2. Алиса должна заплатить «Облигацию действительности», чтобы гарантировать, что это действительный запрос. Гарантия действительности будет возвращена ей, если запрос не будет исключен как "Недействительный".
  3. Алиса ставит 1 ETH на то, что «Трамп» выиграет выборы.
  4. Боб делает ставку против Алисы, что «Эндрю» выиграет выборы.
  5. Разные пользователи могут одинаково делать ставки на разные результаты. Все ставки будут заблокированы в смарт-контракте до тех пор, пока ставки не будут рассчитаны.
  6. В контракте о ставках этот вопрос может быть задан оракулу Razor только в более поздний срок, определенный заранее. Скажем, декабрь 2020 года. А потом сделаем ставку. Это действие может быть инициировано кем угодно, но только после указанной даты.
  7. Поскольку этот запрос будет инициирован в «ручном» режиме, источник данных предоставлен не будет. Валидаторы будут вручную искать в Интернете и сообщать о победителе выборов в Razor Network.
  8. Результат будет финализирован в Razor Network после завершения цикла.
  9. После этого любой может активировать действие «урегулировать» в смарт-контракте ставок. Затем смарт-контракт ставок запросит смарт-контракт Razor, чтобы увидеть результат, а затем рассчитает ставку соответствующим образом.