JAM будет доставлен в течение 12-20 месяцев? Три ключевых разработчика раскрывают детали экономической модели M1, PoP и будущее ZK!

JAM — это имя, которое уже давно обсуждается в сообществе Polkadot. После того как Gavin Wood на Web3 Summit сделал ряд громких заявлений, ожидания и вопросы по поводу JAM достигли нового максимума — что же такое JAM на самом деле? Какие изменения он принесет Polkadot? Как далеко до его официального запуска?

Чтобы дать сообществу более полное понимание, PolkaWorld пригласил трех гостей, непосредственно участвующих в разработке ядра JAM — Bryan из команды Acala, разработчика реализации JAM на Rust под названием “FastRoll” Junha, а также разработчика реализации JAM на Zig “JAMZig” и сооснователя проекта Polona Boy Maas.

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

В этом интервью они из первых уст расскажут нам о мире JAM:

• Что на самом деле означают крупные обновления JAM, объявленные Gavin?
• Как лимит токенов JAM (π × 1,000,000,000) и механизм PoP (Proof of Personhood) изменят экономическую модель Polkadot?
• Каковы технические цели и прогресс Milestone 1? Когда будет запущена тестовая сеть?
• Как в будущем ZK (Zero-Knowledge Proofs) будет интегрироваться с JAM?
• Как механизм управления JAM и редакционный комитет Gray Paper повлияют на долгосрочную эволюцию протокола?

Если вы хотите узнать о будущем JAM и о том, как он изменит инфраструктуру экосистемы Polkadot — этот выпуск нельзя пропустить.

Знакомство с тремя командами разработчиков JAM

Kristen: Всем привет, я Kristen. Сегодня у нас в гостях три ключевых разработчика JAM, которые непосредственно участвуют в его создании. Если вы следите за PolkaWorld или последними новостями Polkadot, то знаете, что сейчас проходит Web3 Summit, и Gavin на конференции сделал несколько важных анонсов о JAM. Сообщество уже активно задает нам вопросы, поэтому мы спонтанно организовали этот эфир, чтобы с помощью наших гостей помочь всем лучше понять, что именно объявил Gavin о JAM на Web3 Summit.

В первой части я хочу попросить гостей по очереди кратко представиться, рассказать, за что вы отвечаете в проекте JAM и каков текущий прогресс разработки. Хотя некоторые из вас уже бывали у нас в эфире, у нас всегда появляются новые зрители, так что прошу вас еще раз представиться. Начнем с Junha.

Junha: Спасибо за приглашение, Kristen. Всем привет, я Junha, впервые участвую в этой программе.

Сейчас я разрабатываю реализацию протокола JAM на языке Rust, проект называется “FastRoll”. В моей команде пока только я один, так что я независимый разработчик.

Я занимаюсь этим проектом около года, сейчас готовлюсь к ревью первого этапа (milestone), а также уже начал работу над некоторыми задачами второго этапа.

Kristen: Добро пожаловать, Junha! Теперь попрошу Bryan представиться.

Bryan: Всем привет, я Bryan из команды Acala. Сейчас я руковожу небольшой командой, которая разрабатывает другую реализацию протокола JAM, проект называется “Boka”.

• Мы также завершаем первый этап и параллельно обновляем некоторые off-chain компоненты, чтобы подготовиться ко второму этапу.
• Кроме того, мы только начали разработку перекомпилятора PVM, но пока это на ранней стадии, до завершения еще далеко.

Kristen: Спасибо, Bryan, что снова пришел к нам. Bryan, кстати, был первым гостем, который рассказывал о проекте JAM. Очень рада, что ты снова с нами. И наконец, приветствуем Boy Maas, с которым мы уже делали отдельное интервью.

Boy Maas: Да, да, всем привет, я Boy Maas. Я независимый разработчик реализации протокола JAM на языке Zig, наш клиент называется “JAMZig”.

Также я сооснователь проекта в экосистеме JAM, наша цель — полностью перенести инструментарий Solana и виртуальную машину Solana (SVM) на JAM. Сейчас мы завершили этап proof-of-concept, то есть уже можем запускать некоторые базовые функции.

JAM будет официально запущен через 12–20 месяцев?

Kristen: Добро пожаловать, Boy Maas. Polona действительно пионерский проект, который стремится привлечь разработчиков Solana в экосистему Polkadot — отличная идея! Спасибо всем гостям за участие.

