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

На кожній ноді Ethereum працює клієнт консенсусу і клієнт виконання. На сьогодні жоден клієнт консенсусу чи виконання не складає більше 2/3 мережі. Якщо клієнт, який має менше 1/3 частки в своїй категорії, має помилку, мережа просто продовжить роботу в звичайному режимі. Якщо клієнт з часткою від 1/3 до 2/3 у своїй категорії (наприклад, Prysm, Lighthouse або Geth) має баг, ланцюжок продовжить додавати блоки, але припинить фіналізацію блоків, щоб дати час розробникам втрутитися.

Одним з недостатньо обговорюваних, але, тим не менш, дуже важливих майбутніх змін в способі перевірки ланцюжка Ethereum є поява ZK-EVM. SNARK, що доводять виконання EVM, розробляються вже багато років, і ця технологія активно використовується протоколами другого рівня, які називаються ZK rollups. Деякі з цих ZK-роликів активні в мейннеті сьогодні, а інші з' являться незабаром. Але в довгостроковій перспективі ZK-EVM будуть призначені не тільки для роллапів; ми хочемо використовувати їх для перевірки виконання на рівні 1 (див. також: The Verge).

Як тільки це станеться, ZK-EVM де-факто стануть третім типом клієнтів Ethereum, таким же важливим для безпеки мережі, як клієнти виконання і клієнти консенсусу сьогодні. І це, природно, викликає питання: як ZK-EVM будуть взаємодіяти з філософією мультиклієнтської системи? Одна з важких частин вже зроблена: у нас вже є кілька реалізацій ZK-EVM, які активно розвиваються. Але залишаються інші складні моменти: як нам насправді зробити "мультиклієнтську" екосистему для ZK-перевірки коректності блоків Ethereum? Це питання відкриває деякі цікаві технічні проблеми - і, звичайно ж, постає питання про те, чи варті ці компроміси того, щоб піти на них.

Якою була початкова мотивація багатоклієнтської філософії Ethereum?

Мультиклієнтська філософія Ethereum є різновидом децентралізації, і, як і <a href="https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274"> децентралізація в цілому, можна зосередитися або на технічних перевагах архітектурної децентралізації, або на соціальних перевагах політичної децентралізації. Зрештою, мультиклієнтська філософія була мотивована обома і служить обом.

Аргументи на користь технічної децентралізації

Головна перевага технічної децентралізації проста: вона зменшує ризик того, що одна помилка в одному програмному забезпеченні призведе до катастрофічного виходу з ладу всієї мережі. Історичною ситуацією, яка ілюструє цей ризик, є баг переповнення біткоїна 2010 року. У той час код клієнта Bitcoin не перевіряв, що сума результатів транзакції не переповнюється (обертається навколо нуля шляхом підсумовування до максимального цілого числа^264-1), і тому хтось здійснив транзакцію, яка саме так і зробила, подарувавши собі мільярди біткоїнів. Баг був виявлений протягом декількох годин, і виправлення було швидко розгорнуто в мережі, але якби на той момент існувала зріла екосистема, ці монети були б прийняті біржами, мостами та іншими структурами, і зловмисники могли б отримати чимало грошей. Якби існувало п'ять різних біткоїн-клієнтів, було б дуже малоймовірно, що всі вони мали однаковий баг, і тому відбувся б негайний розкол, і сторона, яка мала баг, ймовірно, програла б.

Існує компроміс у використанні багатоклієнтського підходу для мінімізації ризику катастрофічних помилок: натомість ви отримуєте помилки, пов'язані з порушенням консенсусу. Тобто, якщо у вас є два клієнти, існує ризик того, що вони по-різному інтерпретують якесь правило протоколу, і хоча обидві інтерпретації є обґрунтованими і не дозволяють красти гроші, розбіжності призведуть до того, що ланцюжок розірветься навпіл. Серйозний розкол такого типу стався один раз в історії Ефіріуму (були й інші набагато менші розколи, коли дуже маленькі частини мережі, що працювали зі старими версіями коду, відокремлювалися). Захисники одноклієнтського підходу вказують на неможливість досягнення консенсусу як на причину відмови від множинних реалізацій: якщо є лише один клієнт, то цей клієнт не може не погодитися сам із собою. Їх модель того, як кількість клієнтів трансформується в ризик, може виглядати приблизно так:

