Сьогодні на дослідницькому форумі Ethereum тихо народилася нова концепція: Доказ валідатора.

Цей механізм протоколу дозволяє мережевим вузлам довести, що вони є валідаторами Ethereum, не розкриваючи свої конкретні дані.

Яке це має відношення до нас?

За звичайних обставин ринок частіше звертає увагу на поверхневі наративи, викликані певними технологічними інноваціями в Ethereum, і рідко заздалегідь глибоко досліджує саму технологію. Наприклад, оновлення в Шанхаї, злиття, перехід від PoW до PoS і розширення Ethereum, ринок пам’ятає лише розповідь про LSD, LSDFi та повторне заставу.

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

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

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

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

Оскільки розширення потужностей є обов’язковим, те, як зменшити можливі ризики, пов’язані з процесом розширення потужностей, є неминучою проблемою безпеки, яка також тісно пов’язана з кожним із нас у колі.

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

Вибірка доступності даних: прорив у розширенні ємності

Не хвилюйтеся, перш ніж офіційно представити Proof of Validator, необхідно зрозуміти логіку поточного розширення Ethereum і можливі ризики.

Спільнота Ethereum активно просуває кілька планів розширення. Серед них найбільш критичною технологією вважається вибірка доступності даних (скорочено DAS).

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

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

Зокрема, впровадження DAS коротко описано наступним чином:

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

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

Однак ця схема вибірки має ключову проблему: де зберігаються масивні вибірки?Для цього потрібен цілий набір децентралізованої мережі.

Розподілена хешована таблиця: домашня сторінка зразків

Це дає розподіленій хеш-таблиці (DHT) можливість проявити свої таланти.

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

Зокрема, після того, як DAS ділить блокові дані на кілька зразків, ці зразки потрібно розповсюдити на різні вузли в мережі для зберігання. DHT може забезпечити децентралізований метод зберігання та отримання цих зразків, основна ідея полягає в наступному:

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

Наприклад, згідно з певними правилами, кожен зразок може бути хешований в адресу, вузол A відповідає за адресу 0-1000, а вузол B відповідає за адресу 1001-2000.

Тоді вибірка з адресою 599 буде збережена у вузлі A. Якщо цей зразок потрібен, знайдіть адресу 599 через той самий хеш, а потім знайдіть вузол A, відповідальний за адресу в мережі, і отримайте з нього зразок.

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

У порівнянні з централізованим зберіганням і пошуком, DHT може підвищити відмовостійкість, уникнути єдиної точки відмови та підвищити масштабованість мережі. Крім того, DHT також може допомогти захиститися від атак, таких як «приховування зразків», згаданих у DAS.

Больові точки ДГТ: атака Сибіл

Однак DHT також має ахіллесову п'яту, яка полягає в загрозі атак Сибіл. Зловмисники можуть створити велику кількість підроблених вузлів у мережі, і навколишні справжні вузли будуть «завалені» цими підробленими вузлами.

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

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

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

Це серйозно заважає розширенню DAS і Ethereum. Чи є спосіб протистояти цій загрозі та забезпечити надійність мережі?

Доказ валідатора: рішення ZK для захисту безпеки розширення

Тепер давайте повернемося до головної теми цієї статті: доказ валідатора.

Сьогодні на технологічному форумі Ethereum Джордж Кадіанакіс, Мері Маллер, Андрія Новакович і Супханат Чунхапанья спільно запропонували цю пропозицію.

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

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

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

Таким чином, Proof of Validator (далі – PoV) можна використовувати для створення високонадійної мережі DHT, яка складається лише з чесних вузлів перевірки, ефективно протистоячи атакам Sybil.

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

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

Тож як це зробити? В оригінальному дописі використовувалося багато математичних формул і виводів, тому я не буду вдаватися в подробиці, ми надамо спрощену версію:

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

Пропустивши ці технічні деталі, кінцевий ефект PoV такий:

** Тільки автентифіковані вузли можуть приєднатися до мережі DHT, що значно підвищує її безпеку та може ефективно протистояти атакам Sybil і запобігати навмисному приховуванню чи зміні зразків. PoV забезпечує надійну базову мережу для DAS, що опосередковано допомагає Ethereum досягти швидкого розширення. **

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

Однак кілька дослідників на цій посаді провели експерименти в невеликому масштабі, і результати показують, що ефективність PoV у пропонуванні доказів ZK і ефективність верифікаторів у отриманні доказів непогані. Варто зазначити, що їх експериментальне обладнання - це просто ноутбук, який лише 5 років тому був оснащений процесором Intel i7.

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