Первый вопрос я хочу задать Boy Maas. Ты участвовал в Web3 Summit, мы уже видели много новостей о выступлении Gavin в Twitter, но хотелось бы услышать твои личные впечатления. Ты смотрел выступление Gavin? Можешь поделиться, что тебе показалось самым важным?

Boy Maas: Конечно, быть на месте — это потрясающе. Можно встретить многих членов сообщества Polkadot, услышать много интересных докладов, почувствовать динамику и энергетику сообщества, что очень вдохновляет и дает надежду на будущее. Сегодня последний день, и я с нетерпением жду, чтобы вернуться и продолжить нашу разработку.

Kristen: Ты смотрел выступление Gavin?

Boy Maas: Да, смотрел.

Kristen: Есть ли что-то, что тебе особенно запомнилось? Мы видели текстовые выдержки в Twitter, но хочется услышать твое мнение как разработчика, чтобы ты объяснил это более простым языком.

Boy Maas: Конечно. Gavin затронул много тем. Он очень дальновидный человек с огромным опытом, поэтому его решения и новые идеи сильно влияют на будущее сообщества.

Самое важное — он объявил, что общий объем эмиссии токенов JAM будет жестко ограничен “π умножить на 1,000,000,000” (π × 1,000,000,000). Это очень значимое событие, которое повлечет за собой множество последствий.

Еще один важный момент — он попытался более четко донести до сообщества Polkadot, что такое JAM. По сути, JAM создан для усиления и поддержки экосистемы Polkadot, его задача — продвигать инфраструктуру всей экосистемы. Сейчас все находятся в стадии изучения и адаптации: что такое JAM? Что он может? Как он взаимодействует с основной сетью Polkadot? Как он реализуется?

Как разработчики, мы понимаем технические детали JAM, но для большинства людей пока неясно, какие изменения принесет JAM. Все пытаются представить, каким будет будущее, управляемое JAM.

Kristen: Звучит очень интересно. Я еще заметила, что Gavin упомянул, что JAM будет официально запущен через 12–20 месяцев. Ваш проект Polona, вероятно, тоже зависит от этого графика? Ваши сроки разработки синхронизированы с JAM?

Boy Maas: Да, Kristen, ты абсолютно права. Мы не ставили целью быть полностью готовыми к запуску тестовой сети, но, судя по объявленному графику, наши планы идеально совпадают — как только тестовая сеть JAM будет запущена, мы сможем сразу начать использовать ее. Когда сеть заработает официально, мы тоже сразу подключимся.

Что такое M1 в JAM?

Kristen: Отлично, приятно слышать о таком прогрессе. Теперь вопрос к Junha.

Недавно JAM выпустил важное техническое обновление и четко определил цели первого этапа (milestone 1). Но некоторые слушатели не до конца понимают, что такое milestone 1, что в него входит и на каком он этапе. Можешь рассказать, что включает milestone 1? Как идет работа над тестовой сетью? Когда, по твоим ожиданиям, она будет запущена?

Junha: Конечно. Как ты отметила, “Gray Paper” JAM недавно обновился до версии 0.7.0. Gavin в своем выступлении также сказал, что с этой версии Polkadot Fellowship может начать оценку milestone 1. Поэтому сейчас большинство команд, работающих над реализацией JAM-нод, готовятся к этой оценке.

Цель milestone 1 — предоставить клиент-ноду, способную “корректно импортировать блоки”, то есть проверить базовую логику выполнения JAM.

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

Оценка milestone 1 — это проверка, может ли твоя реализация ноды после импорта этих блоков сформировать корректное следующее состояние.

Методика оценки проста: мы готовим набор тестовых блоков и сравниваем, совпадают ли состояния, полученные разными реализациями. Это состояние можно выразить через “vertical root”, так что сравнивать очень удобно. Уже есть инструмент JAM Conformance Fuzzer, который автоматически генерирует множество блоков со случайными данными и тестирует, могут ли разные реализации получить одинаковый state root.

Я считаю, что это отличная возможность выявить и исправить критические баги, чтобы заложить фундамент для более сложных этапов.

Kristen: Поняла, а когда ожидается запуск тестовой сети?

Junha: Ты имеешь в виду тестовую сеть JAM? Сейчас некоторые команды уже пробуют кросс-реализацию с помощью собственных бинарников, но, на мой взгляд, по-настоящему работоспособная тестовая сеть появится только после milestone 2.

