Виступ Gavin Wood: стан впровадження JAM та середньо- і довгострокова стратегія інтеграції ZK у JAM!

Це український переклад виступу Gavin Wood на Web3 Summit минулого місяця! Оскільки матеріалу багато, ми поділимо його на чотири частини. Це — перша частина, основні теми якої включають:

• Стан впровадження JAM
• Продуктивність ZK покращилась, але ще далеко до комерціалізації
• 33-кратне повторне виконання vs математичний доказ: реальна ціна двох моделей безпеки
• Скільки коштує один ZK-JAM вузол? Відповідь дорожча у 10 разів, ніж ви думаєте!
• Коротко-, середньо- та довгострокова еволюція ZK у JAM

Давайте подивимось, які цікаві ідеї поділився Gavin!

Отже, без зайвих зволікань, про що я хочу розповісти у цій доповіді?

Спершу я хочу поділитися своїм загальним баченням Polkadot, тобто тим, на якому етапі роздумів я зараз перебуваю — це можна вважати “знімком поточного стану”. Можливо, ви вже чули про JAM — це проект, над яким я довго працюю, і який тісно пов’язаний із Polkadot. Ми сподіваємось, що він зрештою стане основою для наступного етапу розвитку Polkadot. Крім того, я поговорю про технології нульових знань (ZK), особливо про їх застосування для масштабування функціоналу блокчейну.

Також я торкнуся токеноміки DOT. Далі я розповім про деякі нові дослідження, якими я займався останнім часом, спрямовані на вдосконалення поточних можливостей і навіть відкриття нових перспектив для Polkadot і ширшого світу Web3. Ця частина буде різноплановою: деякі аспекти я розкрию докладно, інші — лише окреслю. Тож, починаємо.

Поточний стан впровадження JAM

Початкова версія JAM — це 0.1, і зараз ми поступово наближаємось до 1.0. Коли буде досягнуто 1.0, це означатиме, що протокол JAM готовий для оновлення Polkadot. У міру стабілізації протоколу наш фокус зміщується на оптимізацію, особливо на моделювання gas. Раніше цього року я виступав на Ethereum конференції у Празі (East Prague) саме з цієї теми. Моделювання gas — це дуже цікава, але водночас надзвичайно складна тема.

Очікується, що цього року JAM пройде аудит протоколу. У серії версій 0.7 залишилось небагато роботи; але у версії 0.8 буде офіційно впроваджено моделювання gas, і обсяг роботи суттєво зросте. Я очікую, що цього року ми зможемо перейти до версії 0.9 і тоді офіційно розпочати аудит.

Звісно, мати основний протокол — це одне, а мати можливість розробляти на ньому — зовсім інше. Потрібні SDK, документація та інші інструменти для розробників. Ця частина ще на ранній стадії. Хоча вже зараз можна розробляти ПЗ на JAM, у Parity я переважно сам просуваю створення та випуск SDK. Однак, на практиці це потребуватиме ще місяців або навіть років постійної роботи й вдосконалення. Звісно, розробка SDK не обмежиться лише Parity. Я очікую, що до цього долучаться й інші команди, створюючи власні JAM SDK.

Ми вже почали розробляти стандарт для міжсервісного обміну повідомленнями, який можна вважати JAM-версією XCM/XCMP. Тим часом CoreVM поступово стає частиною SDK і буде вдосконалюватися протягом наступних місяців. CoreVM вже підтримує багато функцій, наприклад, аудіовихід, відеовихід, введення/виведення даних, обробку транзакцій та майбутні внутрішні сервіси. Наразі він ще не підтримує EVM, але це заплановано. Також механізм, який я раніше називав coreplay (основне кооперативне планування), планується реалізувати протягом 12–24 місяців.

Нещодавно у чаті JAM хтось поставив цікаве питання: як уникнути того, щоб я сам став єдиною точкою відмови (single point of failure) для JAM? Наразі розвиток протоколу JAM повністю залежить від того, що я пишу у Gray Paper. Це означає, що якщо зі мною щось трапиться, весь проект може зупинитися. Очевидно, це погано і для JAM, і для мене особисто.

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

Отже, якщо у майбутньому оновлення Gray Paper вже не буде повністю залежати від мене, як це відбуватиметься?

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

З виходом JAM за межі версії 1.0 ця редакційна рада візьме на себе вищий рівень відповідальності:

• Не лише дрібні зміни, а й визначення напрямку розвитку JAM та пріоритетів;
• У разі розбіжностей саме колективна думка ради має бути вирішальною.

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

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

Щодо управління Polkadot — воно має повне право самостійно вирішувати, який протокол використовувати. Polkadot — це суверенний протокол, і механізм управління — прояв цієї суверенності. Наразі управління Polkadot чітко заявило: воно хоче використовувати JAM. Це добре. Водночас інші мережі також можуть обрати JAM, оскільки це відкритий протокол.

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