Я, звичайно, не згоден з цим аналізом. Суть моєї незгоди полягає в тому, що (i) катастрофічні помилки зразка 2010 року теж мають значення, і (ii) насправді у вас ніколи не буває лише одного клієнта. Останній пункт є найбільш очевидним на прикладі форку Біткоїна 2013 року: розрив ланцюжка стався через розбіжності між двома різними версіями клієнта Біткоїна, одна з яких, як виявилося, мала випадкове і незадокументоване обмеження на кількість об'єктів, які можуть бути змінені в одному блоці. Отже, один клієнт в теорії часто є двома клієнтами на практиці, а п'ять клієнтів в теорії можуть бути шістьма чи сімома клієнтами на практиці - тож ми повинні просто зануритися і рухатися по правильній стороні кривої ризику, і мати принаймні кілька різних клієнтів.

Аргументи на користь політичної децентралізації

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

Занепокоєння політикою протоколу, особливо в контексті війни OP_RETURN 2013-14 років, коли деякі учасники відкрито виступали за дискримінацію певних способів використання ланцюжка, стало значним фактором, що сприяв ранньому прийняттю Ethereum філософії багатоклієнтності, яка мала на меті ускладнити прийняття подібних рішень невеликою групою людей. Занепокоєння, характерні для екосистеми Ethereum, а саме - уникнення концентрації влади в межах самої Фундації Ethereum, надали додаткову підтримку цьому напрямку. У 2018 році було прийнято рішення навмисно не впроваджувати протокол Ethereum PoS (тобто. те, що зараз називають "консенсусним клієнтом"), залишаючи це завдання повністю зовнішнім командам.

Як ZK-EVM з'являться на першому рівні в майбутньому?

Сьогодні ZK-EVM використовуються в роллапах. Це збільшує масштабування, дозволяючи дорогому виконанню EVM відбуватися лише кілька разів поза ланцюжком, а всі інші просто перевіряють SNARK, розміщені в ланцюжку, які доводять, що виконання EVM було обчислено правильно. Це також дозволяє не включати деякі дані (зокрема, підписи) в ланцюжок, заощаджуючи витрати на газ. Це дає нам багато переваг масштабованості, а поєднання масштабованих обчислень за допомогою ZK-EVM та масштабованих даних за допомогою <a href="https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling"> вибірки доступності даних може дозволити нам масштабуватися дуже далеко.

Однак сьогодні мережа Ethereum також має іншу проблему, яку не може вирішити жодне масштабування рівня 2: рівень 1 важко верифікувати, до того ж не так багато користувачів запускають свої власні вузли. Натомість більшість користувачів просто довіряють стороннім провайдерам. Легкі клієнти, такі як Helios і Succinct, роблять кроки до вирішення цієї проблеми, але легкий клієнт - це далеко не повністю верифікуючий вузол: легкий клієнт лише перевіряє підписи випадкової підмножини валідаторів, які називаються комітетом синхронізації, і не перевіряє, чи дійсно ланцюжок дотримується правил протоколу. Щоб перенести нас у світ, де користувачі дійсно можуть перевірити, чи дотримується ланцюжок правил, ми повинні були б зробити щось інше.

Варіант 1: звузити рівень 1, змусити майже всю активність переміститися на рівень 2

З часом ми могли б зменшити кількість газу на блок 1-го рівня з 15 мільйонів до 1 мільйона, що достатньо для того, щоб блок містив один SNARK і кілька операцій введення і виведення коштів, але не більше того, і тим самим змусити майже всю активність користувачів перейти на протоколи 2-го рівня. Такий дизайн все ще може підтримувати багато роллапів, що фіксуються в кожному блоці: ми можемо використовувати протоколи позаланцюгової агрегації, що запускаються спеціальними білдерами, щоб зібрати SNARK з декількох протоколів другого рівня і об'єднати їх в один SNARK. У такому світі єдиною функцією 1-го рівня була б функція клірингового центру для протоколів 2-го рівня, який перевіряв би їхні докази і час від часу сприяв би переказу великих коштів між ними.

Такий підхід може працювати, але він має кілька важливих недоліків:

• Це де-факто зворотна несумісність, в тому сенсі, що багато існуючих додатків на базі L1 стають економічно нежиттєздатними. Кошти користувачів у розмірі до сотень і тисяч доларів можуть застрягти, оскільки комісії стають настільки високими, що перевищують вартість спорожнення цих рахунків. Цю проблему можна було б вирішити, дозволивши користувачам підписувати повідомлення, щоб погодитися на масову міграцію в протоколі на L2 за їхнім вибором (див. деякі ранні ідеї реалізації тут), але це додає складності переходу, а для того, щоб зробити його дійсно дешевим, все одно знадобиться якийсь SNARK на рівні 1. Я взагалі прихильник порушення зворотної сумісності, коли йдеться про <a href="https://hackmd.io/@vbuterin/selfdestruct"> такі речі, як опкод SELFDESTRUCT, але в цьому випадку компроміс видається набагато менш сприятливим.
• Це все одно не зробить верифікацію достатньо дешевою. В ідеалі, протокол Ethereum повинен легко перевірятися не тільки на ноутбуках, але і в телефонах, розширеннях браузерів і навіть в інших ланцюжках. Синхронізація ланцюжка вперше або після тривалої відсутності в мережі також має бути простою. Ноутбучний вузол може перевірити 1 мільйон газів за ~20 мс, але навіть це означає 54 секунди для синхронізації після одного дня офлайн (припускаючи, що <a href="https://notes.ethereum.org/@vbuterin/single_slot_finality"> single slot finality збільшує час слоту до 32 с), а для телефонів або розширень браузерів це займе кілька сотень мілісекунд на блок, що все одно може призвести до значного розряду акумулятора. Цими цифрами можна керувати, але вони не ідеальні.
• Навіть в екосистемі першого рівня (L2) є переваги в тому, що L1 є принаймні дещо доступним. Валідії можуть отримати вигоду від сильнішої моделі безпеки, якщо користувачі зможуть виводити свої кошти, якщо помітять, що нові дані про стан більше не надаються. Арбітраж стає більш ефективним, особливо для менших токенів, якщо мінімальний розмір економічно вигідного прямого крос-L2 переказу менший.

Отже, здається більш розумним спробувати знайти спосіб використати ZK-SNARK для перевірки самого рівня 1.

Варіант 2: SNARK-перевірка шару 1

ZK-EVM типу 1 (повністю еквівалентний Ethereum ) може бути використаний для перевірки виконання EVM блоку Ethereum (рівень 1). Ми могли б написати більше коду SNARK, щоб також перевіряти консенсусну сторону блоку. Це було б складною інженерною проблемою: сьогодні ZK-EVM витрачають від декількох хвилин до декількох годин на перевірку блоків Ethereum, а генерація доказів в реальному часі вимагала б одного або декількох (i) вдосконалень самого Ethereum для видалення компонентів, недружніх до SNARK, (ii) значного підвищення ефективності за допомогою спеціалізованого обладнання, і (iii) архітектурних вдосконалень з набагато більшим розпаралелюванням. Однак немає жодної фундаментальної технологічної причини, чому це не можна зробити - і тому я очікую, що, навіть якщо це займе багато років, це буде зроблено.

Тут ми бачимо перетин з парадигмою мультиклієнтських середовищ: якщо ми використовуємо ZK-EVM для перевірки рівня 1, то яку ZK-EVM ми використовуємо?

Я бачу три варіанти:

1. Єдиний ZK-EVM: відмова від багатоклієнтської парадигми і вибір єдиного ZK-EVM, який ми використовуємо для перевірки блоків.
2. Закриті мульти-ЗК-ЕВМ: узгоджують і закріплюють консенсусом певний набір мульти-ЗК-ЕВМ, а також мають правило протоколу на рівні консенсусу, згідно з яким блок потребує доказів від більш ніж половини мульти-ЗК-ЕВМ з цього набору, щоб вважатися дійсним.
3. Відкритий мульти ZK-EVM: різні клієнти мають різні реалізації ZK-EVM, і кожен клієнт чекає на доказ, сумісний з його власною реалізацією, перш ніж прийняти блок як дійсний.

Для мене (3) здається ідеальним, принаймні до тих пір, поки наша технологія не покращиться настільки, що ми зможемо формально довести, що всі реалізації ZK-EVM еквівалентні одна одній, і тоді ми зможемо просто вибрати, яка з них є найбільш ефективною. (1) принесе в жертву переваги багатоклієнтської парадигми, і (2) закриє можливість розвитку нових клієнтів і призведе до більш централізованої екосистеми. (3) має проблеми, але ці проблеми здаються меншими, ніж проблеми двох інших варіантів, принаймні поки що.

Реалізація (3) не буде надто складною: можна створити підмережу p2p для кожного типу підтвердження, і клієнт, який використовує один тип підтвердження, буде слухати відповідну підмережу і чекати, поки він не отримає підтвердження, яке його верифікатор визнає дійсним.

Дві основні проблеми (3), ймовірно, полягають у наступному:

