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

Что такое оракловая сеть?

Оракловая сеть - это набор участников (или узлов/операторов), которые доставляют набор данных вне цепи в целевую сеть. Эти данные могут включать цену на определенный актив, ответ на заданный вопрос или практически любой тип информации. Можно представить себе протокол, в котором каждый участник представляет свою версию данных отдельно, но такой подход связан с определенными проблемами и ограничениями как для протокола, так и для его участников.

Представим систему ценовых оракулов, в которой любой участник может представить свою версию цены. Предположим, что время в этой системе делится на эпохи, а цена в течение эпохи агрегируется в смарт-контракте целевой сети просто как среднее значение представленных цен. Перед этой системой стоят две важные проблемы: быстродействие и безопасность. Если количество участников не ограничено и к ним не предъявляется никаких требований, злоумышленник может создать достаточно большое количество узлов и представить свою версию цены, в результате чего среднее значение будет близко к желаемой злоумышленником цене. Как уже отмечалось, иногда система включает проверку на максимальную разницу между представленными данными; в таких случаях злоумышленник может представить широкий диапазон данных, в результате чего система вообще не предоставит никакой цены. Если таких проверок нет, злоумышленник может эффективно достичь любой желаемой средней цены, используя большое количество узлов. Проблемы в сетях Oracle По этой причине не рекомендуется разрешать любому желающему подавать данные в систему. Эту проблему можно решить, ограничив количество участников сети. Многие протоколы просто используют белый список; однако их число также можно ограничить, потребовав определенную долю операторов.

Система хранилищ Symbiotic

Symbiotic, со своей стороны, предлагает гибкую систему хранилищ, с которой сеть может взаимодействовать для определения ставок операторов. На рисунке секция, связанная с контрактами Symbiotic, выделена зеленым цветом. Важным вопросом является то, где хранится информация об этих ставках. Мы рассмотрим ситуацию, когда ставка сети (в случае Symbiotic она находится на Ethereum) и целевая сеть для отчетов не обязательно совпадают (в случаях, когда они совпадают, учет ставок не является сложной задачей). В глобальном масштабе существует два варианта учета доли: 1. Учет кола во время принятия отчета. 2. Учет доли при формировании отчета. Давайте рассмотрим каждый из этих вариантов:

Метод 1: Учет при принятии отчета Первый вариант - учет долей операторов в целевой сети.

На основе этих ставок может быть принято решение о принятии или отклонении отчета. В некоторых реализациях (если агрегация данных происходит в целевой сети) часть данных из отчета может не использоваться, если оператор, предоставивший отчет, не имеет достаточной доли. Кроме того, вместе с отчетом может передаваться информация о самих операторах, что также зависит от протокола. Вопрос передачи информации о ставках в целевую сеть является наиболее важным в данном варианте решения. В зависимости от реализации, для этого может быть задействована либо доверенная сторона, либо высокозащищенный мост. Также можно не проверять это в явном виде, а в будущем использовать доказательства мошенничества для проверки того, что оператор подал отчет, не имея на это права. Давайте рассмотрим эту проблему с точки зрения сети Ethereum. Операторы подключаются к хранилищам и сети с помощью контрактов OptInService. В некоторых случаях сеть должна дополнительно регистрировать операторов в своем промежуточном ПО. Это программное обеспечение также предоставляет информацию о текущих ставках операторов.

Метод 2: Учет при формировании отчета

Второй вариант заключается в учете текущей доли операторов при формировании отчета. Для этого, скорее всего, потребуется некий механизм консенсуса между операторами. В процессе получения отчетов операторы обмениваются информацией, а также изучают ставки других операторов (например, с помощью легкого клиента). Целевая сеть получает либо набор ответов операторов, либо окончательный результат вместе с агрегированной подписью.

Механизмы сбрасывания

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

Основная сложность здесь заключается в определении правил слэшинга. Для произвольных типов данных слэш за некорректную отчетность довольно сложен, поскольку доказать на цепочке, что отчет был некорректным, практически невозможно. Однако для некоторых типов отчетов это все же можно сделать. Например, если отчет относится к определенному состоянию в другой сети, можно создать систему доказательства мошенничества, которая будет слэшировать оператора либо во время формирования отчета, либо после. Кроме того, правила слэшинга могут быть введены на уровне консенсуса (за неверные данные, если это возможно, или за действия оператора без достаточной доли и т. д.).

Ключевые моменты реализации

В этом посте мы рассмотрели высокоуровневую реализацию оракула с помощью Symbiotic, которая соответствует нескольким ключевым моментам:

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

2. Для интеграции Symbiotic в ваш протокол необходимо создать промежуточное программное обеспечение, включающее компонент, отвечающий за выбор и планирование валидаторов (набор валидаторов). Это позволит командам операторов понимать, когда они могут работать в сети и при каких условиях. Кроме того, важно продумать, как операторы будут получать доступ к этой информации: путем передачи в другую сеть, создания легкого клиента и т. д.

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

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