Поки сторони згодні, я очікую, що управління Polkadot братиме активну участь і підтримуватиме роботу редакційної ради Gray Paper. Якщо у майбутньому інші протоколи використовуватимуть JAM, я також сподіваюся, що вони братимуть участь у подібний спосіб.

Отже, це поточний стан JAM, або етап, якого він ось-ось досягне. Далі я хочу поговорити про нульові знання (ZK).

Продуктивність ZK покращилась, але ще далеко до комерціалізації

Багато хто запитує мене: коли ZK (докази з нульовим розголошенням) стануть справді комерційними?

Ethereum дуже захоплений ZK, їхня дорожня карта майже повністю побудована навколо ZK. У JAM ми використовуємо ZK лише у деяких спеціальних механізмах консенсусу під час побудови блоків, але загалом не залежимо від них. Проте навіть так це питання потребує серйозного аналізу:

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

Якщо подивитися на матеріали з екосистеми Ethereum (наприклад, ethprovers.com), можна побачити вражаючі цифри, які стверджують, що ZK вже економічно вигідна. Але ми перевірили — ці цифри не відповідають дійсності. Добра новина: хоча ще не повністю вигідно, але порівняно з 18 місяцями тому, розрив суттєво скоротився.

Наприклад: зараз віртуальна машина JAM — PVM (аналог EVM для JAM) виконує код повільніше за нативне виконання — приблизно на 34%. Тобто, якщо у нативному середовищі програма виконується за 34 хвилини, на PVM це займе близько 100 хвилин.

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

Звісно, у деяких випадках розрив більший — наприклад, 50% і більше. Особливо це стосується задач на кшталт SHA-1 хешування, де виконання на PVM повільніше. Можливо, це через те, що у нативному середовищі компілятор може використовувати SIMD-інструкції чи інші оптимізації, а PVM поки не може.

Далі розглянемо ще одну ключову цифру: це вартість генерації доказу виконання за допомогою найкращого на сьогодні доказувача — Succinct SP1, тобто додаткові витрати порівняно з прямим виконанням на PVM. Зверніть увагу, що порівняння йде саме з PVM, а не з нативним середовищем. PVM вже повільніше нативного приблизно на 34%.

Поточні результати такі: ми використали найновішу версію ПЗ і припустили використання лише однієї GPU (оскільки відкритий код підтримує лише одну GPU). У комерційній закритій версії, можливо, можна масштабувати на кластер GPU, але у відкритому середовищі — лише так. Тестували так само, як і раніше — SHA-1 хешування, для коректного порівняння.

У чому ж зміни?

18 місяців тому ми проводили подібний експеримент, і тоді цифри були значно більші — близько 60 мільйонів — 64 мільйонів. Зараз вартість суттєво знизилась.

Причини дві:

• З одного боку, оренда GPU подешевшала;
• З іншого — ПЗ суттєво оптимізували, можливо, на порядок і більше.

Додам, що 18 місяців тому ми використовували не SP1, а RISC-0. Але у будь-якому разі, це свідчить про стрімкий прогрес у передових технологіях.

Станом на липень 2025 року, генерація доказу виконання за допомогою SP1 (доказувача Succinct) у 306 451 разів дорожча, ніж безпечне виконання тієї ж операції безпосередньо у PVM. За останні 18 місяців вартість доказу знизилася приблизно у 200 разів, але це все ще дуже багато. ZK-технології справді швидко прогресують, але все ще значно дорожчі за пряме виконання.

Далі поговоримо про вимірювання Gas.

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

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

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

Яке рішення?

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

Якої точності ми досягли у такій оцінці?

На прикладі SHA-1: щоб гарантувати безпеку, ми маємо припускати, що він може бути у 4,5 рази повільніший за норму. Тобто, якщо код зазвичай виконується за 1 секунду, у найгіршому випадку ми маємо рахувати 4,5 секунди. Тільки так можна гарантувати, що навіть найзліший атакуючий не зробить його ще повільнішим.

Такий “мультиплікатор безпеки” — необхідна умова для безпеки у консенсусних механізмах із часовими обмеженнями.

У майбутньому цей коефіцієнт має зменшитися, тобто оцінки стануть точнішими й ефективнішими. Зараз 4,5 — це найкраще, чого ми досягли за тиждень-два роботи. Оптимістично — можливо, вдасться знизити до 3, але не набагато нижче.

33-кратне повторне виконання vs математичний доказ: реальна ціна двох моделей безпеки

У Polkadot і JAM ми використовуємо протокол під назвою elves для забезпечення коректності обчислень. Його завдання — гарантувати, що певний обчислювальний процес виконано правильно.

По суті, elves і докази з нульовим розголошенням (ZK) схожі:

