До сих пор миф о благосостоянии в валютном круге/индустрии блокчейнов сохраняется, и следующим важным направлением «создания богатства» является сосредоточение внимания на «игровом треке». Проект XAI проводит мероприятие Odyssey. Если вам интересно, примите участие в моей статье на площади: Руководство для новичков по публичной сети XAI Game Odyssey Event с нулевой стоимостью
В этой статье я представлю вам подробное объяснение узла Sentry публичной сети игр XAI! Эта статья относительно техническая, поэтому, если вы заинтересованы в зарабатывании денег, вам необходимо прочитать ее внимательно. Потому что только если вы сами поймете «логику» и улучшите свое познание, у вас появится возможность зарабатывать деньги!
Если вы хотите узнать непосредственно об узле Sentry, прочитайте первую часть напрямую, не читая позже, если вам нужен логический замкнутый цикл, тогда вам нужно прочитать вторую, третью и четвертую части!
Я хочу подчеркнуть, что Xai получает прямую техническую поддержку от Offchain Labs. Такая поддержка невообразима для других сетей Orbit! и является ключевым компонентом стратегического плана игры Зая в экосистеме Arbitrum.
Часть 1: Объяснение сторожевого узла
Узел Sentry — это узел наблюдения, который отслеживает протокол объединения Xai, и если предлагается плохой блок, он подает предупреждение (любыми способами по выбору его оператора), чтобы другие могли вмешаться. Целью дозорного узла является решение дилеммы проверяющего (более подробную информацию о дилемме проверяющего см. в части IV).
Нажмите здесь, чтобы просмотреть рекламный видеоролик:
Запускайте узлы Xai и получайте жетоны Xai одним щелчком мыши!
Узлы Sentinel могут работать на ноутбуках, настольных компьютерах и даже облачных экземплярах членов сообщества. Пока узел работает, существует вероятностный алгоритм, который определяет, будет ли оператор узла вознагражден токенами esXai из сети. Делая ставку Xai, вы увеличиваете вероятность алгоритма. Если вы не знаете об esXai, примите участие в моей статье на площади: Интерпретация «токен-экономики» проекта XAI
1. Принцип работы дозорного узла
Протокол Attention Challenge v2 включает в себя несколько участников, включая цепочку Xai, родительскую цепочку (Arbitrum One), доверенного претендента, стражей Xai и их лицензионные ключи, а также контракт рефери (рефери). Претендент создает пару ключей BLS, регистрирует открытый ключ в контракте с рефери и подписывает утверждения, сделанные валидатором, в протоколе объединения Xai на Arbitrum One. Эти подписи проверяются договором судьи и записываются как возражения, связанные с претензией.
Xai Sentinels может зарегистрироваться по контракту с рефери, купив лицензионный ключ Sentinel, чтобы иметь право публиковать заявления о претензиях. Они получают корень состояния правильного оператора, который будет преемником выдавшего оператора. Если определенное условие соблюдено, они выдают заявление о заявлении, ссылаясь на контракт рефери. Если последующее заявление создано и подтверждено и Sentinel выдает правильное заявление, Sentinel свяжется с реферальным контрактом для оформления транзакции погашения. Рефери проверит несколько условий, прежде чем выплатить вознаграждение Стражу.
Этот протокол гарантирует, что каждое утверждение должно полностью использовать входящие сообщения, существовавшие на момент создания предшествующего утверждения. Это означает, что после создания утверждения корни состояний его правильных последующих утверждений полностью определены и могут быть вычислены любым узлом. Это побуждает каждого стража определить правильный корень следующего состояния. Награда дозорного определяется идентификатором разрешения состояния дозорного, корнем последующего состояния и значением запроса, которое не становится известным до тех пор, пока корень последующего состояния не будет полностью определен.
2. Кто может управлять узлом?
Любой может работать с Sentinel, загрузив программное обеспечение, установив его и запустив. Однако для получения вознаграждения в виде токенов необходимо приобрести хотя бы один лицензионный ключ Sentinel.
Покупатели должны успешно пройти проверку KYC, чтобы убедиться:
не в США
Не подлежит никаким санкциям OFAC США (OFAC отражено в санкционном списке США)
Те узлы Sentinel, которые не работают или не имеют соответствующих средств для оплаты платы за газ (GAS), не будут получать вознаграждение даже при наличии лицензионного ключа. Таким образом, операторы захотят убедиться, что их узлы финансируются, находятся в режиме онлайн и работают.
3.Рефери (рефери) Контракт
Рефери — это смарт-контракт, предназначенный для обеспечения соблюдения заранее определенных правил, проверки происхождения заявок и распределения вознаграждений победителям внутри системы. Смарт-контракт рефери — это ключевой компонент экосистемы Xai, отвечающий за управление и проверку претензий, сделанных дозорными узлами в сети. Контракт имеет несколько ключевых функций:
3.1 Подача заявления
Контракт рефери позволяет дозорным узлам подавать претензии на оспаривание. Эту функцию может вызвать только владелец лицензионного ключа Sentinel или его утвержденный адрес в этом контракте. Эта функция проверяет, открыт ли конкурс для отправки и была ли уже отправлена лицензия NodeLicense для этого конкурса.
3.2 Получайте награды
Контракт содержит функцию, которая позволяет пользователям требовать вознаграждения за успешные заявки. Эта функция проверяет, был ли запрос закрыт для отправки, и проверяет, прошел ли владелец ключа узла KYC. Если эти условия соблюдены и претензия подлежит оплате, вознаграждение будет отправлено пользователю.
3.3 Создайте хеш заявки и проверьте оплату.
В контракте есть функция, которая создает хеш идентификатора разрешения дозорного, идентификатора вызова, ChallengerSignedHash в вызове и последующего корня состояния. Затем он проверяет, находится ли хэш ниже определенного порога, который рассчитывается на основе общего количества выпущенных лицензий Sentinel. Если хэш ниже порогового значения, заявка подлежит оплате.
Контракт рефери обеспечивает целостность сети Xai, проверяя заявки и вознаграждая успешные, тем самым стимулируя дозорные узлы точно и старательно контролировать сеть.
4. Компонент «Челленджер»
Претендент — доверенная организация в экосистеме Xai. Он создает пару ключей BLS и регистрирует открытый ключ в реферальном контракте. Когда валидатор делает заявку в протоколе объединения Xai, претендент подписывает заявку, используя свой закрытый ключ, и передает подпись рефери. Рефери проверяет подпись и записывает ее как вызов, связанный с заявлением. Этот процесс обеспечивает целостность утверждений, сделанных в протоколе объединения Xai.
5. Ключ (разрешение ключа узла Sentinel на основе NFT)
Лицензионный ключ Sentinel — это уникальный невзаимозаменяемый токен (NFT), который необходим для работы узла Sentinel в сети Xai. Лицензии Sentinel служат доказательством права узлов подавать претензии и получать вознаграждения. Он чеканится путем отправки правильного количества ETH, а цена чеканки определяется системой возрастающего порога.
Лицензирование узла играет ключевую роль в арбитражном контракте. Когда узел хочет отправить заявку на вызов, он должен предоставить свой идентификатор разрешения Sentinel. Контракт рефери проверяет, действительна ли лицензия Sentinel и является ли узел владельцем лицензии Sentinel или утвержденным оператором (раздел KYC выше). Если эти условия соблюдены, заявка узла передается на вызов.
Разрешения Sentinel также играют роль при получении вознаграждения за успешные заявки. В контракте с рефери проверяется, выполнил ли владелец лицензии Sentinel KYC и имеет ли это заявление право на оплату. Если эти условия выполняются, вознаграждение отправляется владельцу лицензии Sentinel.
Таким образом, разрешение Sentinel является ключевым компонентом сети Xai, который регулирует работу узлов Sentinel, подачу заявок и распределение вознаграждений.
6. Загрузите и запустите узел.
Чтобы запустить дозорный узел, пользователям необходимо всего лишь загрузить определенный пакет программного обеспечения. Этот пакет можно использовать в настольном приложении или в качестве инструмента командной строки на вашем компьютере. Проще говоря, эти приложения представляют собой инструменты, упрощающие использование программного обеспечения Sentinel. Целью этого пакета является автоматизация всех операций, необходимых для запуска Sentinel, что делает его очень простым в настройке и использовании, даже если вы не обладаете техническими знаниями.
Этот пакет помогает пользователям решать такие задачи, как настройка, управление и взаимодействие с другими частями, а также имеет простой в использовании интерфейс, который позволяет пользователям легко просматривать и настраивать параметры. Используя этот пакет, пользователи могут больше сосредоточиться на том, как лучше работать и получать больше токенов. Пользователи могут запустить этот пакет с помощью настольного приложения или инструмента командной строки, оба из которых очень просты в использовании и делают процесс работы очень плавным.
7. Функция кошелька Sentinel
В экосистеме Xai кошелек Sentinel играет ключевую роль во взаимодействии между узлами Sentinel и смарт-контрактами рефери. Sentinel Wallet выступает в качестве агента-посредника и отвечает за отправку заявлений рефери от имени соответствующих Sentinels. Это достигается за счет специальных функций в реферальном контракте, которые может вызывать только владелец лицензионного ключа Sentinel или его утвержденный адрес в этом контракте.
Кошелек Sentinel может отправить запрос на вызов, вызвав функцию submitAssertionToChallenge в контракте рефери. Эта функция проверяет, открыт ли запрос для отправки и был ли уже отправлен ключ узла для этого вызова.
Sentry Wallet также может требовать вознаграждения за успешные заявки, вызывая функциюclaimReward в контракте рефери. Эта функция проверяет, закрыто ли задание для отправки, и проверяет, прошел ли владелец лицензии Sentinel проверку «KYC». Если эти условия соблюдены и претензия подлежит выплате, вознаграждение будет отправлено владельцу Sentinel.
Таким образом, кошелек Sentinel действует как мессенджер, облегчая взаимодействие между узлами и судьями, тем самым обеспечивая бесперебойную работу сети Xai.
8. Лицензия
Взаимосвязь между количеством лицензий и возможностями узла является фундаментальной. Хотя с узлом может быть связано несколько лицензий, важно понимать, что количество лицензий напрямую влияет на способность узла выполнять фиксацию. По сути, чтобы обеспечить справедливые квоты фиксации, соотношение лицензий и экземпляров узлов поддерживается на уровне 1:1. Следуя вышеуказанным принципам, система устанавливает структурированный подход к лицензированию, передаче прав и общей работе узлов в экосистеме.
9. Требования к программному и аппаратному обеспечению узла Sentry.
Программное обеспечение узла Sentinel поддерживает настольные компьютеры Windows, Mac и Linux (требуется 64-разрядная версия). Ниже приведены текущие ресурсы, необходимые для запуска программного обеспечения узла Sentinel для использования до 100 лицензионных ключей:
4 ГБ ОЗУ
2 ядра процессора
60 ГБ дискового пространства
Процессор x86/X64 (поддерживает процессор ARM, например чип Apple M1/M2)
Стабильное подключение к Интернету
При добавлении дополнительных ключей к узлу в идеале аппаратные возможности должны соответственно увеличиваться. Однако не обязательно назначать каждому ключу отдельный автомат. Ожидается, что система будет масштабируемой для размещения десятков ключей на одной машине, а возможно, и больше.
Примечание. Эти требования к оборудованию могут быть изменены.
10. Предполагаемое вознаграждение сети узлов Sentry
Экономическую модель токена XAI см.: Интерпретация «экономики токенов» проекта XAI
Вот три сценария оценки вознаграждений Xai, которые вы можете получить от запуска узла Sentry. Эти три сценария основаны на следующих предположениях:
Сумма XAI и esXAI никогда не превысит 2 500 000 000. Учитывая, что экосистема Xai динамична, невозможно точно предсказать ежемесячное вознаграждение в токенах за каждый ключ Sentry.
100% ГАЗа сжигается, поэтому нет никакой гарантии, что предложение всегда будет инфляционным, оно может быть дефляционным.
Фонд Xai не будет продавать более 50 000 ключей Sentry (узел может загружать несколько ключей). Ожидается, что это займет 2-3 года. Ключи охраны со временем дорожают.
Ежемесячная сумма esXAI за ключ Sentry также может колебаться в зависимости от количества участников экосистемы.
Смысл следующих трех таблиц заключается в том, что при различном обращении токенов XAI и esXAI количество ключей узлов, активированных в сети, и соответствующее ожидаемое ежемесячное вознаграждение токенов за ключ:
Оценка сценария А: если в обращении находится в общей сложности 750 000 токенов XAI и esXAI, то каждый ключ Sentry получит вознаграждение esXAI в соответствии со следующей таблицей:
Оценка сценария B: если в обращении находится в общей сложности 1 250 000 000 токенов XAI и esXAI, то каждый ключ Sentry получит вознаграждение esXAI в соответствии со следующей таблицей:
Оценка сценария C: если в обращении находится в общей сложности 2 187 500 000 токенов XAI и esXAI, то каждый ключ Sentry получит вознаграждение esXAI в соответствии со следующей таблицей:
Часть 2. XAI разрабатывается и поддерживается компанией Arbitrum (ARB), поэтому нам нужно пролить свет на архитектуру Arbitrum:
1. Нитро решение
Все цепочки Arbitrum построены на Arbitrum Nitro, которая является базовой технологией для всех цепочек в экосистеме. Nitro запускает разветвленную версию Geth и использует WebAssembly в качестве базовой виртуальной машины, защищенной от мошенничества.
2.Любое доверительное решение
Anytrust — это протокол Arbitrum, который управляет доступностью данных через группу лицензиаров, называемую Комитетом по доступности данных (DAC). Этот протокол снижает комиссию за транзакцию за счет введения дополнительного предположения о доверии в отношении доступности данных вместо использования механизма ненадежной доступности данных Ethereum.
3. Знакомство с уровнями Arbitrum 2, которые вы, возможно, знаете
Arbitrum Nova — это пример цепочки AnyTrust; Arbitrum One — еще одна альтернативная цепочка, которая реализует чисто не требующий доверия (и более интенсивно использующий газ L1) протокол Arbitrum Rollup. Обе цепи построены на Nitro.
4. Цепь орбит
Arbitrum Orbit позволяет третьим лицам создавать свои собственные самоуправляемые цепочки Arbitrum Rollup и AnyTrust. Arbitrum предлагает технологии Rollup и AnyTrust для максимальной гибкости при построении цепочек Orbit. Как и все сети в экосистеме Arbitrum, как Arbitrum Rollups, так и цепочка Arbitrum Anytrust Orbit построены с использованием Nitro в качестве базовой технологии.
5. Поймите основную ситуацию в Шае.
Давайте поймем Зая в приведенном выше контексте. Xai работает как сеть Arbitrum Orbit, используя технологию Anytrust для максимальной скорости и минимальных затрат. В отличие от большинства «самоуправляемых» сетей Orbit, Xai пользуется прямой технической поддержкой со стороны Offchain Labs. Такая поддержка невообразима для других сетей Orbit! и является ключевым компонентом стратегического плана игры Зая в экосистеме Arbitrum.
Часть 3. После того, как вы ознакомились с вышеизложенными концепциями, давайте глубже разберемся в архитектуре:
1.AnyTrust: революционная инфраструктура блокчейна
В рамках AnyTrust и в качестве передового варианта технологии Arbitrum Nitro Offchain Labs использует инновации для решения некоторых из наиболее насущных проблем в пространстве блокчейнов. AnyTrust открывает нам новую перспективу, включив легкие предположения о доверии, что значительно снижает затраты, обеспечивая при этом надежную доступность и безопасность данных.
2. Сокращение затрат за счет допущений о доверии
В основе протокола Arbitrum все узлы Arbitrum (включая валидаторов, которые проверяют правильность цепочки и ставят на кон точные результаты) должны иметь доступ к данным каждой транзакции второго уровня (L2) в почтовом ящике цепочки Arbitrum. Традиционно объединение Arbitrum обеспечивает доступ к данным путем публикации данных в виде данных вызова на первом уровне (L1) Ethereum, процесса, который генерирует значительные комиссии за газ Ethereum, что является основным компонентом затрат в Arbitrum.
3. Гибкость кетсетов
Кетсеты играют ключевую роль в архитектуре AnyTrust. В них указываются открытые ключи членов комитета и количество подписей, необходимых для проверки сертификата доступности данных (DACert). Наборы Ketsets обеспечивают гибкость при смене членов комитета и позволяют членам комитета обновлять свои ключи по мере необходимости.
4. Сертификаты доступности данных (DACerts).
В AnyTrust основной концепцией является сертификат доступности данных (DACert). DACert состоит из хеша блока данных, срока действия и доказательства того, что члены комитета N-1 подписали пару (хеш, время истечения). Это доказательство включает в себя хэш набора ключей, использованного для подписи, растровое изображение, указывающее, какие члены комитета подписали, и совокупную подпись BLS на кривой BLS12-381, подтверждающую подписавшего.
Благодаря предположению о доверии 2 из N, DACert служит доказательством того, что данные блока будут доступны хотя бы одному честному члену комитета до истечения указанного срока действия. Это предположение о доверии является основой надежности и безопасности доступности данных в рамках AnyTrust.
5.Двойной механизм выпуска данных
AnyTrust представляет двойной метод публикации блоков данных на уровне L1. В дополнение к традиционному методу публикации полных блоков данных он также позволяет выдавать DACerts — сертификаты, подтверждающие доступность данных. Контракт входящего почтового ящика L1 проверяет действительность DACerts, включая ссылку на действительные Kesets, указанные в DACert.
Код L2, отвечающий за чтение данных из папки «Входящие», предназначен для беспрепятственной обработки обоих форматов данных. При обнаружении DACert он выполняет проверки действительности, включая проверку соответствия количества подписывающих лиц требованиям Ketsets, проверку совокупных подписей и подтверждение истечения срока действия после текущей временной метки L2. Действительные DACerts гарантируют, что блок данных доступен и может быть использован кодом L2.
6. Сервер доступности данных (DAS).
Члены комитета управляют сервером доступности данных (DAS), который предоставляет два ключевых API:
(1) API-интерфейс сортировщика: этот интерфейс JSON-RPC, предназначенный для использования сортировщиком цепочки Arbitrum, позволяет сортировщику отправлять блоки данных в DAS для хранения.
(2) REST API: протокол RESTful на основе HTTP(S), разработанный для более широкой доступности, позволяет извлекать фрагменты данных через хэш. Он полностью кэшируется и может быть развернут в сочетании с прокси-серверами кэширования или CDN для повышения масштабируемости и защиты от потенциальных DoS-атак.
7. Взаимодействие сортировщика и комитета
Когда сортировщик Arbitrum намеревается опубликовать пакет данных через комитет, он отправляет данные и время истечения срока действия всем членам комитета параллельно через RPC. Каждый член комитета сохраняет данные, подписывает пару (хэш, срок действия), используя свой ключ BLS, и возвращает подпись и индикатор успеха секвенатору. Как только собрано достаточное количество подписей, секвенсор объединяет их, чтобы создать действительный DACert для пар (хэш, срок действия). Этот DACert затем публикуется в контракте входящих сообщений L1, что делает его доступным для программного обеспечения цепочки AnyTrust L2. В случае, если секвенатор не может собрать достаточное количество подписей в течение указанного периода времени, он применяет стратегию «возврата к объединению» и публикует полные данные непосредственно в цепочке L1. Программное обеспечение L2 превосходно понимает оба формата публикации данных (через DACert или полные данные) и соответствующим образом обрабатывает каждый формат. Подводя итог, AnyTrust, как революционная инновация в экосистеме Offchain Labs, представляет собой важнейший прогресс в обеспечении доступности данных, безопасности и экономической эффективности инфраструктуры блокчейна. Благодаря разумному предположению о доверии и новому подходу к публикации данных AnyTrust прокладывает путь к более масштабируемым, доступным и безопасным решениям на основе блокчейна.
Часть 4. Учитывая вышеизложенные концепции, давайте теперь объясним, почему важны сторожевые узлы: проблема проверки мошенников, почему дилемма валидатора сложнее, чем вы думаете, и решение!
Автор — Эд Фельтен, главный научный сотрудник Arbitrum.
В системах блокчейна общий шаблон проектирования заключается в том, что одна сторона выполняет некоторую работу и депонирует залог за правильное поведение, а затем предлагает другим проверить работу и забрать этот залог, если они поймают работника на мошенничестве. Вы могли бы назвать это шаблоном проектирования «утверждение-вызов». Мы делаем это в Arbitrum и недавно видели в новостях такие предложения, как Optimistic Rollup.
На эти системы может повлиять дилемма валидатора, которая, по сути, заключается в том, что нет смысла проверять чью-либо работу, если вы знаете, что они не будут жульничать, но если вы не проверите, у них есть стимул жульничать; Если вы дизайнер, вы хотите доказать, что ваша система совместима со стимулами, а это означает, что если все будут вести себя последовательно в соответствии со своими стимулами, мошенничества не произойдет. Это та область, где интуиция может подвести вас неправильно. Эта проблема гораздо сложнее, чем кажется, как мы увидим, когда раскроем стимулы сторон ниже.
Супер простая модель
Начнем с построения самой простой модели, какую только сможем. Предположим, есть два игрока. Утверждающий делает утверждение, которое может быть истинным или ложным. Проверяющий может проверить утверждение утверждающего или может ничего не делать, предположительно исходя из предположения, что утверждающий, вероятно, говорит правду. Мы предполагаем, что стоимость проверки для проверяющего равна C. Если проверяющий проверит и обнаружит, что утверждающий жульничал, он получит вознаграждение в размере R. (R включает в себя все выгоды, получаемые экзаменатором от обнаружения мошенничества. Сюда входят преимущества, реализованные «вне системы», а также любые преимущества, полученные благодаря возросшему доверию к системе.) Если утверждающий не был пойман, при мошенничестве проверяющий проигрывает. L, например потому, что мошеннический утверждающий может обманным путем забрать ценные предметы из проверяющего.
Теперь у нас есть две угрозы, о которых стоит беспокоиться: взяточничество и лень. Подкуп — это возможность того, что утверждающий может подкупить проверяющего, чтобы тот не проверял, тем самым позволяя утверждающему обмануть, не будучи обнаруженным. Мы можем предотвратить это, гарантируя, что утверждающий депонирует очень большой депозит, превышающий общую сумму в системе, и платит проверяющему при обнаружении мошенничества, так что утверждающий не желает платить больше, чем вознаграждение проверяющего R взятка. Это позволит предотвратить взяточничество, но требует полного обеспечения системы, что может стоить очень дорого.
Другая угроза — лень, риск того, что проверяющий решит не проверять работу ассертера. (Помните, что шашки могут говорить, что они делают чек, но на самом деле этого не делают.) Давайте посмотрим на стимулы для шашек, чтобы увидеть, является ли это разумной стратегией.
Предположим, что утверждающий обманывает с вероятностью X. Теперь утилита инспектора выглядит следующим образом:
Если рецензент проверяет: RX-C
Если шашка не проверяет: -XL
Проверка имеет смысл только в том случае, если полезность проверки больше, чем полезность непроверки, то есть если X > C/(R+L). Вот и плохие новости: утверждающий может жульничать случайным образом с вероятностью меньше, чем C/(R+L), рациональный проверяющий никогда не сделает чек, поэтому утверждающий никогда не будет уличен в мошенничестве.
Давайте подставим несколько цифр. Если стоимость проверки каждой транзакции составляет 0,10 доллара США, и проверяющая сторона получает награду в размере 75 долларов США, если обнаруживает мошенничество, но теряет 25 долларов США, если ему не удается обнаружить мошенничество, то проверяющий может безнаказанно обманывать тысячу раз. Если мы хотим, чтобы эта система выполняла тысячи транзакций, у нас возникает большая проблема. Очевидно, что в этой модели мы ничего не можем сделать, чтобы свести вероятность мошенничества к нулю. Мы можем только надеяться на систему с чрезмерным обеспечением, в которой знаменатель C/(R+L) станет больше.
Это удивительно надежный результат – в плохом смысле. Оно совершенно не зависит от стимулов утверждающего. Пока проверяющий получает ненулевое преимущество от успешного мошенничества, он может делать это с некоторой вероятностью, зная, что проверка не стоит усилий проверяющего. Этот результат также не зависит от того, сколько времени мы даем инспектору на выполнение работы или платим ли мы за (предполагаемого) инспектора. Возможно, вы сейчас думаете: проблема в том, что инспектор только один. Снизит ли добавление большего количества шашек вероятность мошенничества? Удивительно, но это не так.
Добавление цензоров не помогает предотвратить мошенничество
Опять же, сформулируем простейшую модель. Сейчас два инспектора действуют независимо. Каждый проверяющий платит C, если он проверяет, и если кто-то делает чек и ловит жульничество утверждающего, вознаграждение R выплачивается успешному проверяющему, или, если они оба делают чек, вознаграждение делится поровну между ними. (Если хотите, вы можете дать одному из них случайную полную награду в размере R в случае, если все они сделают чек. Это не повлияет ни на чью-либо стратегию, ни на результаты.) Как и раньше, каждый шашка потеряет L, если утверждающий жульничает, не получив пойманный.
Остается так, что если утверждающий обманывает меньше, чем C/(R+L) за раз, то проверяющему не имеет смысла проверять, поскольку полезность проверки меньше, чем полезность непроверки. На самом деле, проблема со стимулами усугубляется, чем раньше, потому что стоимость проверки на одного проверяющего по-прежнему равна C, но ожидаемое вознаграждение за успешную проверку мошенничества меньше R, потому что вознаграждение иногда необходимо разделить - ожидаемое вознаграждение будет быть в R/2 и R. Если ожидаемая награда равна bR, где b находится между 0,5 и 1, то утверждающий может жульничать до времени C/(bR+L) – это более незамеченный обман, чем если бы была только одна шашка! (Математика немного усложняется, поскольку значение b зависит от стратегии шашки, а его стратегия зависит от b, но должно быть ясно, что иногда им придется разделить награду. Кроме того, эффективное значение L также уменьшается. , так как шашки не могут потерять свою L из-за проверки другими шашками).
Единственное место, где добавление цензоров могло бы действительно помочь, — это предотвращение взяточничества. При наличии двух шашек утверждающий должен заплатить взятку в размере более R каждому утверждающему, что делает взятку вдвое дороже и позволяет сделать ставку в размере 50% вместо полной ставки. Но компромисс в том, что количество мошенничества увеличивается.
Я не буду здесь вдаваться во всю математику, но при разумных предположениях увеличение количества шашек с одной до двух может привести к увеличению количества необнаруженных мошенничеств на 50%.
Добавление цензоров только ухудшает ситуацию!
Вы можете добавить больше шашек, и ситуация станет еще хуже. По мере увеличения количества проверяющих проверяющему приходится больше беспокоиться о разделении вознаграждения несколькими способами, поэтому ожидаемое вознаграждение за каждую успешную проверяющую постепенно уменьшается, в результате чего вероятность того, что утверждающий совершит безопасный обман, постепенно увеличивается. С этой точки зрения, худший сценарий заключается в том, что каждый человек в мире может стать цензором. Это не так уж и плохо, поскольку по мере увеличения количества цензоров ситуация становится еще хуже, но это определенно не поможет предотвратить мошенничество, даже если эффективно устранит риск взяточничества.
Вы уверены, что ваша система совместима со стимулами?
Если у вас есть система, которая соответствует модели такого типа, и вы считаете, что она совместима со стимулами, вам нужно тщательно подумать, почему. В частности, вам необходимо объяснить, почему проверяющий будет выполнять работу по проверке, даже если он считает, что проверяющий вряд ли обманет. Просто большого наказания за мошенничество недостаточно. Просто получить награду за поимку мошенников недостаточно. Просто иметь много шашек недостаточно – на самом деле, это может еще больше усугубить ситуацию. Почему ваша система невосприимчива?
Эта проблема применима к таким системам, как Optimistic Rollup. Когда мы говорим об Арбитруме, это относится и к нам.
Принимая во внимание вышеизложенное, традиционные методы стимулирующей проверки не дают желаемых результатов — существует базовый уровень мошенничества, ниже которого проверяющие сочтут проверку нецелесообразной. В заключение:
Есть два игрока: утверждающий, который выдвигает утверждение, независимо от того, истинно оно или ложное, и проверяющий, который может проверить утверждение с некоторыми вычислительными затратами. Если проверяющий делает чек, его полезность равна RX-C, если он не делает чек, его полезность равна -XL, где R — награда за обнаружение мошенничества, C — стоимость проверки, а L — проигрыш проверяющего из-за необнаружения мошенничества. , X — вероятность мошенничества утверждающего (выбранная утверждающим). Некоторые алгебраические упражнения показывают, что если
Чтобы решить эту проблему и создать ситуацию, когда рецензент, движимый стимулами, всегда будет проверять, мы должны изменить стимулы рецензента. Основная проблема заключается в том, что в исходной модели все положительные стимулы для шашек делать чек пропорциональны Если мы хотим, чтобы стимул проверки действовал независимо, нам нужно создать стимул проверки или препятствие для отказа от проверки, которое не зависит от действий утверждающего.
TrueBit пытается сделать это, добавляя к набору утверждений намеренно ложные утверждения, по существу заменяя X на X плюс константу. Есть некоторые проблемы с этим подходом. (В оригинальном документе Arbitrum есть раздел, посвященный проблемам мотивации TrueBit.)
Сосредоточьтесь на проблемах
Мы используем другой подход, который мы называем сосредоточением на задаче. Идея состоит в том, что если утверждающий вычисляет значение f(x), он сначала выдает x и криптографический запрос. Чтобы правильно ответить на задачу, экзаменатору необходимо знать f(x). Только после того, как вызов произошел, проверяющий публикует f(x) — к этому моменту проверяющий модуль уже проделал тяжелую работу по вычислению f(x), поэтому у него нет стимула лениться. (Более подробная информация о соглашении приведена ниже.)
Чтобы уменьшить количество необходимых для этого внутрисетевых транзакций, мы устроим все так, чтобы правильным ответом на запрос проверяющего лица обычно была тишина. Но в редких случаях чекеру приходится публиковать в цепочке очень небольшую транзакцию. Если шашка даст неправильный ответ – молчание, когда ее следует отпустить, или молчание, когда ее следует отпустить – она потеряет небольшой депозит.
Давайте адаптируем исходную модель стимулирования, включив в нее проблемы с вниманием. Нам нужны два новых параметра (оба из которых мы можем выбрать): P — процент времени, в течение которого проверяющий публикует правильный ответ, и A — штраф, если проверяющий дает неправильный ответ. Теперь полезность инспектора:
Если отмечено: RX-C
Если нет, проверьте: -LX-PA
Ключевое наблюдение заключается в том, что пока PA > C, проверка является оптимальной стратегией, независимо от того, какова X (вероятность мошенничества).
Очень низкая стоимость
Чтобы оценить стоимость, рассмотрим конкретный пример. Предположим, утверждение выполняется каждые пять минут, а стоимость проверки составляет 0,001 доллара США. Если мы установим вероятность P равной 0,3%, чекеру придется внести депозит в размере 3 долларов. Теперь затраты чекера на одно утверждение составляют 0,0003 доллара США за газ (плата за газ 0,10 доллара за публикацию немолчаливого ответа, умноженная на вероятность 0,3%, которую он должен опубликовать), плюс около 0,0003 доллара за блокировку ставки в 3 доллара на пять минут. Стоимость процентов составляет 0,0006 доллара США за утверждение.
Расширение для нескольких инспекторов
Задача фокусировки хорошо масштабируется при участии нескольких экзаменаторов. Протокол выдает запрос, который по-разному влияет на каждую проверяющую программу, заставляя каждую проверяющую программу вычислять f(x) самостоятельно. Каждая проверка будет иметь одинаковую стоимость (в нашем случае 0,0006 доллара США за утверждение).
В открытой системе каждый имеет право проверять расчеты, и вы можете разрешить любому зарегистрироваться в качестве проверяющего и внести необходимый небольшой депозит. Это даст им право на получение внимания и потенциально на получение компенсации от разработчиков децентрализованных приложений. Любой может оспорить неверные утверждения утверждающего, но только зарегистрированные эксперты сталкиваются с проблемами внимания.
Технические детали соглашения
Теперь, когда мы понимаем, какую пользу нам может принести сосредоточенность на задачах, давайте углубимся в технические детали того, как они работают.
Каждая проверка имеет закрытый ключ k и соответствующий открытый ключ gᵏ, определенные в соответствующей группе. Открытый ключ каждой шашки известен всем. Мы также будем полагаться на подходящую хеш-функцию H.
Чтобы бросить вызов вычислению f(x), где функция f известна заранее, утверждающий генерирует случайное значение r, а затем выдает (x, gʳ) в качестве вызова.
Чекер, обладающий закрытым ключом k, должен ответить на вызов публикацией небольшой транзакции только в том случае, если H(gʳᵏ, f(x)) < T, где T — подходящее выбранное пороговое значение. Обратите внимание, что только утверждающий (который знает r) и этот конкретный проверяющий (который знает свой закрытый ключ k) могут вычислить хеш, поскольку они единственные, кто может вычислить gʳᵏ. Также обратите внимание, что для расчета хеша необходимо знать f(x).
После того, как у проверяющих будет некоторое время, чтобы опубликовать свои ответы на запрос, утверждающий может опубликовать свое f(x), и если какой-либо проверяющий не согласен с ним, он будет оспорен как обычно. На этом этапе утверждающий может обвинить любого проверяющего в неправильных ответах; утверждающий должен ввести r, чтобы обосновать свое обвинение; Майнер или контракт может проверить правильность обвинения и наказать нарушителя, но если утверждение утверждающего о f(x) в конечном итоге не будет принято как правильное, обвинение будет проигнорировано; Если какой-либо чекёр будет оштрафован, истец получит половину конфискованных средств, а другая половина будет уничтожена.
Такой подход дает экзаменатору правильные стимулы. Чтобы узнать, как проверяющий должен реагировать на вызов, необходимо знать закрытый ключ этого проверяющего и f(x), поэтому каждый проверяющий захочет вычислить f(x). Если программа проверки сама не вычислит f(x), она не сможет безопасно обеспечить соблюдение протокола. Ответы других проверяющих бесполезны для определения f(x), поскольку они полагаются на закрытые ключи этих проверяющих. Если программа проверки полагается на то, что кто-то другой сообщает ей f(x), у нее нет возможности проверить заявленное значение (кроме самого вычисления f(x)), и программа проверки рискует быть оштрафованной, если оно окажется неправильным. У одной стороны даже есть стимул попытаться ввести проверяющего в заблуждение относительно f(x) - это утверждающий, который получает прибыль от ошибки проверяющего и может использовать эту прибыль для подкупа «друзей» проверяющего, чтобы те предоставили проверяющему неверную информацию. .
Оптимизация и заключение
Есть несколько приемов, которые сделают этот протокол более эффективным. Например, мы могли бы объединить утверждение со следующим вызовом в транзакцию в цепочке, чтобы этот вызов не увеличивал количество транзакций. Если P невелико (например, 0,3% в нашем примере) и количество проверяющих не очень велико, то проверяющим редко приходится записывать транзакции в цепочку, поэтому общее влияние протокола на количество транзакций в цепочке будет быть самым маленьким.
При разумной реализации стоимость этого протокола должна быть очень низкой по сравнению с первоначальными затратами на выдачу утверждений в цепочке. В нашем случае добавление проблем внимания к существующему протоколу проверки утверждений увеличивает общую стоимость менее чем на 1%.
И выгоды значительны — мы получаем совместимый с стимулами протокол проверки, невосприимчивый к дилемме валидатора. Пока хотя бы одна проверяющая является рациональной, утверждения утверждающего всегда будут проверяться.
Дополнительную информацию о проекте можно найти по адресу: Публичная сеть игр Xai: база данных Binance Square