Потому что milestone 1 в основном проверяет логику преобразования состояния ноды, а этого недостаточно для полноценной работы тестовой сети. Только milestone 2 начнет оценку реализации сетевого протокола (networking spec) во всех клиентах. Но сейчас этот протокол еще нестабилен, даже не прописан в Gray Paper. Как только спецификация стабилизируется и реализации будут готовы, можно будет тестировать взаимодействие между нодами.

Тогда уже можно будет серьезно готовиться к запуску тестовой сети. Конечно, некоторые команды могут попробовать раньше, но я лично планирую подключаться к тестовой сети только после milestone 2.

Kristen: Хорошо. А как ты думаешь, повлияют ли новые анонсы Gavin на твои сроки разработки?

Junha: Думаю, большинство его заявлений касаются долгосрочного видения, поэтому в краткосрочной перспективе на мой план они не повлияют. Сейчас я сосредоточен на завершении milestone 1, думаю, потребуется еще несколько недель или месяц, чтобы полностью соответствовать требованиям. Так что моя стратегия пока не меняется.

Конечно, на горизонте 1–3 лет новые направления могут повлиять, но сейчас я сфокусирован на milestone 1.

Что изменится, если PoP заменит NPoS?

Kristen: Поняла, спасибо за рассказ! Теперь “хардкорный” вопрос для Bryan — о токеномике. Мы знаем, что разработчики обычно не любят оценивать экономические модели, но это один из самых волнующих вопросов для сообщества. Gavin на саммите объявил, что PoP (Proof of Personhood) заменит NPoS, вознаграждение валидаторов станет фиксированным, а общий объем DOT будет ограничен механизмом ежегодного халвинга. Как ты, как разработчик, относишься к этим изменениям? Что считаешь самым важным? Ты поддерживаешь эти изменения? Есть ли опасения или предложения?

Bryan: Действительно, это большое изменение.

Сначала кратко о бэкграунде: будь то Proof of Work (PoW), Proof of Stake (PoS) или теперь предложенный Proof of Personhood (PoP) — все эти механизмы нужны для обеспечения безопасности сети, предотвращения double-spend, форков и других атак.

У каждого механизма есть свои издержки: у PoW — это награды за блоки, плюс огромные затраты на электричество и вычисления, у PoS — это вознаграждения стейкерам.

Новый PoP сильно отличается по механике наград. Polkadot раньше использовал NPoS (Nominated Proof of Stake), который, хотя и дешевле PoW, все равно требует постоянной эмиссии новых токенов для вознаграждения валидаторов и номинаторов, что приводит к инфляции.

Введение PoP направлено на снижение издержек безопасности сети, чтобы не полагаться на экономические стимулы или штрафы, а перейти к новому способу — как именно, пока неясно, но суть в “один человек — один голос”. Если это сработает, мошенничать станет намного сложнее, сеть будет проще защищать, и не придется платить столько токенов в виде наград.

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

Есть и потенциальный плюс: это может простимулировать развитие DeFi. Когда доходы от стейкинга падают, пользователи могут переводить средства в другие DeFi-протоколы — кредитование, ликвидность и т.д., что оживит DeFi-экосистему.

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

Kristen: Думаю, в краткосрочной перспективе для валидаторов это может быть ударом, ведь их доходы могут сильно упасть. Как думаешь, это вызовет проблемы на старте?

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

Ведь важно сохранить безопасность сети, чтобы валидаторы хотя бы покрывали издержки и получали прибыль, чтобы у всех был стимул номинировать и выбирать лучших валидаторов. Эти принципы не меняются, просто не хочется платить такие высокие награды. Так что перемены будут, но надеюсь, новая экономическая модель минимизирует негативные эффекты.

Что такое zkJAM?

Kristen: Действительно, мнения в сообществе разделились. Сначала все требовали “снизить инфляцию”, теперь, когда начинается дефляция, появились недовольные. Я считаю, что направление правильное, спасибо за глубокое мнение.

Теперь обсудим техническую тему — ZKJAM. Это слово я увидела на слайде Gavin, пока оно выглядит концептуально. Но Zero-Knowledge Proofs (ZK) в последние годы очень популярны в Web3, многие считают ZK-Rollups и масштабируемость “конечным решением”. Как вы думаете, каким будет будущее JAM с ZK? Junha, начни, пожалуйста.

Junha: Хорошо. Gavin сравнил JAM с децентрализованным “супер bare-metal компьютером”, а сервисы на нем — как операционные системы на железе, например, Windows или macOS.

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

Даже если механизм безопасности JAM перейдет с текущей “аудитной heavy re-execution модели” на “модель на основе ZK-доказательств”, если это будет тщательно проверено и даст лучшие результаты, то стоит внедрять.