• ZK — це математичний доказ, “залізний аргумент”;
• elves — це криптоекономічна гра: учасники використовують підписи й правила, щоб довести правильність результату, за умови, що “поганих” не більше третини.

Під час роботи elves обчислення повторюється. Учасники випадково вирішують, чи виконувати “повторне обчислення”.

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

Таким чином, можна порівняти вартість ZK і elves. Відповідь: ZK приблизно у 4000 разів дорожче за elves. Тобто, використання доказів з нульовим розголошенням для перевірки коректності набагато дорожче, ніж криптоекономічна система elves. Це можна порівняти із різними моделями Rollup.

PolkaWorld: Уявіть, що elves — це коли 33 учні переписують домашнє завдання і звіряють відповіді, щоб переконатися, що все правильно; ZK — це як запросити доктора математики написати “абсолютно безпомилковий доказ”, але на це йому потрібно кілька днів.

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

Але питання вартості — це не лише про “залізо”. Є ще кілька важливих моментів:

• Вартість адміністрування (sysadmin): незалежно від обладнання, зарплата адміністраторів приблизно однакова. І часто адміністрування навіть дорожче за “залізо”.
• Вартість стейкінгу: щоб “поганих” було не більше третини, потрібен механізм фільтрації. У Polkadot це “стейкінг + штрафи”. Тобто, учасники мають внести заставу (ризиковий капітал), щоб відрізнити “хороших” валідаторів від потенційно “поганих”.

Проблема у тому, що стейкінг — це теж дорого, це ще одна додаткова стаття витрат (про це далі).

Для порівняння, ZK не має тягаря стейкінгу. Логіка проста: або доказ правильний, або ні — це видно одразу.

Але проблема у тому, що генерація ZK-доказу занадто повільна. Якщо використовувати одну GPU, це може зайняти години; а на PVM (чи звичайному CPU) те саме обчислення виконується за мілісекунди чи секунди. Різниця величезна.

Втім, вже є приклади, коли за допомогою кластера GPU можна скоротити затримку. Якщо достатньо GPU з’єднати разом, затримка зменшиться. Але:

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

Крім того, є ще питання верифікації та фіналізації.

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

• верифікація (verification)
• фіналізація (settlement)
• остаточність (finality)
• зберігання (storage)

Ці етапи ZK не усуває. Тому зрештою все одно потрібно гарантувати, що “поганих” не більше третини, тобто знову повертаємось до стейкінгу — як у Ethereum L1, Polkadot та більшості ланцюгів.

Скільки коштує один ZK-JAM вузол? Відповідь дорожча у 10 разів, ніж ви думаєте!

Тепер подивимось з іншого боку: скільки коштує робота одного вузла-гаранта (guarantor node) у ZK-JAM?

Коротко поясню: у JAM є роль гаранта (guarantor) — це “охоронці” системи. Всі транзакції чи завдання спочатку надходять до них, вони виконують обчислення, пакують результат і передають іншим валідаторам. Валідатори можуть перевіряти їхню роботу, а можуть і ні.

Уявімо такий сценарій:

• відмовляємось від повторної перевірки (інші більше не перевіряють роботу гаранта);
• знижуємо вимоги до стейкінгу (бо не покладаємось повністю на довіру до гаранта);
• але змушуємо гаранта запускати кластер GPU і генерувати ZK-докази.

Яка вартість такого підходу?

За оцінками: генерація одного ZK-доказу коштує близько 1,18 долара (на прикладі SHA-1, що відповідає 6 секундам обчислень і 12 МБ I/O). Це приблизно обсяг роботи, який може виконати один JAM core за один slot. Усього у JAM 341 core, а це вартість одного core.

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

Якщо порахувати на рік: один core коштує близько 9,5 мільйонів доларів на рік.

Тут припускається, що паралелізація на кластері GPU дає 50% додаткових витрат, головно для зменшення затримки. Але ці 50% — лише припущення, на практиці це може бути 5% або навіть 200%. Однозначно — додаткові витрати будуть, і вони можуть бути суттєвими.

Як це співвідноситься з поточним механізмом стейкінгу Polkadot?

Зараз, щоб забезпечити безпеку на рівні elves (або близько 80% безпеки elves), вартість одного core — менше 1 мільйона доларів.

80% — тому що навіть із ZK все одно потрібен певний стейкінг для безпеки інших ключових частин, таких як:

• нормальна робота головного ланцюга
• фіналізація
• остаточність
• зберігання

Це все важливо, але коректність обчислень — найголовніше, і це близько 80% вартості стейкінгу.

Якщо ми маємо 341 core і зберігаємо поточну економічну модель стейкінгу Polkadot, вартість така. Якщо core буде менше, вартість одного core зросте, бо “загальний пул” стейкінгу не зміниться, а ділити його доведеться на менше число учасників.