• Проблема затримки: зловмисник може опублікувати блок із запізненням, разом із підтвердженням, дійсним для одного клієнта. Насправді це займе багато часу (навіть якщо, наприклад, 15 секунд), щоб згенерувати докази, дійсні для інших клієнтів. Цього часу буде достатньо, щоб потенційно створити тимчасову вилку і перервати ланцюжок на кілька слотів.
• Неефективність даних: одна з переваг ZK-SNARK полягає в тому, що дані, які мають відношення лише до верифікації (іноді їх називають "свідченнями"), можуть бути видалені з блоку. Наприклад, якщо ви перевірили підпис, вам не потрібно зберігати його в блоці, ви можете просто зберігати один біт, який говорить, що підпис дійсний, разом з одним доказом в блоці, який підтверджує, що всі дійсні підписи існують. Однак, якщо ми хочемо, щоб можна було генерувати докази декількох типів для блоку, оригінальні підписи повинні бути фактично опубліковані.

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

Проблему ефективності даних слід було б вирішити шляхом створення окремого протоколу для агрегування даних, пов'язаних з верифікацією. Для підписів ми можемо використовувати агрегацію BLS, яку вже підтримує ERC-4337. Ще однією важливою категорією даних, пов'язаних з верифікацією, є ZK-SNARK, які використовуються для забезпечення конфіденційності. На щастя, вони часто мають власні протоколи агрегації.

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

Висновки

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

• У нас вже є кілька потужних реалізацій ZK-EVM. Ці реалізації ще не є реалізаціями типу 1 (повністю еквівалентними Ethereum), але багато з них активно рухаються в цьому напрямку.
• Робота над легкими клієнтами, такими як Helios і Succinct, з часом може перетворитися на більш повну SNARK-верифікацію консенсусу PoS-частини ланцюжка Ethereum.
• Клієнти, ймовірно, почнуть експериментувати з ZK-EVM, щоб самостійно довести виконання блоків Ethereum, особливо коли у нас з'являться клієнти без громадянства і не буде технічної необхідності безпосередньо повторно виконувати кожен блок для підтримки стану. Ми, ймовірно, отримаємо повільний і поступовий перехід від клієнтів, які перевіряють блоки Ethereum шляхом їх повторного виконання, до більшості клієнтів, які перевіряють блоки Ethereum шляхом перевірки SNARK-доказів.
• Екосистеми ERC-4337 і PBS, ймовірно, незабаром почнуть працювати з технологіями агрегації, такими як BLS і перевірочна агрегація, щоб заощадити на витратах на газ. Робота над агрегацією BLS вже розпочалася.

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

У довгостроковій перспективі, звичайно, може статися що завгодно. Можливо, ШІ прискорить формальну верифікацію до такої міри, що зможе легко довести еквівалентність реалізацій ZK-EVM і виявити всі помилки, які спричиняють відмінності між ними. Такий проект може бути навіть тим, над чим доцільно почати працювати вже зараз. Якщо такий підхід, заснований на формальній верифікації, буде успішним, необхідно буде запровадити різні механізми для забезпечення подальшої політичної децентралізації протоколу; можливо, на цьому етапі протокол вважатиметься "повним", а норми незмінності будуть сильнішими. Але навіть якщо це довгострокове майбутнє, відкритий багатоклієнтський світ ZK-EVM здається природною сходинкою, яка, швидше за все, станеться в будь-якому випадку.

У найближчій перспективі це все ще довгий шлях. ZK-EVM вже є, але для того, щоб ZK-EVM стали по-справжньому життєздатними на рівні 1, потрібно, щоб вони стали типом 1, і щоб доведення було достатньо швидким, щоб це могло відбуватися в реальному часі. При достатньому розпаралелюванні це можливо, але все одно доведеться докласти чимало зусиль, щоб досягти цього. Зміни консенсусу, такі як підвищення вартості газу для прекомпіляцій KECCAK, SHA256 та інших хеш-функцій, також будуть важливою частиною картини. Тим не менш, перші кроки переходу можуть відбутися раніше, ніж ми очікуємо: як тільки ми перейдемо на дерева Verkle і клієнтів без громадянства, клієнти можуть почати поступово використовувати ZK-EVM, і перехід до "відкритого світу з декількома ZK-EVM" може почати відбуватися сам по собі.

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

1. Ця стаття передрукована з[vitalik], всі авторські права належать первинному автору[vitalik]. Якщо у вас є заперечення щодо цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно його опрацюють.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладених статей заборонені.