Razor Network

Особенности Razor Network (RAZOR)

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

Характеристики

Истинная децентрализация. Сквозная децентрализованная сеть Oracle без централизованных узких мест.
Безопасность. Механизм эскалации и разрешения споров делает его чрезвычайно устойчивым к сговорам, подкупу и цензуре.
Скорость. Автоматическое получение данных без ущерба для безопасности и децентрализации.
Масштабируемость. Развертывается в масштабируемой сети и не зависит от блокчейна.
Доказательство доли владения. Обеспечивается высокоэффективной сетью Proof of Stake со строгими штрафами за проступки.

Есть у Razor Network свой блокчейн?

Razor Network - это алгоритм консенсуса Proof of Stake, который достигает консенсуса по значениям оракула с помощью алгоритма «истина за консенсусом». Razor Network не зависит от блокчейна и может работать в любой сети, совместимой с Ethereum.

Описание Razor Network

Razor Network предназначен для обеспечения децентрализованного, надежного, быстрого и масштабируемого способа предоставления внешних данных для смарт-контрактов. Все, что предоставляет внешние данные в цепочку блоков, называется «Oracle».

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

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

Цели Razor Network

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

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

Атака захвата путем контроля над большинством валидаторов
Нападение взяткой
Атака сигналом о взятке
Предоставление недействительного или скомпрометированного источника данных
Недействительные запросы к оракулу
Цензура отчетов честных валидаторов.

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

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

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

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

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

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

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

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

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

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

Razor утверждает, что поощряет децентрализацию протокола следующими способами:

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

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

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

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

Это позволяет 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. Случай, когда приложение находится в другой сети, не показан.

Архитектура смарт-контрактов и сетевая архитектура Razor Network

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

State Manager: управление состоянием сети
Stake Manager: ставка и снятие ставок, штрафы и награды
Менеджер голосования: управление зарегистрированными голосами: совершает и раскрывает
Диспетчер блоков: создание новых блоков в сети Razor
Диспетчер заданий: очередь диспетчера контрактов ожидающих запросов и результатов обработанных запросов.
Делегатор: контракт с прокси-сервером обеспечивает доступ к последнему контракту с менеджером заданий.

Различные служебные библиотеки, контракты хранения и интерфейсы не показаны для ясности.

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

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

Достижение консенсуса на низком уровне
Хостинг смарт-контрактов EVM
Хранить данные
Защита от атак с двойным расходом
Избегайте атак цензуры
Избегайте атак на разделы, затмения и т.д.

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

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

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

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