Нульова віртуальна машина з нульовим знанням (zkVMs) має на меті «зробити SNARKs доступними для мас». Це дозволяє навіть тим, хто не має спеціальних знань про SNARK, довести, що вони правильно працюють з певною програмою на конкретному вході (або свідченні). Її основні переваги полягають у досвіді розробника, але наразі zkVMs все ще стикається з великими викликами щодо безпеки та продуктивності. Щоб zkVMs могли виправдати свої обіцянки, розробники повинні подолати ці перешкоди. У цій статті буде розглянуто можливі етапи розвитку zkVM, які в цілому можуть зайняти кілька років, щоб завершити - не вірте нікому, хто говорить, що це можна зробити дуже швидко.
Ставлені виклики
З точки зору безпеки, zkVMs - це високорівневий складний програмний проект, який все ще має вразливості.
У сфері продуктивності доведення правильності виконання програми може бути повільніше за природну роботу на декілька десятків тисяч разів, що робить більшість застосунків непридатними для реального світу наразі.
Незважаючи на це, багато голосів у галузі блокчейн все ще просувають zkVMs вже можуть бути розгорнуті негайно, навіть деякі проекти вже платять високі витрати на обчислення для генерації доказів знань на ланцюжку. Однак, через те, що у zkVMs все ще існують численні уразливості, цей підхід фактично є дорогою маскою, що робить систему схожою на те, що її захищає SNARK, а насправді вона або ґрунтується на контролі дозволів, або, що гірше, відкрита для ризику атак.
Фактично, нам ще декілька років далеко від побудови дійсно безпечного та ефективного zkVM. У цій статті висуваються конкретні та поетапні цілі, які допоможуть нам відстежувати реальний прогрес zkVM, зменшувати маніпулювання та спрямовувати увагу спільноти на справжні технічні досягнення.
Етап розвитку безпеки
фон
На основі SNARKzkVMs зазвичай містять два основні компоненти:
Доказательство полиномиального интерактивного оракула (PIOP): используется для доказательства интерактивной структуры многочлена (или ограничений, происходящих от многочлена).
Схема зобов'язання поліномом (Polynomial Commitment Scheme, PCS): забезпечує відсутність можливості доказувачу підробляти результати оцінки полінома без виявлення.
zkVM, роблячи кодування ефективних виконавчих траєкторій у систему обмежень, гарантує правильне використання реєстру та пам'яті віртуальної машини, а потім використовує SNARK для підтвердження виконання цих обмежень.
У такій складній системі єдиним способом гарантувати відсутність помилок у zkVM єформалізована перевірка. Ось різні етапи безпеки zkVM, де перший етап спрямований на правильність протоколу, другий і третій етапи спрямовані на правильність реалізації.
Етап 1 безпеки: правильний протокол
ПІОР офіційне підтвердження надійності;
PCS має силу формального доказу під певними криптографічними умовами або в ідеальній моделі;
Якщо використовується Fiat-Shamir, то сполучення PIOP та PCS отримане коротке доведення є формальним підтвердженням безпеки в рамках моделі випадкового пророку (за потреби з використанням інших криптографічних припущень для посилення);
Система обмежень, яка використовується в PIOP, еквівалентна доказу формальної перевірки семантики VM;
Усі ці частини повинні бути повністю "склеєні" в одне єдине, формалізоване підтвердження безпеки SNARK, яке може використовуватися для виконання будь-якої програми, яка вказана у байткоді VM. Якщо протокол передбачає нульове розголошення, ця властивість також повинна бути формалізовано перевірена, щоб уникнути розкриття чутливої інформації про свідка.
Якщо zkVM використовує рекурсію, то PIOP, ангажованість та система зобов'язань, що залучені у процесі рекурсії, мають бути перевірені, інакше цей підетап не може вважатися завершеним.
Етап 2 безпеки: правильна реалізація перевірки
На цьому етапі потрібно провести формальну верифікацію практичної реалізації перевіряча zkVM (наприклад, на Rust, Solidity тощо), щоб забезпечити відповідність його протоколу, який був перевірений на першому етапі. Завершення цього етапу означає, що реалізація zkVM відповідає теоретичному дизайну, а не просто є безпечним протоколом на папері або низькоефективним специфікацією, написаною мовами, такими як Lean тощо.
Чому лише перевірка валідатора, а не перевірка доведення має дві основні причини: по-перше, переконатися, що валідатор правильний, достатньо для забезпечення повноти системи доведення zkVM (тобто: переконатися, що валідатор не буде обманутий, щоб прийняти неправильне доведення). По-друге, реалізація валідатора zkVM простіша на порядок, ніж реалізація доведення, тому правильність валідатора легше забезпечити в найближчий час.
Етап безпеки 3: Правильна реалізація доказувача
На цьому етапі потрібно здійснити формальне підтвердження фактичної реалізації провідника zkVM, щоб забезпечити його правильне генерування доказів системи, які вже були перевірені на першому та другому етапах. Метою цього етапу є повнота, тобто: будь-яка система, яка використовує zkVM, не замерзне через неможливість довести законний вислів. Якщо zkVM повинен мати властивість нульового відомості, необхідно забезпечити формальне підтвердження, щоб гарантувати, що доказ не розголошуватиме жодної інформації про свідчення.
Часовий графік
Етап 1 розвитку: ми можемо очікувати певних досягнень на наступний рік (наприклад, ZKLib - це один із таких зусиль). Але протягом принаймні двох років жоден zkVM не зможе повністю відповідати вимогам першого етапу.
Етап 2 та Етап 3: Ці етапи можуть розвиватися паралельно з деякими аспектами Етапу 1. Наприклад, деякі команди вже довели відповідність реалізації валідатора Plonk до протоколу у публікації (навіть якщо сам протокол у публікації можливо не був повністю перевірений). Однак я очікую, що жодна zkVM не досягне Етапу 3 протягом менше ніж чотири роки - можливо, навіть довше."
Ключові питання: безпека Fiat-Shamir та перевірений байт-код
Однією з основних проблем складності є те, що безпека перетворення Фіата-Шамира все ще має невирішені досліджувані проблеми. Усі три етапи безпеки розглядають Фіата-Шамира та випадкового передбачувача як абсолютно безпечні, але фактично весь парадигма може мати вразливості. Це пов'язано з різницею між ідеалізованою моделлю випадкового передбачувача та фактично використовуваною функцією хешування.
У найгіршому випадку система, яка вже досягла етап безпеки 2, може бути повністю небезпечною через проблеми, пов'язані з Fiat-Shamir. Це вимагає нашої великої уваги та постійних досліджень. Можливо, нам потрібно змінити саме перетворення Fiat-Shamir, щоб краще захищатися від таких уразливостей.
Система без рекурсії в теорії є безпечнішою, оскільки деякі відомі атаки включають схеми, подібні до схем, що використовуються в рекурсивних доказах. Проте цей ризик залишається невирішеним основним питанням.
Іншою проблемою, на яку варто звернути увагу, є те, що навіть якщо zkVM доводить, що певна обчислювальна програма (визначена байт-кодом) була виконана правильно, але якщо сам байт-код має дефекти, то цей доказ має дуже обмежену цінність. Тому практичність zkVM в значній мірі залежить від того, як генерувати байт-код, піддаючийся формальній перевірці, і цей виклик є надзвичайно великим і виходить за межі обговорення цієї статті.
Про квантово-стійкість
Протягом принаймні 5 років (і, можливо, ще довше) квантові комп'ютери не будуть становити серйозної загрози, в той час як програмні помилки є життєво важливою проблемою. Тому головним завданням зараз є досягнення поставлених у цій статті цілей забезпечення безпеки та продуктивності. Якщо неквантові SNARKs можуть швидше відповідати цим цілям, ми повинні надавати їм перевагу. Чекаємо, коли квантові SNARKs догонять розвиток, або коли з'являться ознаки того, що квантові комп'ютери, які мають реальну загрозу, наближаються, перш ніж робити перемикання.
Конкретний рівень безпеки
100-бітна класична безпека є мінімальним стандартом для будь-якого SNARK, який застосовується для захисту цінних активів (але все ще є деякі системи, які не відповідають цьому стандарту). Однак це все ще не може бути прийнято, оскільки стандартна криптографічна практика зазвичай вимагає безпеки на рівні 128 біт та вище. Якщо продуктивність SNARK дійсно відповідає стандартам, ми не повинні знижувати безпеку для поліпшення продуктивності.
Етап продуктивності
Поточна ситуація
Наразі обчислювальні витрати zkVM провідника становлять близько 1 мільйон разів більше, ніж виконання на місці. Іншими словами, якщо для виконання програми потрібно X циклів процесора, то створення правильного виконання доказу займе приблизно X × 1,000,000 циклів процесора. Це було так рік тому і залишається таким і досі (незважаючи на деякі непорозуміння).
Деякі популярні вислови в галузі можуть призвести до неправильного розуміння, наприклад:
**«Вартість генерації доказів для всієї основної мережі Ethereum менше, ніж 1 мільйон доларів США щороку.»
Ми майже досягли миттєвого створення доказів блоків Ethereum, потрібно лише декілька десятків GPU.
"Наша остання zkVM вдосконалена в 1000 разів швидше, ніж попередня версія."
Проте ці висловлювання без контексту можуть бути оманливими:
• Порівняно зі старою версією zkVM, це може бути на тисячу разів швидше, але все одно може бути дуже повільним, це більше стосується того, наскільки погано було колись, а не наскільки добре зараз.
• Обсяг обчислень на головній мережі Ethereum може збільшитися у майбутньому у 10 разів, що значно поставить під загрозу поточну продуктивність zkVM.
• Так званий "майже реальний час" генерації доказів залишається надто повільним для багатьох застосувань блокчейну (наприклад, час блоку в Оптимізмі становить 2 секунди, що набагато швидше, ніж 12 секунд на Ethereum).
• «Десятки GPU, які працюють 24/7 протягом тривалого часу», насправді не можуть забезпечити достатньої гарантії активності.
• Час генерації цих доказів, як правило, стосується розміру доказів понад 1 МБ, що для багатьох додатків є занадто великим.
• "Витрати менше 1 мільйона доларів на рік" лише через те, що повний вузол Ethereum виконує лише близько 25 доларів обчислень на рік.
Для застосувань поза сферою блокчейну цей обчислювальний витрата, очевидно, дуже висока. Незалежно від того, скільки паралельних обчислень або інженерних оптимізацій, не вдасться компенсувати такі величезні обчислювальні витрати.
Нашою основною метою повинно бути зменшення витрат на продуктивність не більше ніж в 100 000 разів порівняно з виконанням носія. Однак це все одно лише перший крок. Щоб досягти справжнього широкомасштабного використання, можливо, нам знадобиться зменшити витрати до 10 000 разів або навіть менше, ніж виконання носія.
Вимірювання продуктивності
SNARK має три основні складові частини продуктивності:
Ефективність фіксованої системи доказів на нижньому рівні.
Оптимізація для конкретних застосувань (наприклад, попереднє компілювання).
Інженерія та апаратне прискорення (наприклад, GPU, FPGA або багатоядерний CPU).
Хоча (2) та (3) надзвичайно важливі для фактичного впровадження, вони застосовуються до будь-якої системи доведення, тому не обов'язково відображають покращення базових витрат. Наприклад, додавання прискорення GPU та попередньої компіляції до zkEVM може легко забезпечити швидкість в 50 разів вище, ніж просте покладання на CPU - це може зробити систему, яка ефективна на перший погляд, краще за іншу систему, яка не була оптимізована так само.
Отже, у цій статті основна увага приділяється основним характеристикам SNARK без спеціалізованого обладнання та попереднього компілювання. Це відрізняється від поточних методів базового тестування, які зазвичай об'єднують усі три фактори в одне «загальне числове значення». Це схоже на оцінку блиску діаманта за часом полірування, а не за його вродженою чистотою.
Наша мета полягає в відокремленні власних витрат універсальної системи доведення, зниженні порогу входження для технологій, які ще не були глибоко досліджені, та допомозі спільноті у виключенні завад, що дозволить сфокусуватися на справжніх досягненнях у дизайні системи доведення.
Етап продуктивності
Ось п'ять ключових віхових етапів продуктивності, які я висунув. По-перше, нам потрібно значно зменшити витрати від учасників на ЦП, щоб далі зменшувати витрати за рахунок апаратного забезпечення. У той же час також потрібно покращити використання пам'яті.
На всіх етапах розробникам не слід змінювати код для покращення продуктивності zkVM. Враження розробника - це основна перевага zkVM. Якщо для досягнення показників продуктивності жертвувати DevEx, це не лише позбавить тестування змісту, а й суперечить первісній меті zkVM.
Ці показники в основному стосуються витрат на доказ. Однак якщо дозволити необмежене зростання витрат на перевірку (тобто без обмеження розміру доказу або часу перевірки), то будь-які показники доказу можуть легко виконати. Тому для виконання вимог цієї стадії необхідно обмежити як максимальний розмір доказу, так і максимальний час перевірки.
Етап 1 вимога: "розумні витрати на незвичайні перевірки"
• Розмір доказу повинен бути меншим, ніж розмір свідоцтва.
• Час перевірки: Швидкість підтвердження доказів не повинна бути повільнішою, ніж виконання програми нативно (тобто не повільніше виконання обчислень).
Це вимоги мінімальної простоти, щоб забезпечити, що розмір доказу та час перевірки не будуть гіршими, ніж при безпосередньому надсиланні підтвердження валідатору та його безпосередньому перевірці.
Етап 2 та вище
• Максимальний розмір доказу：256 KB。
• Максимальний час перевірки: 16 мілісекунд.
Ці обмеження намагалися створити досить широкими, щоб вони відповідали новітній швидкій технології підтвердження, навіть якщо вона може призвести до вищих витрат на підтвердження. Тим часом ці обмеження виключають підтвердження, вартість яких така висока, що майже жоден проєкт не буде користуватися ним на блокчейні.
Етап швидкості 1
Доказательство медленної швидкості одного потоку не повинно бути більшим за 100 000 разів порівняно з виконанням у нативному режимі (для різних застосувань, а не лише для блокування доведення Ethereum), і не повинно бути залежним від попередньої компіляції.
Зокрема, якщо припустити, що швидкість роботи процесора RISC-V на сучасному ноутбуці становить близько 30 мільярдів циклів на секунду, то досягнення етапу 1 означає, що цей ноутбук може генерувати докази зі швидкістю 30,000 циклів RISC-V на секунду (однопотоково).
Вартість валідатора повинна відповідати раніше визначеному стандарту «розумної не-тривіальної вартості перевірки».
Швидкісний етап 2
Доведення однонитковості не повинно бути повільнішим за природне виконання більше ніж у 10,000 разів.
АБО, через деякі перспективні методи SNARK (особливо у бінарному полі SNARK), обмежені поточними CPU та GPU, можна задовольнити цю фазу за допомогою FPGA (навіть ASIC):
Обчисліть кількість ядер RISC-V, які моделюються FPGA зі швидкістю оригіналу.
Розрахуйте, симулюйте та доведіть кількість FPGA, необхідних для виконання RISC-V (майже в реальному часі).
Якщо кількість (2) не перевищує 10 000 разів (1), то виконано етап 2.
• Розмір довідки：максимум 256 КБ.
• Час перевірки: максимум 16 мілісекунд на стандартному процесорі CPU.
Етап швидкості 3
Досягніть накладних витрат на доказ протягом 1000× на вершині Speed Stage 2 (для широкого спектру застосувань) і повинні використовувати попередню компіляцію для автоматичного синтезу та формальної перевірки. По суті, набір інструкцій кожної програми динамічно налаштовується для прискорення генерації доказів, але він повинен бути простим у використанні та офіційно перевіреним. (Див. наступний розділ про те, чому попередня компіляція — це палиця з двома кінцями, і чому «рукописна» попередня компіляція не є стійким підходом.) ）
Етап пам'яті 1
Під час фази 1 швидкості використовується менше 2 ГБ пам'яті, і водночас виконується відповідно до вимог нульового знання. Ця фаза надзвичайно важлива для пересувних пристроїв або браузерів і відкриває двері для багатьох клієнтів zkVM. Наприклад, смартфони використовуються для захисту конфіденційності місцезнаходження, учбових довідок тощо. Якщо генерація підтверджень вимагає більше 1-2 ГБ пам'яті, то більшість пересувних пристроїв не зможуть це виконати.
Два важливі пояснення:
Навіть для великомасштабних обчислень (які вимагають виконання власними силами кілька трильйонів циклів процесора), система доводу також має обмеження в 2 ГБ пам'яті, інакше буде обмежена її придатність.
Якщо довести, що швидкість дуже повільна, то легко зберегти ліміт пам'яті 2 ГБ. Тому для того, щоб етап пам'яті 1 мав сенс, необхідно досягти швидкості етапу 1 в межах обмеження пам'яті 2 ГБ.
етап пам'яті 2
під час використання менше ніж 200 МБ пам'яті досягти етапу швидкості 1 (що вдвічі перевищує етап пам'яті 1).
Чому потрібно зменшити до 200 МБ? Розгляньте сценарій, що не стосується блокчейну: коли ви відвідуєте веб-сайт по HTTPS, ви завантажуєте аутентифікаційні та шифрувальні сертифікати. Якщо веб-сайт перейде на відправлення цих сертифікатів у формі zk-довідок, великі веб-сайти можуть потребувати генерації мільйонів довідок за секунду. Якщо кожна довідка потребує 2 ГБ пам'яті, потреби у обчислювальних ресурсах досягнуть рівня PB, що очевидно неможливо. Таким чином, подальше зменшення використання пам'яті для додатків, що не стосуються блокчейну, є надзвичайно важливим.
Попередня компіляція: останній відрізок або киянка?
Попередня компіляція означає оптимізовану систему обмежень SNARK, спеціально призначену для певних функцій (наприклад, хешування, еліптичні криві підписи). У Ethereum попередня компіляція дозволяє знизити витрати на перевірку хешу Меркла та підпису, але надмірна залежність від попередньої компіляції не дозволяє справжньо підвищити основну ефективність SNARK.
Проблема попередньої компіляції
1.Надто повільний: Навіть з використанням підготовлених хешів та підписів, zkVM все ще має проблему низької ефективності основної системи доведення як на ланцюжку, так і поза ним.
2. Помилки безпеки: Якщо передкомпіляція рукопису не пройшла формалізовану перевірку, то майже неминуче виникнуть помилки, які можуть призвести до катастрофічних випадків невдачі у безпеці.
3. Поганий досвід розробника: Наразі багато zkVM потребує від розробників ручного написання систем обмежень, схоже на спосіб програмування 1960-х років, що серйозно впливає на досвід розробки.
4.Тестування в базовому варіанті може бути вводить у помилку: якщо тестування в базовому варіанті залежить від оптимізації певного попереднього компіляції, це може ввести в оману увагу людей, спрямовану на оптимізацію ручних обмежень системи, а не на покращення самого дизайну SNARK.
5. Витрати на введення/виведення та відсутність доступу до ОЗП Хоча попередня компіляція може покращити продуктивність важких задач з шифрування, вона може бути неефективною для більш різноманітних завдань, оскільки при передачі введення/виведення вона створює значні витрати, і не може використовувати ОЗП.
Навіть у середовищі блокчейну, якщо ви перевищили одиничну L1, таку як Ethereum (наприклад, ви хочете побудувати серію міжланцюжкових мостів), ви стикаєтеся з різними функціями хешування та схемами підпису. Щоб вирішити цю проблему, постійно виконується попереднє компілювання, що є некомплексним і приносить великий ризик безпеки.
Я справді вірю, що попередня компіляція залишається важливою з довгострокової точки зору, але лише після їх автоматичного синтезу та офіційної перевірки. Таким чином, ми можемо забезпечити перевагу розробників zkVM, уникнувши при цьому катастрофічних безпекових ризиків. Ця думка відображена в етапі 3.
Плановий графік
Я очікую, що деякі zkVM досягнуть етапу швидкості 1 та етапу пам'яті 1 до кінця цього року. Я вважаю, що протягом наступних двох років ми також зможемо досягти етапу швидкості 2, але наразі неясно, чи можливо це без нового напрямку досліджень.
Я передбачаю, що решта етапів (швидкість етап 3 та пам'ять етап 2) займе кілька років, щоб досягти.
Незважаючи на те, що у цій статті окремо вказано про безпеку та етапи продуктивності zkVM, ці два аспекти не є повністю незалежними. З виявленням уразливостей у zkVM я передбачую, що виправлення деяких з них неминуче призведе до значного погіршення продуктивності. Таким чином, результати тестів продуктивності zkVM до досягнення етапу безпеки 2 повинні розглядатися як тимчасові дані.
zkVM має великий потенціал у популяризації нульових доказів, але наразі він знаходиться на ранньому етапі - повний викликів у сфері безпеки та серйозних обмежень продуктивності. Ринкове хайповання та маркетингова пропаганда ускладнюють оцінку справжніх досягнень. Через чіткі відмінності у безпеці та продуктивності, я сподіваюся надати відверту дорожню карту, яка допоможе прояснити ситуацію. Ми обов'язково досягнемо цієї мети, але це займе час та постійні зусилля в галузі досліджень та інженерії.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
a16z: дослідження шляху високоефективної безпеки zkVM
Автор: Justin Thaler Джерело: a16z Переклад: Шан Оу Ба, Золотий Фінанси
Нульова віртуальна машина з нульовим знанням (zkVMs) має на меті «зробити SNARKs доступними для мас». Це дозволяє навіть тим, хто не має спеціальних знань про SNARK, довести, що вони правильно працюють з певною програмою на конкретному вході (або свідченні). Її основні переваги полягають у досвіді розробника, але наразі zkVMs все ще стикається з великими викликами щодо безпеки та продуктивності. Щоб zkVMs могли виправдати свої обіцянки, розробники повинні подолати ці перешкоди. У цій статті буде розглянуто можливі етапи розвитку zkVM, які в цілому можуть зайняти кілька років, щоб завершити - не вірте нікому, хто говорить, що це можна зробити дуже швидко.
Ставлені виклики
З точки зору безпеки, zkVMs - це високорівневий складний програмний проект, який все ще має вразливості.
У сфері продуктивності доведення правильності виконання програми може бути повільніше за природну роботу на декілька десятків тисяч разів, що робить більшість застосунків непридатними для реального світу наразі.
Незважаючи на це, багато голосів у галузі блокчейн все ще просувають zkVMs вже можуть бути розгорнуті негайно, навіть деякі проекти вже платять високі витрати на обчислення для генерації доказів знань на ланцюжку. Однак, через те, що у zkVMs все ще існують численні уразливості, цей підхід фактично є дорогою маскою, що робить систему схожою на те, що її захищає SNARK, а насправді вона або ґрунтується на контролі дозволів, або, що гірше, відкрита для ризику атак.
Фактично, нам ще декілька років далеко від побудови дійсно безпечного та ефективного zkVM. У цій статті висуваються конкретні та поетапні цілі, які допоможуть нам відстежувати реальний прогрес zkVM, зменшувати маніпулювання та спрямовувати увагу спільноти на справжні технічні досягнення.
Етап розвитку безпеки
фон
На основі SNARK zkVMs зазвичай містять два основні компоненти:
Доказательство полиномиального интерактивного оракула (PIOP): используется для доказательства интерактивной структуры многочлена (или ограничений, происходящих от многочлена).
Схема зобов'язання поліномом (Polynomial Commitment Scheme, PCS): забезпечує відсутність можливості доказувачу підробляти результати оцінки полінома без виявлення.
zkVM, роблячи кодування ефективних виконавчих траєкторій у систему обмежень, гарантує правильне використання реєстру та пам'яті віртуальної машини, а потім використовує SNARK для підтвердження виконання цих обмежень.
У такій складній системі єдиним способом гарантувати відсутність помилок у zkVM є формалізована перевірка. Ось різні етапи безпеки zkVM, де перший етап спрямований на правильність протоколу, другий і третій етапи спрямовані на правильність реалізації.
Етап 1 безпеки: правильний протокол
Якщо zkVM використовує рекурсію, то PIOP, ангажованість та система зобов'язань, що залучені у процесі рекурсії, мають бути перевірені, інакше цей підетап не може вважатися завершеним.
Етап 2 безпеки: правильна реалізація перевірки
На цьому етапі потрібно провести формальну верифікацію практичної реалізації перевіряча zkVM (наприклад, на Rust, Solidity тощо), щоб забезпечити відповідність його протоколу, який був перевірений на першому етапі. Завершення цього етапу означає, що реалізація zkVM відповідає теоретичному дизайну, а не просто є безпечним протоколом на папері або низькоефективним специфікацією, написаною мовами, такими як Lean тощо.
Чому лише перевірка валідатора, а не перевірка доведення має дві основні причини: по-перше, переконатися, що валідатор правильний, достатньо для забезпечення повноти системи доведення zkVM (тобто: переконатися, що валідатор не буде обманутий, щоб прийняти неправильне доведення). По-друге, реалізація валідатора zkVM простіша на порядок, ніж реалізація доведення, тому правильність валідатора легше забезпечити в найближчий час.
Етап безпеки 3: Правильна реалізація доказувача
На цьому етапі потрібно здійснити формальне підтвердження фактичної реалізації провідника zkVM, щоб забезпечити його правильне генерування доказів системи, які вже були перевірені на першому та другому етапах. Метою цього етапу є повнота, тобто: будь-яка система, яка використовує zkVM, не замерзне через неможливість довести законний вислів. Якщо zkVM повинен мати властивість нульового відомості, необхідно забезпечити формальне підтвердження, щоб гарантувати, що доказ не розголошуватиме жодної інформації про свідчення.
Часовий графік
Етап 1 розвитку: ми можемо очікувати певних досягнень на наступний рік (наприклад, ZKLib - це один із таких зусиль). Але протягом принаймні двох років жоден zkVM не зможе повністю відповідати вимогам першого етапу.
Етап 2 та Етап 3: Ці етапи можуть розвиватися паралельно з деякими аспектами Етапу 1. Наприклад, деякі команди вже довели відповідність реалізації валідатора Plonk до протоколу у публікації (навіть якщо сам протокол у публікації можливо не був повністю перевірений). Однак я очікую, що жодна zkVM не досягне Етапу 3 протягом менше ніж чотири роки - можливо, навіть довше."
Ключові питання: безпека Fiat-Shamir та перевірений байт-код
Однією з основних проблем складності є те, що безпека перетворення Фіата-Шамира все ще має невирішені досліджувані проблеми. Усі три етапи безпеки розглядають Фіата-Шамира та випадкового передбачувача як абсолютно безпечні, але фактично весь парадигма може мати вразливості. Це пов'язано з різницею між ідеалізованою моделлю випадкового передбачувача та фактично використовуваною функцією хешування.
У найгіршому випадку система, яка вже досягла етап безпеки 2, може бути повністю небезпечною через проблеми, пов'язані з Fiat-Shamir. Це вимагає нашої великої уваги та постійних досліджень. Можливо, нам потрібно змінити саме перетворення Fiat-Shamir, щоб краще захищатися від таких уразливостей.
Система без рекурсії в теорії є безпечнішою, оскільки деякі відомі атаки включають схеми, подібні до схем, що використовуються в рекурсивних доказах. Проте цей ризик залишається невирішеним основним питанням.
Іншою проблемою, на яку варто звернути увагу, є те, що навіть якщо zkVM доводить, що певна обчислювальна програма (визначена байт-кодом) була виконана правильно, але якщо сам байт-код має дефекти, то цей доказ має дуже обмежену цінність. Тому практичність zkVM в значній мірі залежить від того, як генерувати байт-код, піддаючийся формальній перевірці, і цей виклик є надзвичайно великим і виходить за межі обговорення цієї статті.
Про квантово-стійкість
Протягом принаймні 5 років (і, можливо, ще довше) квантові комп'ютери не будуть становити серйозної загрози, в той час як програмні помилки є життєво важливою проблемою. Тому головним завданням зараз є досягнення поставлених у цій статті цілей забезпечення безпеки та продуктивності. Якщо неквантові SNARKs можуть швидше відповідати цим цілям, ми повинні надавати їм перевагу. Чекаємо, коли квантові SNARKs догонять розвиток, або коли з'являться ознаки того, що квантові комп'ютери, які мають реальну загрозу, наближаються, перш ніж робити перемикання.
Конкретний рівень безпеки
100-бітна класична безпека є мінімальним стандартом для будь-якого SNARK, який застосовується для захисту цінних активів (але все ще є деякі системи, які не відповідають цьому стандарту). Однак це все ще не може бути прийнято, оскільки стандартна криптографічна практика зазвичай вимагає безпеки на рівні 128 біт та вище. Якщо продуктивність SNARK дійсно відповідає стандартам, ми не повинні знижувати безпеку для поліпшення продуктивності.
Етап продуктивності
Поточна ситуація
Наразі обчислювальні витрати zkVM провідника становлять близько 1 мільйон разів більше, ніж виконання на місці. Іншими словами, якщо для виконання програми потрібно X циклів процесора, то створення правильного виконання доказу займе приблизно X × 1,000,000 циклів процесора. Це було так рік тому і залишається таким і досі (незважаючи на деякі непорозуміння).
Деякі популярні вислови в галузі можуть призвести до неправильного розуміння, наприклад:
**«Вартість генерації доказів для всієї основної мережі Ethereum менше, ніж 1 мільйон доларів США щороку.»
Ми майже досягли миттєвого створення доказів блоків Ethereum, потрібно лише декілька десятків GPU.
"Наша остання zkVM вдосконалена в 1000 разів швидше, ніж попередня версія."
Проте ці висловлювання без контексту можуть бути оманливими:
• Порівняно зі старою версією zkVM, це може бути на тисячу разів швидше, але все одно може бути дуже повільним, це більше стосується того, наскільки погано було колись, а не наскільки добре зараз.
• Обсяг обчислень на головній мережі Ethereum може збільшитися у майбутньому у 10 разів, що значно поставить під загрозу поточну продуктивність zkVM.
• Так званий "майже реальний час" генерації доказів залишається надто повільним для багатьох застосувань блокчейну (наприклад, час блоку в Оптимізмі становить 2 секунди, що набагато швидше, ніж 12 секунд на Ethereum).
• «Десятки GPU, які працюють 24/7 протягом тривалого часу», насправді не можуть забезпечити достатньої гарантії активності.
• Час генерації цих доказів, як правило, стосується розміру доказів понад 1 МБ, що для багатьох додатків є занадто великим.
• "Витрати менше 1 мільйона доларів на рік" лише через те, що повний вузол Ethereum виконує лише близько 25 доларів обчислень на рік.
Для застосувань поза сферою блокчейну цей обчислювальний витрата, очевидно, дуже висока. Незалежно від того, скільки паралельних обчислень або інженерних оптимізацій, не вдасться компенсувати такі величезні обчислювальні витрати.
Нашою основною метою повинно бути зменшення витрат на продуктивність не більше ніж в 100 000 разів порівняно з виконанням носія. Однак це все одно лише перший крок. Щоб досягти справжнього широкомасштабного використання, можливо, нам знадобиться зменшити витрати до 10 000 разів або навіть менше, ніж виконання носія.
Вимірювання продуктивності
SNARK має три основні складові частини продуктивності:
Ефективність фіксованої системи доказів на нижньому рівні.
Оптимізація для конкретних застосувань (наприклад, попереднє компілювання).
Інженерія та апаратне прискорення (наприклад, GPU, FPGA або багатоядерний CPU).
Хоча (2) та (3) надзвичайно важливі для фактичного впровадження, вони застосовуються до будь-якої системи доведення, тому не обов'язково відображають покращення базових витрат. Наприклад, додавання прискорення GPU та попередньої компіляції до zkEVM може легко забезпечити швидкість в 50 разів вище, ніж просте покладання на CPU - це може зробити систему, яка ефективна на перший погляд, краще за іншу систему, яка не була оптимізована так само.
Отже, у цій статті основна увага приділяється основним характеристикам SNARK без спеціалізованого обладнання та попереднього компілювання. Це відрізняється від поточних методів базового тестування, які зазвичай об'єднують усі три фактори в одне «загальне числове значення». Це схоже на оцінку блиску діаманта за часом полірування, а не за його вродженою чистотою.
Наша мета полягає в відокремленні власних витрат універсальної системи доведення, зниженні порогу входження для технологій, які ще не були глибоко досліджені, та допомозі спільноті у виключенні завад, що дозволить сфокусуватися на справжніх досягненнях у дизайні системи доведення.
Етап продуктивності
Ось п'ять ключових віхових етапів продуктивності, які я висунув. По-перше, нам потрібно значно зменшити витрати від учасників на ЦП, щоб далі зменшувати витрати за рахунок апаратного забезпечення. У той же час також потрібно покращити використання пам'яті.
На всіх етапах розробникам не слід змінювати код для покращення продуктивності zkVM. Враження розробника - це основна перевага zkVM. Якщо для досягнення показників продуктивності жертвувати DevEx, це не лише позбавить тестування змісту, а й суперечить первісній меті zkVM.
Ці показники в основному стосуються витрат на доказ. Однак якщо дозволити необмежене зростання витрат на перевірку (тобто без обмеження розміру доказу або часу перевірки), то будь-які показники доказу можуть легко виконати. Тому для виконання вимог цієї стадії необхідно обмежити як максимальний розмір доказу, так і максимальний час перевірки.
Етап 1 вимога: "розумні витрати на незвичайні перевірки"
• Розмір доказу повинен бути меншим, ніж розмір свідоцтва.
• Час перевірки: Швидкість підтвердження доказів не повинна бути повільнішою, ніж виконання програми нативно (тобто не повільніше виконання обчислень).
Це вимоги мінімальної простоти, щоб забезпечити, що розмір доказу та час перевірки не будуть гіршими, ніж при безпосередньому надсиланні підтвердження валідатору та його безпосередньому перевірці.
Етап 2 та вище
• Максимальний розмір доказу：256 KB。
• Максимальний час перевірки: 16 мілісекунд.
Ці обмеження намагалися створити досить широкими, щоб вони відповідали новітній швидкій технології підтвердження, навіть якщо вона може призвести до вищих витрат на підтвердження. Тим часом ці обмеження виключають підтвердження, вартість яких така висока, що майже жоден проєкт не буде користуватися ним на блокчейні.
Етап швидкості 1
Доказательство медленної швидкості одного потоку не повинно бути більшим за 100 000 разів порівняно з виконанням у нативному режимі (для різних застосувань, а не лише для блокування доведення Ethereum), і не повинно бути залежним від попередньої компіляції.
Зокрема, якщо припустити, що швидкість роботи процесора RISC-V на сучасному ноутбуці становить близько 30 мільярдів циклів на секунду, то досягнення етапу 1 означає, що цей ноутбук може генерувати докази зі швидкістю 30,000 циклів RISC-V на секунду (однопотоково).
Вартість валідатора повинна відповідати раніше визначеному стандарту «розумної не-тривіальної вартості перевірки».
Швидкісний етап 2
Доведення однонитковості не повинно бути повільнішим за природне виконання більше ніж у 10,000 разів.
АБО, через деякі перспективні методи SNARK (особливо у бінарному полі SNARK), обмежені поточними CPU та GPU, можна задовольнити цю фазу за допомогою FPGA (навіть ASIC):
Обчисліть кількість ядер RISC-V, які моделюються FPGA зі швидкістю оригіналу.
Розрахуйте, симулюйте та доведіть кількість FPGA, необхідних для виконання RISC-V (майже в реальному часі).
Якщо кількість (2) не перевищує 10 000 разів (1), то виконано етап 2.
• Розмір довідки：максимум 256 КБ.
• Час перевірки: максимум 16 мілісекунд на стандартному процесорі CPU.
Етап швидкості 3
Досягніть накладних витрат на доказ протягом 1000× на вершині Speed Stage 2 (для широкого спектру застосувань) і повинні використовувати попередню компіляцію для автоматичного синтезу та формальної перевірки. По суті, набір інструкцій кожної програми динамічно налаштовується для прискорення генерації доказів, але він повинен бути простим у використанні та офіційно перевіреним. (Див. наступний розділ про те, чому попередня компіляція — це палиця з двома кінцями, і чому «рукописна» попередня компіляція не є стійким підходом.) ）
Етап пам'яті 1
Під час фази 1 швидкості використовується менше 2 ГБ пам'яті, і водночас виконується відповідно до вимог нульового знання. Ця фаза надзвичайно важлива для пересувних пристроїв або браузерів і відкриває двері для багатьох клієнтів zkVM. Наприклад, смартфони використовуються для захисту конфіденційності місцезнаходження, учбових довідок тощо. Якщо генерація підтверджень вимагає більше 1-2 ГБ пам'яті, то більшість пересувних пристроїв не зможуть це виконати.
Два важливі пояснення:
Навіть для великомасштабних обчислень (які вимагають виконання власними силами кілька трильйонів циклів процесора), система доводу також має обмеження в 2 ГБ пам'яті, інакше буде обмежена її придатність.
Якщо довести, що швидкість дуже повільна, то легко зберегти ліміт пам'яті 2 ГБ. Тому для того, щоб етап пам'яті 1 мав сенс, необхідно досягти швидкості етапу 1 в межах обмеження пам'яті 2 ГБ.
етап пам'яті 2
під час використання менше ніж 200 МБ пам'яті досягти етапу швидкості 1 (що вдвічі перевищує етап пам'яті 1).
Чому потрібно зменшити до 200 МБ? Розгляньте сценарій, що не стосується блокчейну: коли ви відвідуєте веб-сайт по HTTPS, ви завантажуєте аутентифікаційні та шифрувальні сертифікати. Якщо веб-сайт перейде на відправлення цих сертифікатів у формі zk-довідок, великі веб-сайти можуть потребувати генерації мільйонів довідок за секунду. Якщо кожна довідка потребує 2 ГБ пам'яті, потреби у обчислювальних ресурсах досягнуть рівня PB, що очевидно неможливо. Таким чином, подальше зменшення використання пам'яті для додатків, що не стосуються блокчейну, є надзвичайно важливим.
Попередня компіляція: останній відрізок або киянка?
Попередня компіляція означає оптимізовану систему обмежень SNARK, спеціально призначену для певних функцій (наприклад, хешування, еліптичні криві підписи). У Ethereum попередня компіляція дозволяє знизити витрати на перевірку хешу Меркла та підпису, але надмірна залежність від попередньої компіляції не дозволяє справжньо підвищити основну ефективність SNARK.
Проблема попередньої компіляції
1.Надто повільний: Навіть з використанням підготовлених хешів та підписів, zkVM все ще має проблему низької ефективності основної системи доведення як на ланцюжку, так і поза ним.
2. Помилки безпеки: Якщо передкомпіляція рукопису не пройшла формалізовану перевірку, то майже неминуче виникнуть помилки, які можуть призвести до катастрофічних випадків невдачі у безпеці.
3. Поганий досвід розробника: Наразі багато zkVM потребує від розробників ручного написання систем обмежень, схоже на спосіб програмування 1960-х років, що серйозно впливає на досвід розробки.
4.Тестування в базовому варіанті може бути вводить у помилку: якщо тестування в базовому варіанті залежить від оптимізації певного попереднього компіляції, це може ввести в оману увагу людей, спрямовану на оптимізацію ручних обмежень системи, а не на покращення самого дизайну SNARK.
5. Витрати на введення/виведення та відсутність доступу до ОЗП Хоча попередня компіляція може покращити продуктивність важких задач з шифрування, вона може бути неефективною для більш різноманітних завдань, оскільки при передачі введення/виведення вона створює значні витрати, і не може використовувати ОЗП.
Навіть у середовищі блокчейну, якщо ви перевищили одиничну L1, таку як Ethereum (наприклад, ви хочете побудувати серію міжланцюжкових мостів), ви стикаєтеся з різними функціями хешування та схемами підпису. Щоб вирішити цю проблему, постійно виконується попереднє компілювання, що є некомплексним і приносить великий ризик безпеки.
Я справді вірю, що попередня компіляція залишається важливою з довгострокової точки зору, але лише після їх автоматичного синтезу та офіційної перевірки. Таким чином, ми можемо забезпечити перевагу розробників zkVM, уникнувши при цьому катастрофічних безпекових ризиків. Ця думка відображена в етапі 3.
Плановий графік
Я очікую, що деякі zkVM досягнуть етапу швидкості 1 та етапу пам'яті 1 до кінця цього року. Я вважаю, що протягом наступних двох років ми також зможемо досягти етапу швидкості 2, але наразі неясно, чи можливо це без нового напрямку досліджень.
Я передбачаю, що решта етапів (швидкість етап 3 та пам'ять етап 2) займе кілька років, щоб досягти.
Незважаючи на те, що у цій статті окремо вказано про безпеку та етапи продуктивності zkVM, ці два аспекти не є повністю незалежними. З виявленням уразливостей у zkVM я передбачую, що виправлення деяких з них неминуче призведе до значного погіршення продуктивності. Таким чином, результати тестів продуктивності zkVM до досягнення етапу безпеки 2 повинні розглядатися як тимчасові дані.
zkVM має великий потенціал у популяризації нульових доказів, але наразі він знаходиться на ранньому етапі - повний викликів у сфері безпеки та серйозних обмежень продуктивності. Ринкове хайповання та маркетингова пропаганда ускладнюють оцінку справжніх досягнень. Через чіткі відмінності у безпеці та продуктивності, я сподіваюся надати відверту дорожню карту, яка допоможе прояснити ситуацію. Ми обов'язково досягнемо цієї мети, але це займе час та постійні зусилля в галузі досліджень та інженерії.