Так что если ZK и JAM будут хорошо совместимы и эффективнее нынешнего подхода, апгрейд вполне реален, и общий опыт не сильно изменится.

Kristen: Спасибо за мнение. Думаю, некоторые слушатели могли запутаться в технических терминах, но не переживайте — будет обзорная статья, можно будет перечитать. Теперь слово Bryan.

Bryan: Думаю, важно различать два понятия: JAM как инфраструктура для ZK-безопасных Rollup и JAM, который сам обеспечивает безопасность через ZK. Это разные вещи.

Через PVM в JAM можно развернуть любые ZK-алгоритмы или архитектуры, например, новые ZK-Rollup протоколы — это реализовать несложно.

Но если JAM сам будет обеспечивать безопасность через ZK, это потребует много исследований и оптимизации существующих алгоритмов. Сейчас это очень “фронтирная” область. Все зависит от текущего состояния — пока алгоритмы не достаточно быстрые и дешевые, но завтра кто-то может изобрести решение в 100 раз эффективнее, и все изменится.

Так что если появится реально полезная интеграция ZK, делающая JAM безопаснее, я только за.

Kristen: Надеюсь, в этой области действительно будет прорыв. Boy Maas, как опытный разработчик, что думаешь?

Boy Maas: Думаю, Bryan и Junha уже все хорошо объяснили. Мне нравится JAM именно за его прагматичность. Все решения в нем направлены на то, чтобы система реально работала и выполняла вычисления. Как сказал Bryan, сейчас делать все через ZK слишком дорого и нереалистично. Думаю, в будущем возможна “гибридная модель” — традиционный аудит и ZK параллельно.

Но пока ZK слишком дорог и не практичен, хотя за 12 месяцев — 5 лет в этой области многое изменится. Если ZK станет эффективным, это будет очень привлекательная технология, способная переопределить модель безопасности и архитектуру всей системы.

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

В JAM будет создан редакционный комитет Gray Paper

Kristen: Спасибо за ваши мнения. Следующая тема — механизм управления JAM.

Gavin продолжит быть главным редактором Gray Paper и объявил о создании “редакционного комитета”, который будет состоять из технически компетентных участников, глубоко вовлеченных в разработку JAM. В будущем они будут совместно принимать решения об обновлениях, приоритетах и ключевых изменениях протокола. Как вы, как разработчики, относитесь к такому комитету? Возможны ли отклонения от изначальных целей? Как с этим бороться? Начнем с Boy Maas.

Boy Maas: Думаю, это очень важный вопрос. Для такой высокотехнологичной и профессиональной сферы наличие комитета для обновления Gray Paper — абсолютно логично и необходимо. Решения должны принимать люди, глубоко понимающие JAM и имеющие большой практический опыт. То, что Gavin возглавит комитет — разумно, я полностью поддерживаю такой способ управления.

Kristen: То есть ты считаешь, что коллективное принятие решений профессиональной командой — это хорошо?

Boy Maas: Да, полностью согласен.

Kristen: Хорошо, Bryan, твое мнение?

Bryan: На самом деле, все проекты по сути управляются каким-то “комитетом”, просто его состав и размер могут отличаться. Важно, чтобы процесс управления был четко прописан.

Я считаю, что формализация процесса управления — это уже прогресс: все знают, как принимаются обновления, это повышает прозрачность и позволяет в будущем улучшать процесс. Если нет правил — нечего улучшать.

Gray Paper очень сложен, почти все разработчики JAM перечитывали его много раз в разных версиях. Но честно говоря, кроме Gavin, возможно, никто не понимает его на 100%, а может, и Gavin не знает все детали. Сейчас многие участвуют в редактировании документа — исправляют опечатки, формулы, логику — это уже коллективная работа.

Поэтому, на мой взгляд, только люди с многолетним опытом в этой области должны участвовать в изменениях Gray Paper. Малейшее изменение может вызвать огромные последствия. Это вопрос будущего Web3, даже интернета, и безопасности огромных активов — нужно быть очень осторожными. Прозрачность и открытость важны. Все могут предлагать идеи, но нужно доказать, что ты их действительно понимаешь, иначе шум заглушит полезные предложения.

Kristen: Значит, комитету нужна система — кто может вступить, как организовать членов и т.д. Ведь у всех свое мнение, без правил легко возникнут разногласия или отклонения от целей.

