Вступ

Дорожня карта Ethereum включає технологію масштабування під назвою Data Availability Sampling (DAS) 6. DAS представляє нові<a href="https://notes.ethereum.org/ @djrtwo /das-requirements">вимоги 4 до мережевого стеку Ethereum, що потребує впровадження спеціалізованих мережевих протоколів 7 . Один відомий <a href="https://notes.ethereum.org/@dankrad /S-Kademlia-DAS"> протокол Пропозиція 4 використовує розподілену хеш-таблицю (DHT) на основі Kademlia 2 для зберігання та отримання зразків даних.

Однак DHT 4 чутливі до атак Sybil: зловмисник, який контролює велику кількість вузлів DHT, може зробити зразки DAS недоступними. Щоб протистояти цій загрозі, можна створити мережевий рівень з високим рівнем довіри, який складається виключно з валідаторів ланцюга маяків. Такий захід безпеки значно підвищує бар’єр для зловмисників, оскільки тепер вони повинні робити ставку на власний ETH для атаки на DHT.

У цій публікації ми представляємо доказ протоколу валідатора, який дозволяє учасникам DHT продемонструвати без знання, що вони є валідатором Ethereum.

Мотивація: атака «приховування зразків» на DAS

У цьому розділі ми додатково мотивуємо доказ протоколу перевірки, описуючи атаку Sybil на вибірку доступності даних.

Протокол DAS обертається навколо конструктора блоків, який забезпечує доступність даних блоків, щоб клієнти могли їх отримати. Сучасні підходи передбачають поділ даних на зразки, і учасники мережі отримують лише ті зразки, які стосуються їхніх інтересів.

)

Розглянемо сценарій, коли зловмисник Sybil хоче перешкодити учасникам мережі отримувати зразки з вузла-жертви, який відповідає за надання зразків. Як показано на малюнку вище, зловмисник генерує багато ідентифікаторів вузла, близьких до ідентифікатора вузла жертви. Оточуючи вузол жертви своїми власними вузлами, зловмисник перешкоджає клієнтам виявити вузол жертви, оскільки злісні вузли навмисно приховують інформацію про існування жертви.

Для отримання додаткової інформації про такі атаки Sybil перегляньте цю недавню дослідницьку статтю 2 про атаки DHT Eclipse. Крім того, <a href="https://notes.ethereum.org/ @dankrad /S-Kademlia-DAS#SKademlia-modifications">Dankrad Пропозиція мережевого протоколу DAS 8 описує, як протокол S/Kademlia DHT страждає від таких атак, і показує потребу в протоколі валідатора.

Доказ валідатора

Наведена вище атака мотивує необхідність підтвердження протоколу валідатора: якщо лише валідатори можуть приєднатися до DHT, тоді зловмисник, який хоче запустити атаку Sybil, також повинен зробити ставку на велику кількість ETH.

Використовуючи наш протокол підтвердження валідації, ми гарантуємо, що лише валідатори ланцюга маяків можуть приєднатися до DHT і що кожен валідатор отримує унікальний ідентифікатор DHT.

Крім того, для стійкості валідатора проти DoS ми також прагнемо приховати ідентичність валідаторів на мережевому рівні. Тобто ми не хочемо, щоб зловмисники могли визначити, який вузол DHT відповідає якому валідатору.

Щоб досягти цих цілей, протокол валідатора має відповідати таким вимогам:

• Унікальність: кожен валідатор ланцюга маяків повинен мати можливість вивести єдину унікальну пару ключів. Ця властивість не тільки обмежує кількість вузлів, які може створити зловмисник Sybil, але й дає змогу учасникам мережі локально карати вузли, що не поводяться неправильно, шляхом блокування їх похідної пари ключів.
• Конфіденційність: зловмисники не повинні бути в змозі дізнатися, який валідатор відповідає певному похідному відкритому ключу
• Час перевірки: процес перевірки протоколу має бути ефективним, займаючи менше 200 мс на вузол, дозволяючи кожному вузлу вивчати принаймні п’ять нових вузлів на секунду

Таке підтвердження протоколу валідатора буде використано Бобом під час встановлення з’єднання на рівні DHT, щоб Аліса знала, що вона розмовляє з валідатором.

Підтвердження протоколу валідатора

Наш протокол підтвердження валідації фактично є простою анонімною схемою облікових даних. Його мета — дозволити Алісі згенерувати унікальний похідний ключ, позначений як D, якщо і тільки якщо вона є валідатором. Згодом Аліса використовує цей похідний ключ D на мережевому рівні.

Під час розробки цього протоколу наша мета полягала в тому, щоб створити рішення, яке було б простим для впровадження та аналізу, гарантуючи, що воно відповідає окресленим вимогам ефективним способом.

Огляд протоколу

У протоколі використовується підпротокол підтвердження членства, в якому Аліса доводить, що вона є валідатором, демонструючи знання секретного геш-прообразу за допомогою доказів ZK. Потім Аліса створює унікальну пару ключів, отриману з цього секретного хеш-прообразу.

Підпротокол підтвердження членства може бути створений різними методами. У цій публікації ми показуємо протокол, що використовує дерева Merkle, і другий протокол, який використовує пошуки.

