Оригінальний заголовок: Шлях до безпечних та ефективних zkVMs: Як відстежувати прогрес
Автор оригинала: a16z crypto
Оригінальний текст: Golem, Одейлі Зіркова газета
zkVM (Zero Knowledge Virtual Machine) зобов'язується «зробити SNARK масовим», дозволяючи будь-кому (навіть людям без професійних знань SNARK) довести, що вони правильно виконали будь-яку програму на вказаному введенні (або свідченні). Їхня основна перевага полягає в досвіді розробника, але наразі вони стикаються з великими викликами в області безпеки та продуктивності. Для того щоб втілити обіцянку візії zkVM, дизайнерам необхідно подолати ці виклики. У цій статті я перераховую можливі етапи розробки zkVM, завершення цих етапів займе кілька років.
Виклик
З точки зору безпеки zkVM є високорівневим складним програмним продуктом, який все ще містить уразливості. З точки зору продуктивності швидкість виконання програми доведення може бути на десятки тисяч разів повільніше, ніж локальний запуск, що перешкоджає більшості додатків розгортатися в реальному світі.
Незважаючи на ці реальні виклики, більшість компаній у галузі блокчейн все ще описують zkVM як що можна вразити в момент. Фактично, деякі проекти вже витрачають значні обчислювальні витрати для генерації доказів ланцюжкової діяльності. Однак, оскільки zkVM ще не є повноцінним, це лише дорогий спосіб претензійного захисту системи за допомогою SNARK, а насправді вона або захищена ліцензією, або, що гірше, легко піддається атакам.
Ми маємо кілька років, щоб забезпечити безпечну та високоефективну zkVM. Ця стаття встановлює конкретні поетапні цілі для відстеження прогресу zkVM - ці цілі можуть усунути шум та допомогти спільноті зосередитися на справжньому прогресі.
Етап безпеки
Зазвичай zkVM, заснований на SNARK, включає два основні компоненти:
· Інтерактивне підтвердження оракула поліномів (PIOP): використовується для підтвердження висловлювань про поліноми (або обмеження, які можуть бути отримані з них) в інтерактивній рамці доказу.
· Схема зобов'язань поліномів (PCS): гарантує, що доказуючий не може брехати щодо оцінки полінома, не бувши виявленим.
zkVM в сутності перетворює ефективне виконання на відстеження кодування у вигляді системи обмежень - загалом це означає, що вони змушують віртуальну машину правильно використовувати регістри та пам'ять - а потім застосовують SNARK для доведення виконання цих обмежень.
Переконайтеся, що єдиний шлях до відсутності помилок у складних системах, які збігаються, таких як zkVM, - це формальна перевірка. Ось підрозділи етапу безпеки. Етап 1 зосереджується на правильному протоколі, тоді як етапи 2 та 3 зосереджені на правильній реалізації.
Етап безпеки 1: Правильний протокол
Формальне підтвердження надійності PIOP;
2、PCS має силу обмежуючого доказу у формі підтвердження під певними криптографічними умовами або ідеальними моделями;
Якщо використовувати Fiat-Shamir, то формальне підтвердження безпеки випадкових передбачень у моделі доведення, отримане шляхом поєднання ПІОП та ПКС, є безпечним (за потреби з посиленням за допомогою інших криптографічних припущень);
4、Система обмежень, що застосовується в PIOP, еквівалентна формальному підтвердженню семантики VM;
Об'єднайте всі ці компоненти в єдиний, формалізований підтверджений безпечний SNARK-доказ, який може використовуватися для виконання будь-якої програми, що визначена байт-кодом ВМ. Якщо протокол передбачає нульовий доказ, також потрібно формалізувати цей аспект, щоб забезпечити, що ніяка чутлива інформація про свідків не буде розкрита.
Попередження про рекурсію: Якщо zkVM використовується для рекурсії, то на цьому етапі вважається завершеним тільки після перевірки кожного PIOP, обіцянки та системи обмежень, що стосуються будь-якого місця у цій рекурсії.
Етап безпеки 2: Правильна реалізація перевірки
Формалізоване доведення zkVM верифікатора фактичної реалізації (використання Rust, Solidity тощо) відповідає протоколу першої фази верифікації. Це забезпечує розумність реалізованого протоколу (не лише на папері, або низькоефективні специфікації, створені з використанням Lean тощо).
Друга фаза має два аспекти, що стосуються лише реалізації перевірників (а не доводів). По-перше, правильне використання верифікатора вже достатньо для забезпечення надійності (тобто гарантії того, що верифікатор не може вірити в будь-які фальшиві заяви, які фактично є істинними). По-друге, реалізація верифікатора zkVM є простішою на порядок, ніж реалізація доводу.
Етап безпеки 3: правильна реалізація доказувача
Реальна реалізація засобів доведення zkVM правильно генерує підтвердження системи доведення для першої та другої фаз верифікації, тобто отримує формальне підтвердження. Це забезпечує цілісність, тобто жодне заявлення, яке не може бути доведено, не може «застрягти» в будь-якій системі, що використовує zkVM. Якщо засіб доведення має намір реалізувати нульове знання, то цю властивість необхідно формально підтвердити.
Плановий графік
· Етап 1: Прогрес: Ми можемо очікувати поступових досягнень у наступному році (наприклад, ZKLib). Проте протягом щонайменше двох років жоден zkVM не зможе повністю задовольнити вимоги першого етапу;
· Крок 2 та крок 3: Ці етапи можуть взаємодіяти з деякими аспектами Кроку 1 одночасно. Наприклад, деякі команди вже довели, що реалізація перевірника Plonk відповідає протоколу з документації (навіть якщо сам протокол з документації може бути не повністю перевірений). Проте я не очікую, що будь-яка zkVM досягне Кроку 3 менш як за чотири роки — і можливо, навіть довше.
Ключові пункти: безпека Fiat-Shamir та перевірений байт-код
Один із головних складних чинників полягає в тому, що навколо безпеки перетворення Фіата-Шамира існують невирішені дослідницькі питання. Усі три етапи розглядають Фіата-Шамира та випадковий оракул як частину їхньої бездоганної безпеки, але насправді весь парадигма може мати вразливості. Це через те, що випадковий оракул занадто ідеалізований та відмінності між ним та фактично використовуваними хеш-функціями. У найгіршому випадку система, яка вже перейшла до другого етапу через проблему Фіата-Шамира, може виявитися абсолютно небезпечною. Це викликає серйозну тривогу та постійні дослідження. Можливо, нам знадобиться модифікувати саме перетворення для кращого запобігання таким вразливостям.
Система без рекурсії в теорії є більш стійкою, оскільки деякі відомі атаки включають схеми, схожі на схеми, що використовуються в рекурсивних доведеннях.
Ще одним важливим аспектом є те, що якщо байт-код має дефекти, то навіть після правильного виконання комп'ютерної програми (за допомогою вказаного байт-коду) його цінність обмежена. Тому практична цінність zkVM в значній мірі залежить від методу генерації формалізованої верифікації байт-коду - це великий виклик, який виходить за межі обговорення цього документа.
Про безпеку у постквантову епоху
Принаймні протягом наступних п'яти років (можливо, навіть довше) квантові комп'ютери не будуть становити серйозної загрози, а уразливості - це форма життєвого ризику. Тому наразі головний акцент слід зробити на задоволення вимог щодо безпеки і продуктивності, які обговорюються у цьому документі. Якщо ми можемо швидше задовольнити ці вимоги безпеки за допомогою не-квантово-безпечних SNARK, то ми повинні це зробити, доки пізніше квантово-безпечний SNARK не наздожене, або доки люди серйозно не почнуть турбуватися про застосування квантових комп'ютерів у криптографії.
Поточний стан продуктивності zkVM
Наразі коефіцієнт витрат zkVM доказувача наближається до вартості виконання майже на 1 мільйон разів. Якщо програмі потрібно X циклів для виконання, то вартість доказу правильного виконання становить близько X помножити на 1 мільйон циклів процесора. Це було так рік тому, і це так і зараз.
Популярні наративи зазвичай описують ці витрати таким чином, що звучить прийнятно. Наприклад:
·「Витрати на генерацію доказів роботи головної мережі Ethereum становлять менше ніж один мільйон доларів на рік.」
Ми майже можемо використовувати кластер, що складається з десятків GPU, для генерації доказів блоків Ethereum у реальному часі.
·「Наш новий zkVM працює в 1000 разів швидше, ніж його попередник.」
Хоча технічно ці висловлювання є точними, але без належного контексту вони можуть бути вводячими у помилку. Наприклад:
· Порівняно з попередньою версією zkVM швидкість зросла в 1000 разів, але абсолютна швидкість все ще дуже повільна. Це, скоріш за все, свідчить про те, наскільки погано все виявилося, а не наскільки добре.
· Хтось вже запропонував збільшити обчислювальну потужність головної мережі Ethereum у 10 разів. Це зробить поточну продуктивність zkVM повільнішою.
· Те, що люди називають «майже в реальному часі доказом Ефіріум-блоку», все ще набагато повільніше, ніж вимагає багато додатків блокчейну (наприклад, час блокування оптимізму станом на 2 секунди, це набагато швидше, ніж час блокування Ефіріуму на 12 секунд).
·「Десятки GPU постійно працюють, без жодних помилок」не може забезпечити задовільну гарантію активності.
· Кожного року витрачається менше одного мільйона доларів, щоб довести, що всі дії на головній мережі Ethereum відображають той факт, що для виконання обчислень на повній вузлі Ethereum щороку потрібно лише приблизно 25 доларів.
Для додатків поза блокчейном такі витрати, очевидно, є надто великими. Жодна паралельність або інженерія не здатна компенсувати такі великі витрати. Ми повинні вважати швидкість zkVM найбільш базовим бенчмарком порівняно з нативним виконанням - навіть якщо це лише перший крок. Справжня масова участь можливо знадобиться приблизно в 10 000 разів менших витрат або ще менше.
Як виміряти продуктивність
SNARK має три основні складові частини продуктивності:
· Внутрішня ефективність системи підтвердження на нижньому рівні.
· Оптимізація, специфічна для додатків (наприклад, попередня компіляція).
· Інженерія та апаратне прискорення (наприклад, GPU, FPGA або багатоядерний CPU).
Хоча останні дві надзвичайно важливі для реального впровадження, вони, як правило, застосовуються до будь-якої системи доказів, тому вони не обов'язково відображають основні витрати. Наприклад, у zkEVM додавання прискорення GPU та попередньої компіляції може легко забезпечити 50-кратне прискорення, що набагато швидше, ніж чистий метод без попередньої компіляції, заснований на CPU - достатньо, щоб система з суттєво меншою ефективністю виглядала краще, ніж система без такого самого полірування.
Отже, нижче наведено основні характеристики продуктивності SNARK без спеціалізованого апаратного забезпечення та попередньої компіляції. Це відрізняється від поточного методу базового тестування, який зазвичай об'єднує всі три фактори в одне "число заголовка". Це відповідає визначенню вартості діаманта на основі часу полірування, а не його внутрішньої чистоти. Нашою метою є виключення внутрішніх витрат загальної системи доведення - допомога спільноті усунути різноманітні фактори, щоб сконцентруватися на справжніх досягненнях в дизайні системи доведення.
Етап продуктивності
Ось 5 віх здійснення продуктивності. По-перше, нам потрібно зменшити витрати на доведення на CPU на кілька порядків величини. Тільки тоді увага повинна перейти на подальше зменшення через апаратне забезпечення. Також потрібно підвищити використання пам'яті.
На всіх етапах розробки розробники не повинні робити налаштування коду відповідно до zkVM для досягнення необхідної продуктивності. Враження розробників є основною перевагою zkVM. Жертвувати DevEx для відповідності продуктивності порушує сенс самого zkVM.
Ці показники зосереджені на витратах для підтверджуючого. Однак якщо дозволити необмежені витрати на підтвердження (тобто немає верхньої межі для розміру доказу або часу підтвердження), то будь-які показники підтвердження можна легко задовольнити. Тому для системи, яка має відповідати описаному етапу, необхідно визначити максимальні значення розміру доказу та часу підтвердження.
вимоги до продуктивності
Етап 1 вимагає: "розумних та неординарних витрат на підтвердження":
· Розмір доказу: Розмір доказу повинен бути меншим за розмір свідоцтва.
· Час перевірки: швидкість підтвердження доказу не може бути повільніше, ніж швидкість виконання локальної програми (тобто виконання обчислення без підтвердження правильності).
Це мінімальні вимоги щодо конкретності. Вони гарантують, що розмір доказу та час підтвердження не будуть гіршими, ніж метод надсилання свідчень валідаторам та дозвіл на безпосередню перевірку їх правильності від валідатора.
Вимоги на етапі 2 та пізніше:
· Максимальний розмір підтвердження: 256 КБ.
· Максимальний час перевірки: 16 мс.
Ці межі були наміренно збільшені для відповідності новій швидкій технології підтвердження, яка може призвести до вищих витрат на підтвердження. Водночас вони виключають дуже дорогі підтвердження, через що майже жоден проект не бажає включати їх в блокчейн.
Етап швидкості 1
Доказательство однопоточності повинно бути принаймні в десять тисяч разів повільнішим за локальне виконання у серії застосунків (не лише блоків Ethereum), не покладаючись на попередню компіляцію.
Конкретно, уявіть собі процес RISC-V, який працює на сучасному ноутбуці приблизно 30 мільярдів разів на секунду. Завершення першої фази означає, що ви можете довести приблизно 30,000 циклів RISC-V на секунду (однопотоково) на тому ж самому ноутбуці. Однак вартість верифікації повинна бути «розумною та не банальною», як вище зазначено.
Етап швидкості 2
Доказ про один потік повинен бути повільнішим на найбільше десять тисяч разів, ніж локальне виконання.
Або, через обмеження поточних ЦП та ГПУ, зумовлене деякими перспективними методами SNARK (особливо тими, що базуються на бінарних полях), ви можете досягти цього етапу, порівнюючи використання FPGA (навіть ASIC):
FPGA може емулювати кількість ядер RISC-V зі швидкістю локального обчислення;
Моделювання та демонстрація (майже) в реальному часі кількості FPGA, необхідних для виконання RISC-V.
Якщо друге число не більше першого у 10, 000 разів, ви маєте право на вхід до другої фази. На стандартному процесорі розмір доказу повинен бути не більш як 256 КБ, а час перевірки - не більше 16 мілісекунд.
Етап швидкості 3
Крім досягнення швидкісної фази 2, можна використовувати автоматичне синтезування та попередню компіляцію для зниження витрат на докази на порядок менше 1000 разів (що підходить для широкого спектру додатків). Фактично, для кожної програми можна динамічно налаштувати набір інструкцій для прискорення доведення, проте це слід зробити таким чином, щоб його можна було легко використовувати та перевіряти формально.
Етап пам'яті 1
Швидкість у першому етапі досягається при умові, що потребується менше 2 ГБ пам'яті в доведенні (одночасно досягається нульове знання).
Це надзвичайно важливо для багатьох мобільних пристроїв або браузерів, тому відкрито безліч випадків використання zkVM клієнтом. Клієнтське підтвердження є дуже важливим, оскільки наші мобільні телефони - це наш постійний зв'язок з реальним світом: вони відстежують наше місце знаходження, підтвердження тощо. Якщо для генерації підтвердження потрібно більше 1-2 ГБ пам'яті, то це занадто багато для більшості сучасних мобільних пристроїв. Є дві речі, які потрібно уточнити:
· 2 ГБ обмеження простору відноситься до великих запитів (заявки, які вимагають мільярди циклів ЦП для локального виконання). Системи доказу обмеження простору для невеликих запитів мають обмежену застосовність.
· Якщо доведець дуже повільний, то дуже легко утримувати простір доведця в межах 2 ГБ пам'яті. Тому, щоб зробити етап 1 пам'яті не настільки простим, я прошу задовольнити швидкість етапу 1 в межах 2 ГБ обмеження простору.
Етап пам'яті 2
Швидкість етапу 1 досягається при обсязі використання пам'яті менше 200 МБ (на 10 разів краще, ніж етап 1 пам'яті).
Чому потрібно обмежитися 2 ГБ? Розгляньте не блокчейн приклад: кожного разу, коли ви відвідуєте веб-сайт через HTTPS, ви завантажуєте сертифікат для автентифікації та шифрування. Натомість сайт може вислати докази знань з цими сертифікатами. Великі веб-сайти можуть видалити мільйони таких доказів кожної секунди. Якщо для кожного доказу потрібно 2 ГБ пам'яті, то загалом потрібно петабайтовий обсяг ОЗП. Подальше зменшення використання пам'яті є критично важливим для неблокчейн розгортання.
Передкомпіляція: останній мильний варіант чи киянка?
У zkVM дизайні, підготовка означає спеціалізовану SNARK (або систему обмежень), яка спеціально налаштована для конкретних функцій, таких як хеш-функція Keccak/SHA або операції над кривими еліптичними групами, використовувані для цифрового підпису. У Ethereum (де більшість важких завдань пов'язані з хеш-функціями Merkle та перевіркою підписів), декілька ручно виготовлених підготовок можуть зменшити витрати доведення. Однак роблячи їх опорою, не можна досягти мети, яку потребує SNARK. Причина полягає в наступному:
· Для більшості додатків (внутрішніх та зовнішніх) блокчейн все ще занадто повільний: Навіть з використанням попередньо скомпільованого хешу та підпису, поточна zkVM все ще занадто повільна (як у середовищі блокчейн, так і поза ним), оскільки основна система доведення має низьку ефективність.
· Помилка безпеки: Неперевірений належним чином рукописний попередній компілятор майже навряд чи не повністю заповнений помилками, що може призвести до катастрофічних відмов безпеки.
· Поганий досвід розробника: У більшості сучасних zkVMs додавання нових попередньо скомпільованих означає написання системи обмежень вручну для кожної функції - це суттєво повертає нас до робочого процесу стилю 1960-х років. Навіть при використанні існуючих попередніх компіляцій, розробники повинні переробляти код, щоб викликати кожну попередню компіляцію. Ми повинні оптимізувати для безпеки та досвіду розробників, а не жертвувати цими двома ради поступової продуктивності. Такий підхід тільки підтверджує, що продуктивність не досягла належного рівня.
· I/O витрати та відсутність оперативної пам'яті: Навіть якщо попередній компіляції може покращити продуктивність важких шифрувальних завдань, вони можуть не забезпечити значного прискорення для більш різноманітних завдань, оскільки вони вимагають значних витрат при передачі введення / виведення та не можуть використовувати ОП. Навіть у середовищі блокчейну, якщо ви вийдете за межі однієї такої як Ethereum однієї L1 (наприклад, ви хочете побудувати серію міжланцюжкових мостів), ви стикаєтеся з різними хеш-функціями та схемами підпису. Повторна попередня компіляція на проблемі не розширюється та приносить величезні ризики з точки зору безпеки.
З усіх цих причин нашою головною метою є підвищення ефективності нижчого рівня zkVM. Технологія найкращого zkVM також породить найкращі попередні компіляції. Я дійсно вірю, що попередні компіляції залишатимуться вкрай важливими в довгостроковому плані, але лише за умови, що вони автоматично синтезовані та офіційно перевірені. Це дозволить зберегти перевагу розробників zkVM в інтерфейсі користувача, уникаючи при цьому катастрофічних загроз безпеці. Цей підхід відображається на етапі швидкості 3.
Плановий графік
Я прогнозую, що деякі zkVM будуть реалізовані пізніше цього року: етап швидкості 1 та етап пам'яті 1. Я вважаю, що ми також зможемо досягти етапу швидкості 2 протягом наступних двох років, але наразі невідомо, чи зможемо ми досягти цієї мети без деяких нових ідей, що ще не з'явилися. Я прогнозую, що для реалізації залишкових етапів (етап швидкості 3 та етап пам'яті 2) знадобиться кілька років.
Загальний підсумок
Хоча я в цій статті окремо визначив етапи безпеки та продуктивності zkVM, ці аспекти zkVM не є повністю незалежними. З очікуванням виявлення більше помилок у zkVM, деякі помилки можуть бути виправлені тільки за значного зниження продуктивності. До досягнення zkVM етапу безпеки 2 продуктивність повинна бути відкладена.
zkVM має потенціал дійсно популяризувати докази знань, але вони все ще знаходяться на етапі початкового розвитку - повні безпекові виклики та великі витрати на продуктивність. Реклама та маркетингова пропаганда ускладнюють оцінку справжніх досягнень. Шляхом визначення чітких безпечних та продуктивних віх надіємося надати карту шляху, яка усуває зайві перешкоди. Ми досягнемо мети, але це потребує часу та постійних зусиль.
Посилання на оригінал тексту
：
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
a16z: як поетапно досягти безпеки та ефективності zkVM (обов'язково для розробників)
zkVM (Zero Knowledge Virtual Machine) зобов'язується «зробити SNARK масовим», дозволяючи будь-кому (навіть людям без професійних знань SNARK) довести, що вони правильно виконали будь-яку програму на вказаному введенні (або свідченні). Їхня основна перевага полягає в досвіді розробника, але наразі вони стикаються з великими викликами в області безпеки та продуктивності. Для того щоб втілити обіцянку візії zkVM, дизайнерам необхідно подолати ці виклики. У цій статті я перераховую можливі етапи розробки zkVM, завершення цих етапів займе кілька років.
Виклик
З точки зору безпеки zkVM є високорівневим складним програмним продуктом, який все ще містить уразливості. З точки зору продуктивності швидкість виконання програми доведення може бути на десятки тисяч разів повільніше, ніж локальний запуск, що перешкоджає більшості додатків розгортатися в реальному світі.
Незважаючи на ці реальні виклики, більшість компаній у галузі блокчейн все ще описують zkVM як що можна вразити в момент. Фактично, деякі проекти вже витрачають значні обчислювальні витрати для генерації доказів ланцюжкової діяльності. Однак, оскільки zkVM ще не є повноцінним, це лише дорогий спосіб претензійного захисту системи за допомогою SNARK, а насправді вона або захищена ліцензією, або, що гірше, легко піддається атакам.
Ми маємо кілька років, щоб забезпечити безпечну та високоефективну zkVM. Ця стаття встановлює конкретні поетапні цілі для відстеження прогресу zkVM - ці цілі можуть усунути шум та допомогти спільноті зосередитися на справжньому прогресі.
Етап безпеки
Зазвичай zkVM, заснований на SNARK, включає два основні компоненти:
· Інтерактивне підтвердження оракула поліномів (PIOP): використовується для підтвердження висловлювань про поліноми (або обмеження, які можуть бути отримані з них) в інтерактивній рамці доказу.
· Схема зобов'язань поліномів (PCS): гарантує, що доказуючий не може брехати щодо оцінки полінома, не бувши виявленим.
zkVM в сутності перетворює ефективне виконання на відстеження кодування у вигляді системи обмежень - загалом це означає, що вони змушують віртуальну машину правильно використовувати регістри та пам'ять - а потім застосовують SNARK для доведення виконання цих обмежень.
Переконайтеся, що єдиний шлях до відсутності помилок у складних системах, які збігаються, таких як zkVM, - це формальна перевірка. Ось підрозділи етапу безпеки. Етап 1 зосереджується на правильному протоколі, тоді як етапи 2 та 3 зосереджені на правильній реалізації.
Етап безпеки 1: Правильний протокол
2、PCS має силу обмежуючого доказу у формі підтвердження під певними криптографічними умовами або ідеальними моделями;
4、Система обмежень, що застосовується в PIOP, еквівалентна формальному підтвердженню семантики VM;
Попередження про рекурсію: Якщо zkVM використовується для рекурсії, то на цьому етапі вважається завершеним тільки після перевірки кожного PIOP, обіцянки та системи обмежень, що стосуються будь-якого місця у цій рекурсії.
Етап безпеки 2: Правильна реалізація перевірки
Формалізоване доведення zkVM верифікатора фактичної реалізації (використання Rust, Solidity тощо) відповідає протоколу першої фази верифікації. Це забезпечує розумність реалізованого протоколу (не лише на папері, або низькоефективні специфікації, створені з використанням Lean тощо).
Друга фаза має два аспекти, що стосуються лише реалізації перевірників (а не доводів). По-перше, правильне використання верифікатора вже достатньо для забезпечення надійності (тобто гарантії того, що верифікатор не може вірити в будь-які фальшиві заяви, які фактично є істинними). По-друге, реалізація верифікатора zkVM є простішою на порядок, ніж реалізація доводу.
Етап безпеки 3: правильна реалізація доказувача
Реальна реалізація засобів доведення zkVM правильно генерує підтвердження системи доведення для першої та другої фаз верифікації, тобто отримує формальне підтвердження. Це забезпечує цілісність, тобто жодне заявлення, яке не може бути доведено, не може «застрягти» в будь-якій системі, що використовує zkVM. Якщо засіб доведення має намір реалізувати нульове знання, то цю властивість необхідно формально підтвердити.
Плановий графік
· Етап 1: Прогрес: Ми можемо очікувати поступових досягнень у наступному році (наприклад, ZKLib). Проте протягом щонайменше двох років жоден zkVM не зможе повністю задовольнити вимоги першого етапу;
· Крок 2 та крок 3: Ці етапи можуть взаємодіяти з деякими аспектами Кроку 1 одночасно. Наприклад, деякі команди вже довели, що реалізація перевірника Plonk відповідає протоколу з документації (навіть якщо сам протокол з документації може бути не повністю перевірений). Проте я не очікую, що будь-яка zkVM досягне Кроку 3 менш як за чотири роки — і можливо, навіть довше.
Ключові пункти: безпека Fiat-Shamir та перевірений байт-код
Один із головних складних чинників полягає в тому, що навколо безпеки перетворення Фіата-Шамира існують невирішені дослідницькі питання. Усі три етапи розглядають Фіата-Шамира та випадковий оракул як частину їхньої бездоганної безпеки, але насправді весь парадигма може мати вразливості. Це через те, що випадковий оракул занадто ідеалізований та відмінності між ним та фактично використовуваними хеш-функціями. У найгіршому випадку система, яка вже перейшла до другого етапу через проблему Фіата-Шамира, може виявитися абсолютно небезпечною. Це викликає серйозну тривогу та постійні дослідження. Можливо, нам знадобиться модифікувати саме перетворення для кращого запобігання таким вразливостям.
Система без рекурсії в теорії є більш стійкою, оскільки деякі відомі атаки включають схеми, схожі на схеми, що використовуються в рекурсивних доведеннях.
Ще одним важливим аспектом є те, що якщо байт-код має дефекти, то навіть після правильного виконання комп'ютерної програми (за допомогою вказаного байт-коду) його цінність обмежена. Тому практична цінність zkVM в значній мірі залежить від методу генерації формалізованої верифікації байт-коду - це великий виклик, який виходить за межі обговорення цього документа.
Про безпеку у постквантову епоху
Принаймні протягом наступних п'яти років (можливо, навіть довше) квантові комп'ютери не будуть становити серйозної загрози, а уразливості - це форма життєвого ризику. Тому наразі головний акцент слід зробити на задоволення вимог щодо безпеки і продуктивності, які обговорюються у цьому документі. Якщо ми можемо швидше задовольнити ці вимоги безпеки за допомогою не-квантово-безпечних SNARK, то ми повинні це зробити, доки пізніше квантово-безпечний SNARK не наздожене, або доки люди серйозно не почнуть турбуватися про застосування квантових комп'ютерів у криптографії.
Поточний стан продуктивності zkVM
Наразі коефіцієнт витрат zkVM доказувача наближається до вартості виконання майже на 1 мільйон разів. Якщо програмі потрібно X циклів для виконання, то вартість доказу правильного виконання становить близько X помножити на 1 мільйон циклів процесора. Це було так рік тому, і це так і зараз.
Популярні наративи зазвичай описують ці витрати таким чином, що звучить прийнятно. Наприклад:
·「Витрати на генерацію доказів роботи головної мережі Ethereum становлять менше ніж один мільйон доларів на рік.」
Ми майже можемо використовувати кластер, що складається з десятків GPU, для генерації доказів блоків Ethereum у реальному часі.
·「Наш новий zkVM працює в 1000 разів швидше, ніж його попередник.」
Хоча технічно ці висловлювання є точними, але без належного контексту вони можуть бути вводячими у помилку. Наприклад:
· Порівняно з попередньою версією zkVM швидкість зросла в 1000 разів, але абсолютна швидкість все ще дуже повільна. Це, скоріш за все, свідчить про те, наскільки погано все виявилося, а не наскільки добре.
· Хтось вже запропонував збільшити обчислювальну потужність головної мережі Ethereum у 10 разів. Це зробить поточну продуктивність zkVM повільнішою.
· Те, що люди називають «майже в реальному часі доказом Ефіріум-блоку», все ще набагато повільніше, ніж вимагає багато додатків блокчейну (наприклад, час блокування оптимізму станом на 2 секунди, це набагато швидше, ніж час блокування Ефіріуму на 12 секунд).
·「Десятки GPU постійно працюють, без жодних помилок」не може забезпечити задовільну гарантію активності.
· Кожного року витрачається менше одного мільйона доларів, щоб довести, що всі дії на головній мережі Ethereum відображають той факт, що для виконання обчислень на повній вузлі Ethereum щороку потрібно лише приблизно 25 доларів.
Для додатків поза блокчейном такі витрати, очевидно, є надто великими. Жодна паралельність або інженерія не здатна компенсувати такі великі витрати. Ми повинні вважати швидкість zkVM найбільш базовим бенчмарком порівняно з нативним виконанням - навіть якщо це лише перший крок. Справжня масова участь можливо знадобиться приблизно в 10 000 разів менших витрат або ще менше.
Як виміряти продуктивність
SNARK має три основні складові частини продуктивності:
· Внутрішня ефективність системи підтвердження на нижньому рівні.
· Оптимізація, специфічна для додатків (наприклад, попередня компіляція).
· Інженерія та апаратне прискорення (наприклад, GPU, FPGA або багатоядерний CPU).
Хоча останні дві надзвичайно важливі для реального впровадження, вони, як правило, застосовуються до будь-якої системи доказів, тому вони не обов'язково відображають основні витрати. Наприклад, у zkEVM додавання прискорення GPU та попередньої компіляції може легко забезпечити 50-кратне прискорення, що набагато швидше, ніж чистий метод без попередньої компіляції, заснований на CPU - достатньо, щоб система з суттєво меншою ефективністю виглядала краще, ніж система без такого самого полірування.
Отже, нижче наведено основні характеристики продуктивності SNARK без спеціалізованого апаратного забезпечення та попередньої компіляції. Це відрізняється від поточного методу базового тестування, який зазвичай об'єднує всі три фактори в одне "число заголовка". Це відповідає визначенню вартості діаманта на основі часу полірування, а не його внутрішньої чистоти. Нашою метою є виключення внутрішніх витрат загальної системи доведення - допомога спільноті усунути різноманітні фактори, щоб сконцентруватися на справжніх досягненнях в дизайні системи доведення.
Етап продуктивності
Ось 5 віх здійснення продуктивності. По-перше, нам потрібно зменшити витрати на доведення на CPU на кілька порядків величини. Тільки тоді увага повинна перейти на подальше зменшення через апаратне забезпечення. Також потрібно підвищити використання пам'яті.
На всіх етапах розробки розробники не повинні робити налаштування коду відповідно до zkVM для досягнення необхідної продуктивності. Враження розробників є основною перевагою zkVM. Жертвувати DevEx для відповідності продуктивності порушує сенс самого zkVM.
Ці показники зосереджені на витратах для підтверджуючого. Однак якщо дозволити необмежені витрати на підтвердження (тобто немає верхньої межі для розміру доказу або часу підтвердження), то будь-які показники підтвердження можна легко задовольнити. Тому для системи, яка має відповідати описаному етапу, необхідно визначити максимальні значення розміру доказу та часу підтвердження.
вимоги до продуктивності
Етап 1 вимагає: "розумних та неординарних витрат на підтвердження":
· Розмір доказу: Розмір доказу повинен бути меншим за розмір свідоцтва.
· Час перевірки: швидкість підтвердження доказу не може бути повільніше, ніж швидкість виконання локальної програми (тобто виконання обчислення без підтвердження правильності).
Це мінімальні вимоги щодо конкретності. Вони гарантують, що розмір доказу та час підтвердження не будуть гіршими, ніж метод надсилання свідчень валідаторам та дозвіл на безпосередню перевірку їх правильності від валідатора.
Вимоги на етапі 2 та пізніше:
· Максимальний розмір підтвердження: 256 КБ.
· Максимальний час перевірки: 16 мс.
Ці межі були наміренно збільшені для відповідності новій швидкій технології підтвердження, яка може призвести до вищих витрат на підтвердження. Водночас вони виключають дуже дорогі підтвердження, через що майже жоден проект не бажає включати їх в блокчейн.
Етап швидкості 1
Доказательство однопоточності повинно бути принаймні в десять тисяч разів повільнішим за локальне виконання у серії застосунків (не лише блоків Ethereum), не покладаючись на попередню компіляцію.
Конкретно, уявіть собі процес RISC-V, який працює на сучасному ноутбуці приблизно 30 мільярдів разів на секунду. Завершення першої фази означає, що ви можете довести приблизно 30,000 циклів RISC-V на секунду (однопотоково) на тому ж самому ноутбуці. Однак вартість верифікації повинна бути «розумною та не банальною», як вище зазначено.
Етап швидкості 2
Доказ про один потік повинен бути повільнішим на найбільше десять тисяч разів, ніж локальне виконання.
Або, через обмеження поточних ЦП та ГПУ, зумовлене деякими перспективними методами SNARK (особливо тими, що базуються на бінарних полях), ви можете досягти цього етапу, порівнюючи використання FPGA (навіть ASIC):
FPGA може емулювати кількість ядер RISC-V зі швидкістю локального обчислення;
Моделювання та демонстрація (майже) в реальному часі кількості FPGA, необхідних для виконання RISC-V.
Якщо друге число не більше першого у 10, 000 разів, ви маєте право на вхід до другої фази. На стандартному процесорі розмір доказу повинен бути не більш як 256 КБ, а час перевірки - не більше 16 мілісекунд.
Етап швидкості 3
Крім досягнення швидкісної фази 2, можна використовувати автоматичне синтезування та попередню компіляцію для зниження витрат на докази на порядок менше 1000 разів (що підходить для широкого спектру додатків). Фактично, для кожної програми можна динамічно налаштувати набір інструкцій для прискорення доведення, проте це слід зробити таким чином, щоб його можна було легко використовувати та перевіряти формально.
Етап пам'яті 1
Швидкість у першому етапі досягається при умові, що потребується менше 2 ГБ пам'яті в доведенні (одночасно досягається нульове знання).
Це надзвичайно важливо для багатьох мобільних пристроїв або браузерів, тому відкрито безліч випадків використання zkVM клієнтом. Клієнтське підтвердження є дуже важливим, оскільки наші мобільні телефони - це наш постійний зв'язок з реальним світом: вони відстежують наше місце знаходження, підтвердження тощо. Якщо для генерації підтвердження потрібно більше 1-2 ГБ пам'яті, то це занадто багато для більшості сучасних мобільних пристроїв. Є дві речі, які потрібно уточнити:
· 2 ГБ обмеження простору відноситься до великих запитів (заявки, які вимагають мільярди циклів ЦП для локального виконання). Системи доказу обмеження простору для невеликих запитів мають обмежену застосовність.
· Якщо доведець дуже повільний, то дуже легко утримувати простір доведця в межах 2 ГБ пам'яті. Тому, щоб зробити етап 1 пам'яті не настільки простим, я прошу задовольнити швидкість етапу 1 в межах 2 ГБ обмеження простору.
Етап пам'яті 2
Швидкість етапу 1 досягається при обсязі використання пам'яті менше 200 МБ (на 10 разів краще, ніж етап 1 пам'яті).
Чому потрібно обмежитися 2 ГБ? Розгляньте не блокчейн приклад: кожного разу, коли ви відвідуєте веб-сайт через HTTPS, ви завантажуєте сертифікат для автентифікації та шифрування. Натомість сайт може вислати докази знань з цими сертифікатами. Великі веб-сайти можуть видалити мільйони таких доказів кожної секунди. Якщо для кожного доказу потрібно 2 ГБ пам'яті, то загалом потрібно петабайтовий обсяг ОЗП. Подальше зменшення використання пам'яті є критично важливим для неблокчейн розгортання.
Передкомпіляція: останній мильний варіант чи киянка?
У zkVM дизайні, підготовка означає спеціалізовану SNARK (або систему обмежень), яка спеціально налаштована для конкретних функцій, таких як хеш-функція Keccak/SHA або операції над кривими еліптичними групами, використовувані для цифрового підпису. У Ethereum (де більшість важких завдань пов'язані з хеш-функціями Merkle та перевіркою підписів), декілька ручно виготовлених підготовок можуть зменшити витрати доведення. Однак роблячи їх опорою, не можна досягти мети, яку потребує SNARK. Причина полягає в наступному:
· Для більшості додатків (внутрішніх та зовнішніх) блокчейн все ще занадто повільний: Навіть з використанням попередньо скомпільованого хешу та підпису, поточна zkVM все ще занадто повільна (як у середовищі блокчейн, так і поза ним), оскільки основна система доведення має низьку ефективність.
· Помилка безпеки: Неперевірений належним чином рукописний попередній компілятор майже навряд чи не повністю заповнений помилками, що може призвести до катастрофічних відмов безпеки.
· Поганий досвід розробника: У більшості сучасних zkVMs додавання нових попередньо скомпільованих означає написання системи обмежень вручну для кожної функції - це суттєво повертає нас до робочого процесу стилю 1960-х років. Навіть при використанні існуючих попередніх компіляцій, розробники повинні переробляти код, щоб викликати кожну попередню компіляцію. Ми повинні оптимізувати для безпеки та досвіду розробників, а не жертвувати цими двома ради поступової продуктивності. Такий підхід тільки підтверджує, що продуктивність не досягла належного рівня.
· I/O витрати та відсутність оперативної пам'яті: Навіть якщо попередній компіляції може покращити продуктивність важких шифрувальних завдань, вони можуть не забезпечити значного прискорення для більш різноманітних завдань, оскільки вони вимагають значних витрат при передачі введення / виведення та не можуть використовувати ОП. Навіть у середовищі блокчейну, якщо ви вийдете за межі однієї такої як Ethereum однієї L1 (наприклад, ви хочете побудувати серію міжланцюжкових мостів), ви стикаєтеся з різними хеш-функціями та схемами підпису. Повторна попередня компіляція на проблемі не розширюється та приносить величезні ризики з точки зору безпеки.
З усіх цих причин нашою головною метою є підвищення ефективності нижчого рівня zkVM. Технологія найкращого zkVM також породить найкращі попередні компіляції. Я дійсно вірю, що попередні компіляції залишатимуться вкрай важливими в довгостроковому плані, але лише за умови, що вони автоматично синтезовані та офіційно перевірені. Це дозволить зберегти перевагу розробників zkVM в інтерфейсі користувача, уникаючи при цьому катастрофічних загроз безпеці. Цей підхід відображається на етапі швидкості 3.
Плановий графік
Я прогнозую, що деякі zkVM будуть реалізовані пізніше цього року: етап швидкості 1 та етап пам'яті 1. Я вважаю, що ми також зможемо досягти етапу швидкості 2 протягом наступних двох років, але наразі невідомо, чи зможемо ми досягти цієї мети без деяких нових ідей, що ще не з'явилися. Я прогнозую, що для реалізації залишкових етапів (етап швидкості 3 та етап пам'яті 2) знадобиться кілька років.
Загальний підсумок
Хоча я в цій статті окремо визначив етапи безпеки та продуктивності zkVM, ці аспекти zkVM не є повністю незалежними. З очікуванням виявлення більше помилок у zkVM, деякі помилки можуть бути виправлені тільки за значного зниження продуктивності. До досягнення zkVM етапу безпеки 2 продуктивність повинна бути відкладена.
zkVM має потенціал дійсно популяризувати докази знань, але вони все ще знаходяться на етапі початкового розвитку - повні безпекові виклики та великі витрати на продуктивність. Реклама та маркетингова пропаганда ускладнюють оцінку справжніх досягнень. Шляхом визначення чітких безпечних та продуктивних віх надіємося надати карту шляху, яка усуває зайві перешкоди. Ми досягнемо мети, але це потребує часу та постійних зусиль.
Посилання на оригінал тексту
：