Поки що міф про добробут у валютному колі/індустрії блокчейнів триває, і наступна важлива сфера «створення багатства» зосереджена на «ігровому треку». Проект XAI проводить подію Odyssey. Якщо ви зацікавлені, візьміть участь у цій моїй статті на квадраті: Посібник для початківців у публічній мережі XAI Game Odyssey Zero-Cost.
У цій статті я надаю вам детальне пояснення вузла Sentry публічного ланцюга гри XAI! Ця стаття є відносно технічною, тому, якщо ви зацікавлені в тому, щоб заробляти гроші, ви повинні прочитати її уважно. Тому що тільки якщо ви самі розумієте «логіку» і вдосконалюєте свої знання, ви можете мати можливість заробляти гроші!
Якщо ви хочете побачити безпосередньо вузол Sentry, прочитайте безпосередньо першу частину, не читаючи пізніше, якщо вам потрібен логічний замкнутий цикл, вам потрібно прочитати другу, третю та четверту частини!
Я хочу підкреслити, що Xai отримує пряму технічну підтримку від Offchain Labs. Таку підтримку неможливо уявити для інших мереж Orbit! і є ключовим компонентом стратегічного ігрового плану Xai в екосистемі Arbitrum.
Частина 1: Пояснення сторожового вузла
Вузол Sentry — це вузол спостереження, який відстежує протокол зведення Xai, і якщо запропоновано пошкоджений блок, він подасть сповіщення (будь-яким способом на вибір оператора), щоб інші могли втрутитися. Метою дозорного вузла є розв’язання дилеми верифікатора (див. Частину IV для детальної інформації про дилему верифікатора).
Натисніть тут, щоб переглянути рекламне відео:
Запустіть вузли Xai та отримуйте токени Xai одним клацанням миші!
Вузли Sentinel можуть працювати на ноутбуках, настільних комп’ютерах або навіть у хмарних інсталяціях учасників спільноти. Поки вузол працює, існує ймовірнісний алгоритм, який визначає, чи отримає оператор вузла винагороду токенами esXai від мережі. Ставлячи Xai, ви збільшуєте ймовірність алгоритму. Якщо ви не знаєте про esXai, візьміть участь у моїй статті на площі: Інтерпретація «токенної економіки» проекту XAI
1. Принцип роботи дозорного вузла
Протокол Attention Challenge v2 передбачає участь кількох учасників, включаючи ланцюг Xai, батьківський ланцюг (Arbitrum One), довіреного претендента, Xai sentinels та їхні ліцензійні ключі, а також контракт Referee (рефері). Претендент створює пару ключів BLS, реєструє відкритий ключ у контракті судді та підписує претензії, зроблені валідатором у протоколі зведення Xai на Arbitrum One. Ці підписи перевіряються контрактом арбітра та записуються як оскарження, пов’язані з позовом.
Xai Sentinels може зареєструватися за контрактом арбітра, придбавши ліцензійний ключ Sentinel, щоб мати право публікувати заяви про претензії. Вони отримують корінь стану правильного оператора, який буде наступником оператора видачі. Якщо виконується певна умова, вони видають заяву про заяву, посилаючись на договір рефері. Якщо буде створено та підтверджено додаткову заяву, і Sentinel видає правильну заяву, Sentinel зв’яжеться з референтом контракту, щоб оформити транзакцію викупу. Рефері перевірить кілька умов, перш ніж виплатити винагороду Sentinel.
Цей протокол гарантує, що кожна претензія має повністю використовувати повідомлення вхідних повідомлень, які існували на момент створення попередньої претензії. Це означає, що після створення претензії корені стану її правильних наступних претензій повністю визначені та можуть бути обчислені будь-яким вузлом. Це заохочує кожного дозорного визначити правильний наступний корінь стану. Винагорода дозорного визначається ідентифікатором дозволу стану дозорного, наступним коренем стану та значенням виклику, яке стає відомим лише після повного визначення наступного кореня стану.
2. Хто може керувати вузлом?
Будь-хто може керувати Sentinel, завантаживши програмне забезпечення, встановивши його та запустивши. Однак, щоб отримати символічні винагороди, необхідно придбати принаймні один ліцензійний ключ Sentinel.
Покупці повинні успішно пройти перевірку KYC, щоб переконатися, що вони:
не в Сполучених Штатах
Не підпадає під санкції OFAC США (OFAC відображено в списку санкцій США)
Ті вузли Sentinel, які не працюють або не мають відповідних коштів для сплати зборів за газ (GAS), не отримуватимуть винагороди, навіть за наявності ліцензійного ключа. Таким чином, оператори захочуть переконатися, що їхні вузли фінансуються, онлайн і працюють.
3.Суддівський (суддівський) договір
Referee — це смарт-контракт, призначений для забезпечення дотримання попередньо визначених правил, перевірки походження поданих заявок і розподілу винагород переможцям у системі. Смарт-контракт рефері є ключовим компонентом екосистеми Xai, відповідальним за керування та підтвердження претензій, зроблених дозорними вузлами в мережі. Договір виконує кілька ключових функцій:
3.1 Подання заяви
Договір рефері дозволяє дозорним вузлам подавати претензії на виклики. Цю функцію може викликати лише власник ліцензійного ключа Sentinel або його затверджена адреса в цьому контракті. Ця функція перевіряє, чи виклик все ще відкритий для подання та чи NodeLicense вже подано для цього виклику.
3.2 Отримувати винагороди
Контракт містить функцію, яка дозволяє користувачам вимагати винагороди за успішні претензії. Ця функція перевіряє, чи виклик закрито для подання, і перевіряє, чи власник ключа вузла завершив KYC. Якщо ці умови дотримано і претензія придатна для оплати, винагороду буде надіслано користувачеві.
3.3 Створіть хеш вимоги та перевірте платіж.
У контракті є функція, яка створює хеш ідентифікатора дозорного дозволу, ідентифікатора виклику, challengerSignedHash у виклику та подальшого кореня стану. Потім він перевіряє, чи хеш є нижчим за певне порогове значення, яке розраховується на основі загальної кількості ліцензій Sentinel, які були викарбувані. Якщо хеш нижчий за порогове значення, претензія має право на виплату.
Договір рефері забезпечує цілісність мережі Xai, перевіряючи претензії та винагороджуючи успішні, тим самим спонукаючи дозорні вузли точно й ретельно контролювати мережу.
4. Компонент Challenger
Претендент є довіреною організацією в екосистемі 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 виступає в якості агента-посередника та несе відповідальність за подання звітів судді від імені відповідних Sentinels. Це досягається завдяки спеціальним функціям у контракті референта, які може викликати лише власник ліцензійного ключа Sentinel або його затверджена адреса в цьому контракті.
Гаманець Sentinel може надіслати заяву на виклик, викликавши функцію submitAssertionToChallenge у контракті рефері. Ця функція перевіряє, чи виклик ще відкритий для подання та чи ключ вузла вже подано для цього виклику.
Гаманець Sentry Wallet також може вимагати винагороди за успішні претензії, викликаючи функцію claimReward у контракті рефері. Ця функція перевіряє, чи виклик закрито для подання, і перевіряє, чи пройшов власник ліцензії Sentinel перевірку «KYC». Якщо ці умови дотримано і претензія придатна для оплати, винагороду буде надіслано власнику Sentinel.
Таким чином, Sentinel Wallet діє як месенджер, полегшуючи взаємодію між вузлами та арбітрами, забезпечуючи тим самим безперебійну роботу мережі Xai.
8. Ліцензія
Зв'язок між кількістю ліцензій і можливостями подачі даних вузла є фундаментальним. Хоча вузол може мати декілька пов’язаних ліцензій, важливо розуміти, що кількість ліцензій безпосередньо впливає на здатність вузла здійснювати зобов’язання. По суті, щоб забезпечити справедливі квоти фіксації, співвідношення ліцензій до екземплярів вузла підтримується на рівні 1:1. Дотримуючись наведених вище принципів, система встановлює структурований підхід до ліцензування, надання прав і загальної роботи вузлів у екосистемі.
9. Вимоги до програмного та апаратного забезпечення сторожового вузла
Програмне забезпечення Sentinel node підтримує робочий стіл Windows, Mac і Linux (потрібна 64-розрядна версія). Нижче наведено поточні ресурси, необхідні для запуску програмного забезпечення вузла Sentinel для максимум 100 ліцензійних ключів:
4 Гб оперативної пам'яті
2 ядра ЦП
60 Гб дискового простору
Процесор x86/X64 (підтримує процесор ARM, наприклад чіп Apple M1/M2)
Стабільне підключення до Інтернету
При додаванні додаткових ключів до вузла в ідеалі апаратні можливості повинні відповідно збільшуватися. Однак не обов’язково призначати окрему машину для кожної клавіші. Очікується, що система буде масштабованою для розміщення десятків ключів на одній машині, а можливо, і більше.
Примітка. Ці вимоги до апаратного забезпечення можуть змінюватися.
10. Приблизні винагороди мережі Sentry node
Економічна модель токенів XAI, див.: Інтерпретація «Економіки токенів» проекту XAI
Ось три сценарії для оцінки винагород Xai, які ви можете отримати, керуючи вузлом Sentry. Ці три сценарії базуються на таких припущеннях:
Сума XAI та esXAI ніколи не перевищить 2 500 000 000. З огляду на те, що екосистема Xai є динамічною, неможливо точно передбачити щомісячну винагороду за кожен ключ Sentry.
100% ГАЗу спалюється, тому немає гарантії, що пропозиція завжди буде інфляційною, вона може бути дефляційною.
Xai Foundation не продасть більше 50 000 ключів Sentry (вузол може завантажити кілька ключів). Очікується, що це займе 2-3 роки. Ключі від сторожових з часом дорожчають.
Щомісячна сума esXAI на ключ Sentry також може коливатися залежно від кількості учасників екосистеми, що ставлять ставки.
Значення наступних трьох таблиць полягає в тому, що за різної циркуляції токенів XAI та esXAI кількість ключів вузла, активованих у мережі, та відповідні очікувані щомісячні винагороди за токени за ключ:
Приблизний сценарій A: якщо в обігу буде 750 000 токенів XAI та esXAI, то кожен ключ Sentry отримає винагороду esXAI згідно з наведеною нижче таблицею:
Оцінка сценарію Б: якщо в обігу буде 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 є ще одним альтернативним ланцюжком, який реалізує протокол Arbitrum Rollup, який не має довіри (і більш інтенсивний L1). Обидві мережі побудовані на Nitro.
4.Орбітальний ланцюг
Arbitrum Orbit дозволяє третім сторонам створювати власні самокеровані ланцюжки Arbitrum Rollup і AnyTrust. Arbitrum пропонує технології Rollup і AnyTrust для максимальної гнучкості при створенні ланцюжків Orbit. Як і всі ланцюжки в екосистемі Arbitrum, і Arbitrum Rollups, і ланцюг Arbitrum Anytrust Orbit побудовані з використанням Nitro як базової технології.
5. Зрозумійте основну ситуацію Xai
Давайте зрозуміємо Xai у наведеному вище контексті. Xai працює як мережа Arbitrum Orbit, використовуючи технологію Anytrust для досягнення максимальної швидкості та мінімальних витрат. На відміну від більшості «самокерованих» мереж Orbit, Xai отримує пряму технічну підтримку від Offchain Labs. Таку підтримку неможливо уявити для інших мереж Orbit! і є ключовим компонентом стратегічного ігрового плану Xai в екосистемі Arbitrum.
Частина 3: Після того, як у вас є наведені вище концепції, давайте глибше зрозуміємо архітектуру:
1.AnyTrust: революційна інфраструктура блокчейну
У рамках AnyTrust і як передовий варіант технології Arbitrum Nitro Offchain Labs використовує інновації для вирішення деяких із найактуальніших проблем у просторі блокчейну. AnyTrust відкриває для нас нову перспективу, використовуючи легкі припущення про довіру, значно знижуючи витрати, забезпечуючи надійну доступність і безпеку даних.
2. Зменшити витрати за рахунок довіри
В основі протоколу Arbitrum усі вузли Arbitrum (включно з валідаторами, які перевіряють правильність ланцюжка та виставляють точні результати) потребують доступу до даних кожної транзакції другого рівня (L2) у вхідній скриньці ланцюжка Arbitrum. Традиційно зведення Arbitrum забезпечує доступ до даних, публікуючи дані як дані виклику на першому рівні (L1) Ethereum, процес, який створює значні комісії за газ Ethereum, що є основним компонентом витрат у Arbitrum.
3. Гнучкість Ketsets
Ketsets відіграють ключову роль в архітектурі 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 сортувальника: розроблений для використання сортувальником ланцюга Arbitrum, цей інтерфейс JSON-RPC дозволяє сортувальнику надсилати блоки даних до DAS для зберігання.
(2) REST API: розроблений для ширшої доступності протокол на основі HTTP(S) RESTful дозволяє отримувати фрагменти даних через хеш. Він повністю кешується та може бути розгорнутий у поєднанні з кешуючими проксі-серверами або 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. Коли ми говоримо про Arbitrum, це стосується і нас.
Беручи до уваги вищесказане, традиційні методи перевірки заохочення не досягають бажаних результатів - існує базовий рівень шахрайства, нижче якого перевіряючі вважатимуть чек недоцільним. На закінчення:
Є два гравці: стверджувач, який висуває претензію, правдива вона чи хибна, і гравець, що перевіряє, який може перевірити претензію за певні обчислювальні витрати. Якщо гравець робить чек, його корисність RX-C, якщо він не робить чек, його корисність -XL, де R — винагорода за виявлення шахрайства, C — вартість перевірки, а L — втрата гравця через те, що він не виявив шахрайства. , X – це ймовірність обману суб’єкта, що заявляє (вибирається суб’єктом, що стверджує). Деяка алгебра показує, що якщо
Щоб вирішити цю проблему та створити ситуацію, коли рецензент, керований стимулом, завжди перевірятиме, ми маємо змінити стимули рецензента. Основна проблема полягає в тому, що в оригінальній моделі всі позитивні стимули для шашок пропорційні Якщо ми хочемо, щоб стимул для перевірки діяв незалежно від цього, нам потрібно створити стимул для перевірки або перешкоду для відмови від перевірки, яка не залежить від дій особи, яка стверджує.
TrueBit намагається зробити це, додаючи навмисно хибні твердження до набору тверджень, по суті замінюючи X на X плюс константу. З цим підходом є деякі проблеми. (Оригінальний документ Arbitrum містить розділ про проблеми мотивації TrueBit.)
Зосередьтеся на викликах
Ми використовуємо інший підхід, який ми називаємо зосередженням на виклику. Ідея полягає в тому, що якщо асертер обчислює значення f(x), він спочатку видає x і криптографічний виклик. Щоб правильно відповісти на виклик, екзаменатор повинен знати f(x). Лише після того, як виклик стався, asserter публікує 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 за твердження).
У відкритій системі будь-хто має право перевірити розрахунки, і ви можете дозволити будь-кому зареєструватися як перевіряючий і внести необхідний невеликий депозит. Це дасть їм право на виклики уваги та потенційно отримають компенсацію від розробників dapp. Будь-хто може оскаржити неправильні твердження автора, але лише зареєстровані екзаменатори стикаються з проблемами уваги.
Технічні деталі угоди
Тепер, коли ми розуміємо, що зосередження на викликах може зробити для нас, давайте зануримося в технічні деталі їх роботи.
Кожна перевірка має закритий ключ k і відповідний відкритий ключ gᵏ, визначені у відповідній групі. Відкритий ключ кожної шашки відомий кожному. Ми також будемо покладатися на відповідну хеш-функцію H.
Щоб поставити виклик обчисленню f(x), де функція f відома заздалегідь, асертер генерує випадкове значення r, а потім видає (x, gʳ) як виклик.
Контролер, який володіє приватним ключем k, повинен відповісти на виклик, опублікувавши невелику транзакцію, лише якщо H(gʳᵏ, f(x)) < T, де T є відповідно обраним порогом. Зауважте, що лише той, хто підтверджує (який знає r) і той конкретний перевіряючий (який знає свій закритий ключ k) можуть обчислити хеш, оскільки вони єдині, хто може обчислити gʳᵏ. Також зауважте, що для обчислення хешу потрібно знати f(x).
Після того, як перевіряючі матимуть деякий час, щоб опублікувати свої відповіді на виклик, заявник може опублікувати свій f(x), і якщо будь-який перевіряючий не погодиться з ним, він буде оскаржений, як зазвичай. На цьому етапі автор може звинуватити будь-якого перевіряючого в неправильних відповідях; Майнер або контракт можуть перевірити, чи є звинувачення правильним, і покарати порушника; Якщо будь-якого чекера оштрафують, заявник отримає половину конфіскованих коштів, а іншу половину буде знищено.
Такий підхід дає екзаменатору правильні стимули. Щоб знати, як перевіряючий має реагувати на виклик, потрібно знати закритий ключ цього перевіряючого та f(x), тому кожен перевіряючий захоче обчислити f(x). Якщо засіб перевірки не обчислить f(x) сам, він не зможе безпечно застосувати протокол. Відповіді інших шашок не є корисними для визначення f(x), оскільки вони покладаються на закриті ключі цих шашок. Якщо перевіряючий покладається на те, що хтось інший повідомляє йому f(x), він не має способу перевірити це заявлене значення (окрім обчислення f(x) самостійно), і перевіряючий ризикує бути покараним, якщо він помилиться. Існує навіть стимул для однієї сторони намагатися ввести перевіряючого в оману щодо f(x) - це особа, яка стверджує, яка отримує прибуток від помилки перевіряючого і може використовувати ці прибутки для підкупу «друзів» перевіряючого, щоб вони надали перевіряючому неправильну інформацію. .
Оптимізація та висновок
Є кілька прийомів, щоб зробити цей протокол ефективнішим. Наприклад, ми могли б об’єднати твердження з наступним викликом у транзакцію в ланцюжку, щоб виклик не збільшував кількість транзакцій. Якщо P невелике (наприклад, 0,3% у нашому прикладі) і кількість шашок не дуже велика, тоді шашкам рідко потрібно записувати транзакції в ланцюжку, тому загальний вплив протоколу на кількість транзакцій у ланцюжку буде бути найменшим.
З розумною реалізацією вартість цього протоколу має бути дуже низькою порівняно з початковою вартістю видачі тверджень у ланцюжку. У нашому випадку додавання викликів уваги до існуючого протоколу перевірки тверджень збільшує загальну вартість менше ніж на 1%.
І виграш суттєвий – ми отримуємо протокол перевірки, сумісний із заохоченнями, який захищений від дилеми валідатора. Поки принаймні один перевіряючий є раціональним, твердження того, хто стверджує, завжди перевірятимуться.
Щоб отримати іншу інформацію про проект, зверніться до: Публічна мережа ігор Xai: база даних Binance Square