Хоча обидва підходи демонструють прийнятну ефективність, вони мають різні компроміси. Дерева Merkle покладаються на SNARK-дружні хеш-функції, такі як Poseidon (які можна вважати експериментальними). З іншого боку, ефективні протоколи пошуку покладаються на надійну установку Power-of-tau, розмір якої дорівнює розміру набору валідаторів (наразі 700 тис. валідаторів, але вони зростають).

Тепер давайте зануримося в протоколи:

Підхід №1: Дерева Меркле

Дерева Merkle широко використовуються для підтвердження членства (наприклад, див. семафор 3). Ось компроміс під час розробки підтвердження членства за допомогою дерев Merkle:

• Позитивно: немає потреби в довіреній установці
• Позитивний: простий для розуміння
• Негативний: покладається на SNARK-дружні хеш-функції, такі як Poseidon
• Мінус: повільніше створення доказів

Нижче ми описуємо підтвердження протоколу валідатора на основі дерев Merkle:

Протокол підтвердження валідації з використанням дерев Merkle

)

Наприкінці протоколу Аліса може використовувати D у DHT, щоб підписувати повідомлення та отримувати свій унікальний ідентифікатор вузла DHT.

Тепер давайте розглянемо трохи складніше, але набагато ефективніше рішення з використанням пошуку.

Підхід №2: Пошуки

Ось компроміс використання протоколів пошуку 2, таких як Caulk 2:

• Позитив: надзвичайно ефективне створення доказів (з використанням етапу попередньої обробки)
• Позитивно: протокол можна адаптувати для використання звичайної хеш-функції замість Poseidon
• Негативний: вимагає довіреної установки великого розміру (ідеально рівного розміру валідаторів)

Нижче ми описуємо конкретне підтвердження протоколу валідатора:

Підтвердження протоколу валідатора за допомогою пошуку

Так само, як і в підході Меркла, кожен валідатор i реєструє нове значення pi в блокчейні таким чином, що:

Ефективність

Ми порівняли час роботи нашого протоколу підтвердження членства (посилання 6 на код 5) щодо створення та перевірки підтвердження. Зауважте, що хоча підтвердження членства є лише частиною нашого протоколу підтвердження валідатора, ми очікуємо, що воно домінуватиме в загальному часі роботи.

Нижче ми надаємо результати порівняльного аналізу для доказу членства в дереві Меркле з використанням системи доказів Halo2 з IPA як поліноміальною схемою зобов’язань. IPA є повільнішою схемою, ніж KZG, але вона не потребує довіреного налаштування, що максимізує переваги підходу дерева Merkle.

Ми спостерігаємо, що час перевірки та верифікації добре узгоджується з нашими вимогами ефективності. З цієї причини ми вирішили не порівнювати підхід на основі Caulk, оскільки очікується, що його продуктивність буде значно кращою в усіх категоріях (особливо час перевірки та розмір перевірки).

Контрольні показники проводилися на ноутбуці, що працює на процесорі Intel i7-8550U (п’ятирічний процесор).

Обговорення

Обертові тотожності

Властивість унікальності протоколу перевірки перевірки гарантує, що кожен учасник мережі володіє окремою похідною парою ключів. Однак для певних мережевих протоколів може бути вигідно дозволити валідаторам мати змінні ідентифікатори, коли їхні отримані ключі періодично змінюються, можливо, щодня.

У такому випадку, якщо Єва погано поводилася в певний день, Аліса може заблокувати її для цього дня. Однак наступного дня Єва може згенерувати новий похідний ключ, якого немає в списку блокувань. Якщо ми хочемо мати можливість назавжди заблокувати валідаторів на основі їхніх змінних ідентифікаторів, нам знадобиться більш просунута схема анонімних облікових даних, як-от SNARKBlock 1.

Чому б не використати ідентифікаційний відкритий ключ BLS12-381?

Альтернативним (можливо, простішим) підходом було б створити зобов’язання з усіх ключів ідентичності валідатора BLS12-381 і виконати підтвердження членства на цьому зобов’язанні.

Однак цей підхід вимагав би від валідаторів вставити свій приватний ключ ідентичності в систему доказів ZK, щоб створити дійсний доказ членства та обчислити унікальний похідний ключ.

Ми вирішили не використовувати цей підхід, оскільки вставляти конфіденційні ключі ідентифікації в складний криптографічний протокол не є хорошою практикою, а також це ускладнить для валідаторів збереження основного ключа ідентифікації в автономному режимі.

Майбутні напрямки досліджень

• Чи можемо ми повністю уникнути схем SNARK і виконати доказ приналежності та виведення ключа чисто алгебраїчним способом?
• Пов’язане: чи можемо ми мати ефективний протокол підтвердження членства без довіреної установки та без використання хеш-функцій, зручних для SNARK?

Подяки

Дякуємо Енріко Ботацці, Cedoor, Vivian Plasencia та Wanseob за допомогу в навігації мережею кодових баз доказів членства.

Відмова від відповідальності:

1. Цю статтю передруковано з [ethresear]. Усі авторські права належать оригінальному автору [Георгій Кадіанакіс, Мері Маллер, Андрія Новакович, Супханат Чунхапанья]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: Th
   Погляди та думки, висловлені в цій статті, належать виключно автору та не є інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.