A16z: Ключові елементи для творців: «Jolt Inside»

Автор статті: a16z crypto

Переклад статті: Block unicorn

Передмова

Сьогодні LayerZero випустила свою нову ланцюг Zero, яка містить кілька технологічних проривів — зокрема новий метод доведення з нульовим розкриттям, що роз’єднує виконання транзакцій і їх верифікацію. Усе це стало можливим завдяки “Jolt Inside”.

Що таке Jolt? Jolt — це відкритий RISC-V zkVM (знеколізовані віртуальні машини, або точніше, “лаконічна” віртуальна машина), яка швидка, безпечна і легка у використанні. Вона представляє новий, передовий підхід до дизайну SNARK, розроблений протягом трьох років командою a16z crypto, і буде відкрито доступна для всіх для використання або подальшої розробки. Але створення Jolt — це історія, яка формувалася десятиліттями.

Чому дизайн zkVM і SNARK так важливі?

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

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

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

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

Коротко кажучи, zkVM — це спосіб довести, що ви правильно виконали обчислювальну програму. Перевага zkVM у тому, що він дружній до розробників. Використовуючи існуючу обчислювальну інфраструктуру (наприклад, відкриту екосистему компіляторів LLVM), розробники можуть застосовувати потужність SNARK у своїх програмах без необхідності в спеціалізованих мовах програмування (DSL).

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

Розробники можуть зосередитися на практичних задачах. За допомогою Jolt їм не потрібно мати спеціальні знання про SNARK — достатньо натиснути кнопку, і вони зможуть згенерувати доказ для свого коду.

Навіть попри значний прогрес, доведення будь-яких доказів середньої складності (наприклад, операцій, виконаних за секунду на одному стандартному процесорі) все ще вимагає потужних обчислень. Щоб швидко генерувати складні докази, потрібні кілька GPU. LayerZero портирує Jolt на CUDA і запускає Zero — це поєднання високого рівня паралелізму алгоритмів Jolt із паралельною апаратною підтримкою GPU, що забезпечує масштабованість.

LayerZero прагне вивести Jolt на рівень виробничих GPU-доказів, включаючи співпрацю з нами над розробкою GPU-дружньої версії алгоритму Jolt, що є критично важливим для підвищення масштабованості zkVM і доказів.

Відкриті дослідження і розробки

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

Інвестиції венчурних фондів у відкриті проекти можуть здатися незвичними, але сучасна структура R&D передбачає, що більша частина роботи виконується або в компаніях (наприклад, колишні корпоративні лабораторії або сучасні фонди), або в академічних колах. Мета створення a16z crypto — побудувати дослідницьку лабораторію і команду інженерів, що поєднують академічну теорію і промислову практику. Як венчурний фонд, ми можемо фінансувати проекти, які інші не можуть — особливо у випадках зворотних інвестицій.

Підтримка зворотного проектування SNARK особливо важлива для Jolt, оскільки вона означає кардинальний “парадигмальний зсув” у порівнянні з попередніми підходами. Ця еволюція дизайну триває вже багато років.

Історія інновацій — це історія змін архітектурних підходів

Щоб зрозуміти кардинальні зміни у підходах до дизайну SNARK, потрібно повернутися більш ніж на дві тисячі років назад: греки започаткували розвиток формалізованих систем математичних доведень, які згодом розвивали в Близькому Сході, Азії та інших регіонах.

Ці ранні доведення — логічні висновки, записані у формальній мові або формулі — дозволяли будь-кому їх перевірити. Наприклад, математик міг записати доведення у вигляді “книги”, а інший — прочитати її по рядках, щоб переконатися у правильності. Ця статична концепція доведення — ідея “P проти NP” у складності.

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

Але у 1985 році* Шафі Гольдвасер, Сільвіо Мікалі і Чарльз Ракофф запропонували концепцію інтерактивних доведень (“IP”). [* Насправді їхній документ був написаний раніше, але був кілька разів відхилений і прийнятий пізніше.] Основна ідея — під час обміну між доведувачем і перевіряючим вони не повинні чекати, поки один напише доведення, а інший його перевірить. Навпаки, вони можуть задавати питання у реальному часі; тобто — через інтерактивність — досліджувати істинність доведення.

Ця потужність — порівняно з традиційними статичними доведеннями — була повністю оцінена лише через п’ять років, у 1990-му. Тоді Карстен Лунд, Ланс Фортноу, Говард Карлофф і Ноам Нісан запропонували алгебраїчний протокол для перевірки сум. У поєднанні з подальшою роботою Аді Шаміра це швидко привело до фундаментального висновку “IP=PSPACE” — технічного визначення, яке узагальнює таку ідею:

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

Інакше кажучи: інтерактивність дає нам значні переваги у системах доведень. А концепція суми — sum-check — є ключовою для перетворення цієї переваги у ефективну перевірку: вона дозволяє перевірячу підтверджувати результати без необхідності відтворювати весь обчислювальний процес.

Через кілька років Джо Кіліан запропонував побудувати короткі знеколізовані доведення (PCP), базуючись на концепції доведень з високою надмірністю. У теорії PCP доведення — це “книга”, яку може записати доведувач (можна уявити грецького математика), але вона містить багато зайвого. Це дозволяє перевірячу, не читати всю книгу, а випадковим чином вибрати кілька позицій — наприклад, три слова — і з високою ймовірністю переконатися у правильності доведення.

