Выступление Gavin Wood: статус реализации JAM и средне- и долгосрочная стратегия внедрения ZK в JAM!

Это русская версия выступления Gavin Wood на Web3 Summit в прошлом месяце! Поскольку этот цикл довольно объемный, мы опубликуем его в четырех частях. Это первая часть, основные темы которой включают:

• Статус реализации JAM
• Несмотря на прогресс, производительность ZK все еще далека от коммерческого применения
• 33-кратное повторное вычисление против математического доказательства: реальная цена двух моделей безопасности
• Сколько стоит один ZK-JAM-узел? Ответ — в 10 раз дороже, чем вы думаете!
• Краткосрочная, среднесрочная и долгосрочная эволюция ZK в JAM

Давайте посмотрим, какими интересными мыслями поделился Gavin!

Итак, не будем откладывать, о чем я собираюсь рассказать в этом выступлении?

Прежде всего, я хочу поделиться своим общим взглядом на Polkadot, то есть своим текущим положением в размышлениях — это можно рассматривать как "снимок текущего состояния". Возможно, вы уже слышали о JAM — это мой долгосрочный исследовательский проект, тесно связанный с Polkadot. Мы надеемся, что он в конечном итоге поддержит следующий этап развития Polkadot. Кроме того, я расскажу о технологиях нулевого знания (ZK), особенно об их применении для расширения функциональности блокчейна.

Также я затрону токеномику DOT. Далее я представлю некоторые новые исследования, которыми я занимался в последнее время, направленные на улучшение существующих возможностей и даже на открытие новых возможностей для Polkadot и более широкой Web3-экосистемы. Эта часть будет разной степени детализации. Хорошо, теперь начнем официально.

Текущий статус реализации JAM

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

Ожидается, что в этом году JAM пройдет аудит протокола. В серии версий 0.7 осталось немного работы; но в версии 0.8 будет официально введено моделирование газа, и объем работы значительно увеличится. Я ожидаю, что мы сможем продвинуться до версии 0.9 в этом году и тогда официально начать аудит.

Конечно, наличие основного протокола — это одно, а возможность разработки на его основе — совсем другое. Вам нужны SDK, документация и другие инструменты для разработчиков. Эта часть пока находится на ранней стадии. Хотя уже можно разрабатывать ПО на JAM, в Parity в основном я сам продвигаю создание и выпуск SDK. Однако на практике это потребует еще месяцев и даже лет постоянных усилий и доработок. Конечно, разработка SDK не будет ограничена Parity. Я также ожидаю, что больше команд присоединится и создаст свои собственные JAM SDK.

Мы уже начали разрабатывать стандарт межсервисного обмена сообщениями, который можно рассматривать как версию XCM/XCMP для JAM. Тем временем 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, но в open-source — только так. Тест был тот же, что и раньше — SHA-1 хэширование, для сопоставимости.

В чем разница?

18 месяцев назад мы проводили похожий эксперимент, тогда значения были гораздо больше — порядка 60 миллионов — 64 миллионов. Сейчас стоимость значительно снизилась.

Причины примерно две:

• Во-первых, аренда GPU стала дешевле;
• Во-вторых, само ПО значительно оптимизировано, возможно, на порядок и более.

Стоит добавить, что 18 месяцев назад мы использовали не SP1, а RISC-0. Но в любом случае результат один: передовые технологии быстро развиваются, и прогресс значителен.

По состоянию на июль 2025 года, генерация доказательства выполнения (execution trace) с помощью SP1 (доказатель Succinct) дороже, чем безопасное выполнение той же задачи на PVM, в 306 451 раз. За последние 18 месяцев стоимость доказательства снизилась примерно в 200 раз, но это все еще очень большая величина. Технология ZK действительно быстро развивается, но она все еще намного дороже прямого исполнения.

Теперь поговорим о газовом учете.

Быстрое выполнение кода — это одно, но главное — можно ли ему доверять. Что если кто-то намеренно напишет "замедляющий" код? В механизмах консенсуса, если система должна достичь согласия за определенное время, а код специально замедлен, вся система может быть заблокирована или даже парализована.

В Polkadot эта проблема не так остра, потому что у нас есть аукционы парачейновых слотов. То есть, кто может загружать код в систему, в основном известен — они заплатили реальные деньги за слот, поэтому вряд ли будут заниматься вредительством себе в ущерб.

Но если рассматривать более открытую и универсальную среду, проблема становится серьезной.

Какое решение?

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

Каковы наши успехи в оценке худшего случая?

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

Такой "многократный запас" — необходимый способ обеспечения безопасности в консенсусных механизмах с временными ограничениями.

В будущем этот коэффициент должен снизиться, то есть оценка станет точнее и эффективнее. Сейчас 4,5 — это лучший результат после одной-двух недель работы. Оптимистично, возможно, удастся снизить до 3, но не намного ниже.

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

В Polkadot и JAM мы используем протокол под названием elves для обеспечения безопасности вычислений. Его задача — убедиться, что определенное вычисление действительно выполнено правильно.

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

• ZK использует математическое доказательство, давая "железное" подтверждение;
• elves — это скорее криптоэкономическая игра: участники с помощью подписей и правил доказывают правильность результата, при условии, что "плохих" не больше трети.