Bryan: Поэтому нам нужны смарт-контракты и четкие процессы, чтобы все было записано. Если правила прописаны, все могут контролировать исполнение, все прозрачно — риск отклонения минимален. Если все решается “в темной комнате”, никто не знает, что происходит — вот тогда легко уйти в сторону. Поэтому прозрачность особенно важна, особенно если процесс можно реализовать через смарт-контракты — тогда механизм будет устойчивым в долгосрочной перспективе.

Kristen: Поняла, помню, что в сообществе Bitcoin тоже есть похожий комитет разработчиков.

Bryan: Да, в сообществе Bitcoin есть группа core-разработчиков, но окончательное решение принимается через форк: какая цепь набирает больше хешрейта, та и побеждает.

Kristen: Поняла, спасибо за объяснение. И наконец, Junha, твое мнение?

Junha: Я считаю создание редакционного комитета очень естественным и важным шагом. Проект JAM сам по себе уникален: до появления полноценного ПО сначала была опубликована полная техническая спецификация (Gray Paper). В ней много математических формул, определяющих входы и выходы системы. Публикация документа до разработки — это стремление к большей децентрализации и устойчивости системы.

Поэтому Gray Paper с момента публикации уже много раз редактировался, и даже после версии 1.0 он будет дорабатываться.

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

В такой ситуации коллективная работа над спецификацией явно лучше, чем если бы все делал один автор.

Как сказал Bryan, прозрачность очень важна, процесс принятия решений комитетом должен быть открытым. Я также надеюсь, что больше команд, использующих JAM, будут активно участвовать в рецензировании, корректировке и обратной связи, а не просто “верить, что Gavin всегда прав”. Такой подход поможет находить улучшения. Это хороший старт, и он оправдан с учетом особенностей JAM.

Мы, возможно, недооцениваем, что JAM принесет блокчейну

Kristen: Хорошо, это действительно хороший старт. Если весь процесс будет прозрачным — это замечательно. Спасибо за ваши мнения, думаю, мы обсудили все темы на сегодня.

В завершение — есть ли у вас что добавить? О JAM, о Web3 Summit — может, что-то не успели сказать? Начнем с Bryan.

Bryan: Нет, особо добавить нечего. JAM — это базовая инфраструктура, она важна, но не всеобъемлюща. Главное — сервисы и приложения на JAM, ведь пользователи будут взаимодействовать именно с ними, а не с JAM напрямую.

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

Kristen: Спасибо. Boy Maas, есть ли что добавить о Polona или JAM?

Boy Maas: Конечно. Прежде всего — о JAM. Помню, в Лиссабоне Gavin делал презентацию о JAM. Тогда у меня возникло ощущение, что мы, возможно, недооцениваем, что эта платформа принесет блокчейн-сообществу.

“Пропускная способность” и гибкость JAM — это то, чего не было ни в одном блокчейне ранее. Думаю, это уже можно считать важной вехой в истории блокчейнов, особенно с учетом новых приложений, которые он сможет поддерживать — это действительно уникально.

Еще новость: наш проект Polona быстро развивается, мы уже запустили proof-of-concept на JAM. Мы перенесли SVM Solana на PVM, то есть теперь можно запускать байткод Solana на JAM, включая кросс-контрактные вызовы — все уже работает, это очень круто. Это демонстрирует мощь JAM.

Kristen: Отлично, спасибо! И наконец, Junha, твое слово.

Junha: Я надеюсь, что больше людей обратят внимание на JAM, Polkadot и Gray Paper. Я очень хочу познакомиться и пообщаться с единомышленниками, поделиться идеями.

Сейчас клиенты JAM еще в разработке, поэтому пока нет много “готовых” примеров приложений. Команда Gavin показывала некоторые демо, но пока нет достаточно реальных кейсов, чтобы убедить всех в возможностях системы.

Но если вам интересна философия Web3 и вы хотите двигать индустрию вперед, JAM — проект, который стоит изучить глубже. Я сейчас работаю над ним один, поэтому очень хочу познакомиться с единомышленниками, даже если просто вместе читать Gray Paper и обсуждать идеи. Надеюсь, мы сможем обмениваться мыслями и даже создавать что-то новое, особенно после завершения разработки ноды.

Kristen: Спасибо за мнение, и огромное спасибо всем гостям за интересные взгляды и идеи! Спасибо всем слушателям за участие, советую подписаться на Twitter наших гостей — аккаунты есть в анонсе PolkaWorld. Независимо от того, обычный вы пользователь или разработчик, следить за новостями JAM очень полезно. Спасибо за внимание, до встречи! Пока!