Отже, підсумок: зараз вартість ZK приблизно у 10 разів більша за elves.

Звісно, якщо ми зможемо знизити вартість безпеки (я вважаю, це можливо), наприклад, з 9,16 мільйона доларів до 2,7 мільйона, або навіть, використовуючи нові механізми, до 1,44 мільйона. Тоді різниця між ZK і elves зменшиться. Але 1,44 мільйона — це вже оптимістична оцінка.

Який остаточний висновок?

Вартість ZK справді знижується, але навіть зараз вона у 10–100 разів вища за elves. І є ще додаткові невизначені витрати — фіналізація, зберігання, остаточність — усе це JAM вже підтримує “з коробки”, або elves може використовувати, а ZK — ні.

Крім того, у elves є перевага: він може масштабуватися надлінійно. Тобто, можна з’єднати кілька JAM-мереж і дати їм спільний набір валідаторів, підвищуючи загальну ефективність. А ZK так не може — він масштабується лише лінійно: для кожного нового core треба знову витрачати ті ж ресурси, не можна об’єднати чи повторно використати докази.

Коротко-, середньо- та довгострокова еволюція ZK у JAM

Отже, з точки зору стратегії, який шлях обрати — залежить від обставин.

Я вважаю, що розумна стратегія така:

• Знизити вартість доказу: потрібно ще зменшити її на 1–2 порядки. За досвідом, це може зайняти 18 місяців — 5 років.
• Потрібні open-source інструменти: для ефективної розподіленої генерації доказів на кластері GPU. Зараз таких інструментів немає, або вони не найкращі. Без них наші оцінки вартості не мають сенсу.
• Питання ціни core: якщо ринкова ціна core вже у зоні, де elves вигідний, то перевага ZK зникає.
• Вибір безпеки: ринок має розрізняти два типи безпеки: ZK — “ідеальна безпека”, elves — “економічно обмежена безпека”. Питання у тому, чи ринку це взагалі важливо — поки неясно.
• Відмова від великого стейкінгу: потрібно навчитися виконувати інші завдання JAM/elves (зберігання, фіналізація, остаточність) без великого стейкінгу. Якщо все одно потрібен масовий стейкінг — жодної переваги, лише додаткові витрати для ZK.

Виходячи з цього, моя пропозиція щодо ZK-стратегії:

• Почати з простого: створити фреймворк ZK-JAM, але поки що використовувати поточний криптоекономічний механізм JAM (elves) для безпеки.
• Використати переваги JAM: один JAM core має потужний CPU і непоганий I/O (12 МБ), а PVM дуже ефективний. Тобто, можна прямо у JAM core виконувати багато ZK-верифікацій, не вдаючись до зовнішніх дорогих і складних процедур.
• Оптимізувати доказову частину: традиційно ZK-доказ складається з кількох етапів, останній — “стиснення доказу” для зменшення розміру і спрощення верифікації. Але у JAM core, завдяки потужності, ця стадія може бути непотрібною, що економить ресурси.
• Пріоритет — докази зберігання: JAM core має сильні обчислення, але I/O слабший, а докази зберігання можуть компенсувати цей недолік і дозволити швидко обробляти багато транзакцій.
• Інші прості завдання: наприклад, перевірка підписів — це не вузьке місце.

Інакше кажучи, справжня складність — гарантувати, що дані, на які спираються транзакції, коректні. Це і є головна задача.

У середньостроковій перспективі розумний підхід такий:

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

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

Особливо важливо зосередитись на доказах виконання PVM, бо це ключ до сумісності ZK-JAM із звичайним JAM у майбутньому, а також розподілена генерація доказів — обов’язкова.

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

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

Як реалізувати JAM, повністю заснований на ZK?

По-перше, це має сенс лише тоді, коли вартість ZK достатньо знизиться, і буде зрозуміло, що використання core у поточній моделі економічно недоцільне. Зараз це ще не ясно, тому це умовне припущення.

Якщо умови виконано, JAM можна перетворити на багатомодельну систему безпеки:

• З одного боку — дешева, але обмежена безпека (як у elves);
• З іншого — дорога, але ідеальна безпека (на основі ZK, із лінійним зростанням витрат).

Ключове питання: потрібно знайти спосіб забезпечити фіналізацію (finality) і зберігання (storage) без стейкінгу.

Один із можливих напрямків — доказ особистості (Proof of Personhood). Якщо інтегрувати цей механізм у протокол, можна суттєво підвищити ефективність і використання капіталу.

Але для цього потрібен дуже потужний механізм захисту від Sybil-атак (anti-sybil mechanism). Зараз більшість рішень недостатньо сильні: або залежать від якогось авторитетного органу, або якась організація збирає дані користувачів, щоб вирішити, хто справжній, а хто ні. Це явно централізовано, і лише дуже небагато рішень близькі до реальної реалізації.