При работе elves вычисления повторяются. Участники случайным образом решают, будут ли они делать это "повторное вычисление".

В итоге, в этом режиме работа в среднем повторяется примерно 33 раза. То есть стоимость примерно в 33 раза выше обычного исполнения.

Таким образом, можно сравнить стоимость ZK и elves. Ответ: ZK примерно в 4000 раз дороже elves. Иными словами, проверка корректности с помощью ZK стоит гораздо дороже, чем с помощью криптоэкономической системы elves. Это можно сравнить с разницей в стоимости различных Rollup-решений.

Примечание PolkaWorld: можно представить, что elves — это как если бы 33 одноклассника переписывали домашнее задание и сверяли ответы, чтобы убедиться в отсутствии ошибок; а ZK — это как если бы вы наняли доктора математики, чтобы он написал "абсолютно безошибочное доказательство", но на это у него уйдет несколько дней.

Разрыв в 4000 раз — это очень много, чтобы сделать ZK экономически выгодным для практического применения, его стоимость должна значительно снизиться. Конечно, мы также можем оптимизировать elves, чтобы сделать его еще эффективнее.

Однако проблема стоимости — это не только оборудование. Есть еще несколько ключевых моментов:

• Операционные расходы (sysadmin): независимо от оборудования, зарплата администраторов примерно одинакова. А в ряде случаев операционные расходы даже выше стоимости оборудования.
• Стоимость стейкинга: чтобы гарантировать, что "плохих" не больше трети, системе нужен фильтр. В Polkadot это реализовано через "стейкинг + механизм наказаний". То есть участники должны заложить часть средств (рисковый капитал), чтобы отделить "хороших валидаторов" от потенциальных "плохих".

Проблема в том, что сам стейкинг тоже дорог, это еще одна статья расходов (я расскажу подробнее чуть позже).

В отличие от этого, ZK не требует стейкинга. Логика 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 раз дороже, чем вы думаете!

Теперь посмотрим с другой стороны: предположим, есть гарантирующий узел ZK-JAM (guarantor node), какова его стоимость?

Кратко поясню: в JAM есть роль гарантора (guarantor), они как "сторожи" системы. Все транзакции или задачи сначала поступают к ним, они выполняют вычисления, упаковывают результат и передают другим валидаторам. Валидаторы могут перепроверять их работу, а могут и нет.

Теперь предположим:

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

Какова стоимость?

По оценкам: генерация одного ZK-доказательства стоит примерно 1,18 доллара (на примере SHA-1, что эквивалентно 6 секундам вычислений и 12 МБ I/O). Это примерно объем работы, который может выполнить один JAM core за один слот. Всего в 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 тоже высока. Это значит, что мы можем выполнять много ZK-верификаций прямо внутри JAM core, не прибегая к дорогим и сложным внешним доказательствам.
• Оптимизировать этап доказательства: обычно процесс ZK-доказательства состоит из нескольких этапов, последний — "сжатие доказательства" для уменьшения размера и удобства верификации. Но внутри JAM core, благодаря высокой вычислительной мощности, этот этап может быть не нужен, что экономит расходы.
• В первую очередь заняться доказательствами хранения: поскольку JAM core очень мощный в вычислениях, но ограничен по I/O, а доказательства хранения могут компенсировать этот недостаток и ускорить обработку большого числа транзакций.
• Другие простые задачи: например, верификация подписей и так легко решается, это не узкое место.

Другими словами, настоящая сложность — в обеспечении корректности данных, от которых зависят транзакции. Это и есть наша главная задача.

В среднесрочной перспективе разумно поступить так:

У нас уже есть новое видение Kusama — создание сети с поддержкой ZK. Поэтому использовать этот бюджет и сотрудничать с другими командами, чтобы сосредоточиться на эффективных, распределенных инструментах генерации доказательств — очень уместно.

• Если сейчас никто этим не занимается — запустить новый проект;
• Если уже есть команда или кто-то готов переключиться — сотрудничать и поддерживать их.

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

Цель — сохранить модульность и открытость системы, чтобы идти в ногу с передовыми исследованиями. Только так мы сможем снизить стоимость доказательств еще на несколько порядков и сделать их действительно коммерчески жизнеспособными.

В долгосрочной перспективе, если мы действительно хотим, чтобы ZK стал основным решением, нужно найти способ заменить стейкинг. Пока есть стейкинг — расходы очень высоки.

Как реализовать полностью ZK-ориентированный JAM?

Во-первых, это имеет смысл только если стоимость ZK достаточно снизится, и будет ясно, что использование core в текущем режиме экономически невыгодно. Сейчас это неясно, так что это условное предположение.

Когда условия будут выполнены, можно эволюционировать JAM в многомодельную систему безопасности:

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

Ключевая задача — найти способ реализовать финальность (finality) и хранение (storage) без стейкинга.

Один из возможных путей — Proof of Personhood (доказательство личности). Если интегрировать этот механизм в основной протокол, можно значительно повысить эффективность и использование средств.

Однако для этого нужна очень мощная анти-сибилловая защита (anti-sybil mechanism). Сейчас большинство решений недостаточно сильны: либо зависят от какого-то авторитета, либо организация собирает пользовательские данные для определения, кто реальный человек, а кто нет. Такой подход явно централизован, и только очень немногие решения близки к реализуемым.