Але проблема — доведення PCP дуже довге, хоча перевірка — швидка.

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

Спочатку ці доведення були інтерактивними. Потім Мікалі показав, як застосувати трансформацію Fiat-Shamir, щоб перетворити інтерактивний протокол Кіліана у неінтерактивний. За допомогою цієї трансформації виклики — випадкові питання — генеруються доведувачем самостійно, і весь доказ можна вивести одразу.

Залишковий вплив архітектури

Якщо подивитися на історію систем доведень, то можна побачити перехід від статичних до інтерактивних, потім — до ймовірнісних і неінтерактивних (PCP), потім знову — до інтерактивних (Кіліан), і знову — до неінтерактивних (Мікалі). SNARK — це результат цієї еволюції: застосування трансформації Fiat-Shamir до інтерактивних доведень Кіліана дало перший SNARK.

Але у цих ранніх SNARK на основі PCP робота доведувача була дуже важкою — довгий час обчислювально — що ускладнювало їх практичне застосування.

Однак спосіб проектування SNARK залишався майже незмінним десятиліттями. Навіть коли галузь намагалася відійти від концепції PCP, дизайнери все одно використовували схожі ідеї (наприклад, “лінійний PCP”), які фактично були варіаціями від концепцій PCP. Хоча ці підходи і давали короткі докази, вони не забезпечували найшвидшого доведення.

Дизайнери SNARK так і не повернулися до коренів — протоколів суми — щоб отримати ще швидші і зручніші доведення за допомогою сучасних обчислень.

Якщо ж раніше використовувати протоколи суми, потрібно було б переглянути історію SNARK у більш нелінійному світлі. З (a) інтерактивних доведень → (b) PCP → © лаконічних інтерактивних доведень → (d) ранніх SNARK — галузь пройшла через такі перетворення:

У переході від (a) до (b) — інтерактивних доведень до PCP — головне завдання полягало у збереженні лаконічності перевірки і одночасному усуненні взаємодії. Це змусило відмовитися від протоколів суми (інтерактивних частин).

Але при переході від (b) до © — від PCP до лаконічних знеколізованих доведень — інтерактивність знову з’явилася… і потім, за допомогою Fiat-Shamir, її знову усунули, що привело до (d) — ранніх SNARK.

Якщо подивитися на всі ці кроки послідовно, то стає зрозуміло, що дизайн SNARK двічі пропускав етапи взаємодії — один раз при переході від (a) до (b), і вдруге — від © до (d).

Але якщо ми хочемо використовувати Fiat-Shamir для усунення взаємодії, то логічно пропустити проміжний крок (b) — протоколи PCP! Це і є ключова ідея Jolt: безпосередньо з інтерактивних доведень побудувати SNARK — ідучи прямо до протоколів суми.

Чому ж раніше ніхто не застосовував цю ідею? Можливо, через те, що дизайнери SNARK вважали PCP і SNARK схожими, оскільки обидва забезпечують лаконічність. Або через архітектурні та ідеологічні помилки, що зберігалися роками.

Для нас інвестування ресурсів у розробку zkVM Jolt на основі протоколів суми — це зворотна ставка, яка йде проти домінуючої парадигми SNARK.

‘Jolt Inside’

Метод SNARK у Jolt (заснований на пакетних обчисленнях і механізмах перевірки пам’яті, таких як Twist + Shout) базується на інтерактивних доведеннях і протоколах суми.

Зараз, через кілька років після початку роботи над Jolt, інші теж починають застосовувати протоколи суми у своїх рішеннях. Тож, які особливості має Jolt у сучасних zkVM? Jolt максимально використовує повторювану структуру виконання CPU. Спостерігаючи за тим, як “зчитування-декодування-виконання” кожного ядра застосовне до механізмів пакетних обчислень, Jolt досягає неймовірної ефективності з мінімальним ускладненням.

На відміну від інших zkVM, які сильно залежать від “передкомпільованих” рішень (подібних до ASIC-ускорювачів для конкретних підпрограм), Jolt відмовляється від таких підходів, оскільки вони повторюють помилки передSNARK-архітектурою: залучення експертів для створення спеціалізованих SNARK ускладнює їхнє використання і підвищує ймовірність помилок. Головна мета Jolt — зробити SNARK доступними для широкого кола розробників.

Перевірка правильності роботи CPU — це основна цінність zkVM і значний прорив для досвіду розробників, оскільки вона дозволяє повторно використовувати існуючу, вже оптимізовану обчислювальну інфраструктуру. Світова обчислювальна інфраструктура побудована навколо CPU, і Jolt максимально використовує цю “структуру” для підвищення лаконічності і продуктивності.

З самого початку Jolt орієнтована на зручність і продуктивність: розробники можуть безпосередньо перевіряти існуючі програми; навіть для швидкої перевірки не потрібно змінювати код. Jolt не змушує команди переписувати програми під “передкомпільовані” або спеціальні API — зберігаючи цілісність оригінального коду, що полегшує його використання, аудит і зменшує витрати на ітерації.

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

Що далі з Jolt?

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

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

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

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