Ниже приведено подробное объяснение Polkadot1, Polkadot2 и того, как они превратились в JAM. (Дополнительные сведения см. на странице:https://www.navalmanack.com/almanack-of-naval-ravikant/how-to-think-clearly. Эта статья предназначена для технических читателей, особенно для тех, кто может быть не очень хорошо знаком с Polkadot, но имеет некоторое представление о блокчейн-системах и, вероятно, знаком с технологиями из других экосистем.
Я считаю, что этот статья служит хорошим предтечей к прочтению JAM Gray Paper. (Для более подробной информации см.https://graypaper.com/)

Фоновые знания

Эта статья предполагает, что читатель знаком с следующими концепциями:

• Описание блокчейна как функции перехода состояний.
• Понимание того, что означает "состояние". (Дополнительные сведения см.https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/blockchain_state_machines/index.html)
• Экономическая безопасность и доказательство доли. (Для получения более подробной информации см.: https://polkadot-blockchain-academy.github.io/pba-book/economics/economics-of-polkadot/page.html#staking-concept,https://www.youtube.com/watch?v=suyram9vaFc)

Введение: Polkadot1

Давайте сначала вспомним самые инновационные особенности Polkadot1.

Социальные аспекты:

• Polkadot - это масштабная децентрализованная автономная организация (DAO). Сеть реализует полностью on-chain, самоисполняющееся управление, включая безфорковые обновления времени выполнения.
• Комиссия по ценным бумагам и биржам признала DOT как программное обеспечение, а не ценность. (Подробнее см.:https://polkadot.com/newsroom/press-releases/web3-foundation-announces-polkadot-blockchains-native-token-dot-has-morphed-and-is-software-not-a-security)
• Большую часть работ по развитию сети выполняет стипендиатская программа Polkadot (дополнительные сведения см. в: https://polkadot-fellows.github.io/dashboard/), а не компанией, финансирующей проект, Parity Technologies,https://www.parity.io/).

Технические аспекты:

• Polkadot реализовал общую безопасность и распределенное выполнение.
• Используя метапротокол на основе WASM (дополнительные сведения см.: https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/wasm_meta_protocol/index.html), код блокчейна хранится в состоянии в виде байт-кода. Это позволяет осуществлять большинство обновлений без разветвлений и обеспечивает гетерогенное шардирование. (См. соответствующие разделы для получения дополнительной информации о "гетерогенном шардировании".)

Фрагментированное выполнение: ключевые моменты

В настоящее время мы обсуждаем сеть уровня 1, которая размещает другие сети "блокчейн" уровня 2, аналогично Polkadot и Ethereum. Следовательно, термины Уровень 2 и Парачейн могут использоваться взаимозаменяемо.

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

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

Это демонстрирует монолитный блокчейн (в отличие от черепаховидного). Все сетевые валидаторы обрабатывают входы (т. е. блоки) один за другим. В такой системе, если уровень 1 хочет разместить больше уровней 2, то все валидаторы должны повторно выполнить все задания уровней 2. Очевидно, что такой метод не масштабируется.

Оптимистические роллапы решают эту проблему, перезапуская (доказательства мошенничества) только при утверждении о мошенничестве. Роллапы на основе SNARK решают эту проблему, используя тот факт, что стоимость проверки доказательств SNARK значительно ниже стоимости их генерации, что позволяет всем валидаторам эффективно проверять доказательства SNARK. Для получения более подробной информации обратитесь к разделу «Приложение: Диаграмма масштабируемости».

Простым решением для шардирования является разделение набора валидаторов на более мелкие подмножества и повторное выполнение блоков уровня 2 этими более маленькими подмножествами. В чем проблема этого подхода? По сути, мы шардируем как выполнение, так и экономическую безопасность сети. Такое решение уровня 2 имеет более низкий уровень безопасности по сравнению с уровнем 1, и его безопасность дополнительно снижается по мере того, как мы делим набор валидаторов на большее количество шардов.

В отличие от оптимистичных роллапов, где издержки повторного выполнения не всегда можно избежать, Polkadot был разработан с учетом разделенного выполнения. Это позволяет части валидаторов повторно выполнять блоки уровня 2, предоставляя достаточно крипто-экономических доказательств всей сети, чтобы доказать, что блок уровня 2 так же безопасен, как если бы его выполнил полный набор валидаторов. Это достигается благодаря новаторскому (и недавно формализованному) механизму, известному как ELVES. (Для получения более подробной информации см.:https://eprint.iacr.org/2024/961)

Коротко говоря, ELVES можно рассматривать как механизм «подозрительных роллапов». Через несколько раундов валидаторы активно опрашивают других валидаторов о том, действителен ли данный блок уровня 2, мы можем с высокой вероятностью подтвердить его действительность. В случае спора полный набор валидаторов быстро вовлекается. Основатель Polkadot Роб Хабермейер подробно объяснил это в статье. (Для получения более подробной информации см.: https://polkadot.com/blog/polkadot-v1-0-sharding-and-economic-security#approval-checking-and-finality)

ELVES позволяют Polkadot обладать как осколочным выполнением, так и общей безопасностью, двумя свойствами, которые ранее считались взаимоисключающими. Это основное техническое достижение Polkadot1 в масштабируемости.

Теперь давайте продвинемся вперед с аналогией "Ядра". Разделенная выполнение блокчейна очень похожа на ЦП: так же как ЦП может иметь несколько ядер, выполняющих инструкции параллельно, Polkadot может обрабатывать блоки уровня 2 параллельно. Поэтому блок уровня 2 в Polkadot называется парачейн, а среда, где более мелкие подмножества валидаторов повторно выполняют один блок уровня 2, называется "ядром". Каждое ядро может быть абстрагировано как "группа сотрудничающих валидаторов".

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

Гетерогенность

До сих пор мы обсуждали только масштабируемость и фрагментированное выполнение, предлагаемые Polkadot. Важно отметить, что каждый из фрагментов Polkadot, фактически, является совершенно отдельным приложением. Это достигается благодаря метапротоколу, сохраненному в виде байткода: протоколу, который хранит определение самого блокчейна в виде байткода в его состоянии. В Polkadot 1.0 в качестве предпочтительного байткода используется WASM, в то время как в JAM принят PVM/RISC-V.

Вот почему Полкадот называют гетерогенным черепичным блокчейном. (Для получения более подробной информации см.:https://x.com/kianenigma/status/1790763921600606259) Каждый уровень 2 - это совершенно другое приложение.

Polkadot2

Один важный аспект Polkadot2 заключается в том, что использование ядер становится более гибким. В исходной модели Polkadot сроки аренды ядер варьировались от 6 месяцев до 2 лет, что подходило для предприятий с изобилием ресурсов, но было менее реальным для меньших команд. Функция, позволяющая более гибко использовать ядра Polkadot, называется "Agile Coretime". (Дополнительные сведения см. в: https://polkadot.com/agile-coretime) В этом режиме срок аренды ядра может быть как один блок, так и до месяца, с предельной ценой для тех, кто хочет арендовать на более длительный период.

Другие особенности Polkadot 2 постепенно раскрываются по мере развития нашего обсуждения, поэтому здесь нет необходимости подробно на них останавливаться.

Внутриядерные против цепных операций

Для понимания JAM важно сначала понять, что происходит, когда блок уровня 2 входит в ядро Polkadot. Ниже приведено упрощенное объяснение.

Помните, что ядро в основном состоит из набора валидаторов. Так что когда мы говорим "данные отправляются в ядро", это означает, что данные передаются этому набору валидаторов.

1. Блок уровня 2 вместе с частью состояния этого уровня 2 отправляется в ядро. Эти данные содержат всю необходимую информацию для выполнения блока уровня 2.

2. Часть основных валидаторов повторно выполнит блок уровня 2 и продолжит выполнение задач, связанных с консенсусом.

3. Эти основные валидаторы предоставляют повторно выполненные данные другим валидаторам за пределами ядра. Согласно правилам ELVES, эти валидаторы могут решить, повторно выполнить ли блок уровня 2, для этого им нужны эти данные.

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

1. Наконец, небольшая часть последнего состояния Layer 2 становится видимой на главной ретрансляционной цепи Polkadot. В отличие от предыдущих операций, этот шаг намного дешевле повторного выполнения блока Layer 2, и он влияет на основное состояние Polkadot. Он виден в блоке Polkadot и выполняется всеми валидаторами Polkadot.

Из этого мы можем изучить несколько ключевых операций, которые выполняет Polkadot:

• Из шага 1 мы можем заключить, что Polkadot представил новый тип исполнения, отличный от традиционных функций перехода состояния блокчейна. Обычно, когда все сетевые валидаторы выполняют задачу, основное состояние блокчейна обновляется. Это то, что мы называемвыполнение on-chain, и это происходит на Шаге 3. Однако то, что происходит внутри ядра (Шаг 1), отличается. Эта новая форма вычислений блокчейна называется внутреннее исполнение.
• Из шага 2 мы делаем вывод, что у Polkadot есть собственный Доступность данных (DA)Уровень и Уровни 2 автоматически используют его, чтобы обеспечить доступность доказательств их выполнения в течение определенного периода времени. Однако блоки данных, которые могут быть размещены на уровне DA, фиксированы и содержат только доказательства, необходимые для повторного выполнения Уровня 2. Кроме того, код парачейна не читает данные уровня DA.

Понимание этого является основой для понимания JAM. Вот краткое изложение:

• Выполнение в ядреОтносится к операциям, которые происходят внутри ядра. Эти операции богаты, масштабируемы и защищены криптоэкономикой и ELVES, обеспечивая ту же безопасность, что и выполнение on-chain.
• Выполнение в сети: Операции, выполненные всеми валидаторами. Они обеспечивают экономическую безопасность по умолчанию, но они более затратны и ограничены, поскольку каждый выполняет все задачи.
• Доступность данных: Означает способность валидаторов Polkadot гарантировать доступность определенных данных в течение определенного периода времени и предоставлять их другим валидаторам.

JAM

Понимая это, мы можем сейчас представить JAM.

JAM - новый протокол, вдохновлённый дизайном Polkadot и полностью совместимый с ним, нацеленный на замену ретрансляционной цепи Polkadot и полную децентрализацию и неограниченное использование основной функциональности.

Построенный на Polkadot 2, JAM стремится сделать развертывание Layer 2s на ядре более доступным, предлагая даже большую гибкость, чем модель agile-coretime.

• Polkadot 2 позволяет развертывать уровень 2 на основе более динамичным образом.
• JAM нацелен на то, чтобы позволить развертывать любое приложение в основе Polkadot, даже если эти приложения не структурированы как блокчейны или уровни 2.

Это достигается в основном путем предоставления разработчикам трех основных концепций, обсуждаемых ранее: выполнение on-chain, выполнение in-core и уровень DA.

Другими словами, в JAM разработчики могут:

• Полностью разрабатывать как внутриядерные, так и ончейновые задачи.
• Чтение и запись произвольных данных в слой DA Polkadot.

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

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

Сервисы и рабочие элементы

В JAM то, что ранее называли Layer 2s или парачейнами, теперь называетсяУслуги, а то, что ранее называлось блоками или транзакциями, теперь называетсяРабочие элементыилиРабочие пакеты. Конкретно, элемент работы принадлежит к сервису, а рабочий пакет - это коллекция элементов работы. Эти термины намеренно широкие, чтобы охватывать случаи использования за пределами блокчейна/Layer 2.

Сервис описывается тремя точками входа, две из которых являются fn refine() и fn accumulate(). Первая описывает, что делает сервис во время выполнения в памяти, а вторая описывает, что делает во время выполнения на цепи.

Наконец, названия этих точек входа являются причиной, по которой протокол называется JAM (Join Accumulate Machine).Присоединитьсяотносится кfn refine(), что является фазой, когда все ядра Polkadot обрабатывают большой объем работы параллельно по различным сервисам. После обработки данных они переходят к следующему этапу. Накопитьотносится к процессу накопления всех этих результатов в основное состояние JAM, который происходит во время фазы выполнения on-chain.

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

Полуконсистентность

При рассмотрении существующей документации по XCM (выбранный язык Полкадота для коммуникации парачейна), вся коммуникация является асинхронной (дополнительные сведения см. вздесьЭто означает, что после отправки сообщения вы не можете ждать его ответа. Асинхронное общение является симптомом несогласованности в системе и одним из основных недостатков постоянно шардированных систем, таких как Polkadot 1, Polkadot 2 и существующие экосистемы Layer 2 Ethereum.

Однако, как описано в разделе 2.4Graypaper, полностью согласованная система, которая остаётся синхронной для всех своих арендаторов, может масштабироваться только до определенной степени, не жертвуя универсальностью, доступностью или устойчивостью.

• Синхронный ≈ Согласованность || Асинхронный ≈ Несогласованность

Здесь JAM выделяется: введя несколько функций, JAM достигает нового промежуточного состояния, известного как полуконсистентная система. В этой системе подсистемы, которые часто общаются, могут создать согласованную среду друг с другом, не заставляя весь систему оставаться согласованной. Это было наилучшим образом описано доктором Гэвином Вудом, автором Серого бумаги, в интервью: https://www.youtube.com/watch?t=1378&v=O3kRAVBTkfs&embeds_referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ

Другой способ понять это - рассматривать Polkadot/JAM как разделенную систему, где границы между этими осколками являются гибкими и динамически определяемыми.

Polkadot всегда был разделенным и полностью гетерогенным.

Теперь это не только расщеплено и гетерогенно, но эти границы осколков могут быть гибко определены - то, что Гэвин Вуд называет "полусогласованной" системой в своих твитах и Graypaper. (см.https://x.com/gavofyork?ref_src=twsrc%5Etfw、https://graypaper.com/)

Несколько функций делают этот полусогласованный статус возможным:

1. Доступ к бессостоятельному параллельному выполнению в ядре, где различные службы могут взаимодействовать только синхронно с другими службами в пределах одного и того же ядра и конкретного блока, а также к выполнению на цепи, где службы могут получить доступ к результатам всех служб по всем ядрам.
2. JAM не навязывает конкретное планирование служб. Службы с частым общением могут предоставлять экономические стимулы своим планировщикам для создания рабочих пакетов, содержащих эти часто общающиеся службы. Это позволяет этим службам работать в одном и том же ядре, делая их взаимодействия синхронными, хотя они и распределены.
3. Кроме того, сервисы JAM могут получить доступ к слою DA и использовать его в качестве временного, но крайне экономичного слоя данных. Как только данные размещаются в DA, они в конечном итоге распространяются на все ядра, но сразу же становятся доступными в пределах одного и того же ядра. Следовательно, сервисы JAM могут достичь более высокой степени доступа к данным, планируя свое выполнение в пределах одного и того же ядра через последовательные блоки.

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

CorePlay

Этот раздел знакомит с CorePlay, экспериментальным концептом в среде JAM, который можно описать как новую модель программирования смарт-контрактов. На момент написания CorePlay еще не был полностью определен и остается спекулятивной идеей.

Для понимания CorePlay нам сначала нужно познакомиться с виртуальной машиной (VM), выбранной JAM: PVM.

PVM

PVM - ключевая деталь как в JAM, так и в CorePlay. Нижестоящие детали PVM выходят за рамки этого документа и лучше всего объясняются предметными экспертами в Graypaper. Однако для данного объяснения мы выделим несколько ключевых атрибутов PVM:

• Эффективный учет
• Возможность приостановить и возобновить выполнение

Последнее особенно важно для CorePlay.

CorePlay - это пример того, как гибкие примитивы JAM могут быть использованы для создания синхронной и масштабируемой среды смарт-контрактов с высоко гибким программным интерфейсом. CorePlay предлагает, чтобы смарт-контракты на основе акторов развертывались непосредственно на ядрах JAM, позволяя им воспользоваться синхронными программными интерфейсами. Разработчики могут писать смарт-контракты, как если бы они были простыми функциями fn main(), используя выражения, например let результат = other_coreplay_actor(data).await?общаться. Еслидругой актер CorePlayнаходится на той же ядро JAM в том же блоке, этот вызов синхронен. Если это на другом ядре, актер будет приостановлен и возобновлен в последующем блоке JAM. Это становится возможным благодаря службам JAM, их гибкому планированию и возможностям PVM.

Сервис CoreChains

Наконец, давайте подытожим основную причину того, что JAM полностью совместим с Polkadot. Флагманским продуктом Polkadot являются его гибкие ядерные парачейны, которые продолжают работу в JAM. Самые ранние развернутые сервисы в JAM, скорее всего, будут называться CoreChains или Parachains, позволяя существующим парачейнам в стиле Polkadot-2 работать на JAM.

Дополнительные сервисы могут быть развернуты на JAM, и существующий сервис CoreChains может взаимодействовать с ними. Однако текущие продукты Polkadot останутся надежными, просто открывая новые возможности для существующих команд парачейн.

Приложение: Разделение данных

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

• Полностью Совместимые Системы: Это платформы, где все синхронизировано, например, Solana или те, что эксклюзивно развернуты на Ethereum Layer 1. Вся информация приложения хранится on-chain и легко доступна всем другим приложениям. Это идеально с точки зрения программирования, но не масштабируется.
• Несовместимые системы: Данные приложения хранятся за пределами уровня 1 или в различных изолированных осколках. Это очень масштабируется, но плохо работает с точки зрения композиции. Модели Polkadot и Ethereum rollup относятся к этой категории.

JAM предлагает что-то более чем эти два варианта: это позволяет разработчикам публиковать произвольные данные в слой JAM DA, который служит своеобразным золотым стандартом между on-chain и off-chain данными. Новые приложения могут быть построены с использованием слоя DA для большей части своих данных, в то время как только абсолютно критические данные сохраняются в состоянии JAM.

Приложение: Ландшафт масштабируемости

Этот раздел пересматривает нашу перспективу масштабируемости блокчейна, которая также обсуждается в Graypaper, хотя здесь представлена более кратко.

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

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

Горизонтальное масштабирование - это стратегия, принятая Ethereum и Polkadot: снижение нагрузки, которую каждому участнику нужно обрабатывать. В традиционных распределенных системах это достигается путем добавления большего количества реплицирующих машин. В блокчейне "компьютером" является весь сеть валидаторов. Распределяя задачи между ними (как это делает ELVES) или оптимистически снижая их ответственность (как в оптимистических Rollups), мы уменьшаем нагрузку на весь набор валидаторов, тем самым достигая горизонтального масштабирования.

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

В заключение:

1. Вертикальное масштабирование: Высокопроизводительное оборудование + оптимизация монолитных блокчейнов.
2. Горизонтальное масштабирование:
   • Оптимистичные роллапы
   • Роллапы на основе SNARK
   • ЭЛЬФЫ: Циничные роллапы Polkadot

Приложение: Та же аппаратная часть, обновление ядра

Этот раздел основан на аналогии Роба Хабермейера с Sub0 2023: Polkadot: Ядро/Пользовательское пространство | Sub0 2023 - YouTube (see: https://www.youtube.com/watch?v=15aXYvVMxlw) представляя JAM как обновление для Polkadot: обновление ядра на том же оборудовании.

В типичном компьютере мы можем разделить весь стек на три части:

1. Аппаратное обеспечение
2. Ядро
3. Пользовательское пространство

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

В Polkadot ядро до сих пор состоит из двух основных частей:

1. Протокол Парачейнс: фиксированный, упрямый способ использования ядер.
2. Набор низкоуровневых функций, такие как токен DOT и его передаваемость, стейкинг, управление и т. д.

Оба из них существуют в цепи ретрансляции Polkadot.

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

Мы можем визуализировать этот процесс следующим образом:

Polkadot давно предполагал перенос большего количества основных функций к его основным пользователям - парачейнам. Именно этой цели и служит концепция Минимального реле RFC. (Подробнее см.:Минимальный протокол ретрансляции RFC)

Это означает, что Цепь Реле Polkadot будет заниматься только предоставлением протокола парачейна, тем самым уменьшая пространство ядра в некоторой степени.

Как только эта архитектура будет реализована, будет легче представить, как будет выглядеть миграция JAM. JAM значительно уменьшит ядро Polkadot, сделав его более универсальным. Кроме того, протокол Parachains перейдет в пользовательское пространство, поскольку это один из немногих способов построения приложений на одном и том же ядре (аппаратном) и ядре (JAM).

Это также подтверждает, почему JAM заменяет цепочку ретрансляции Polkadot, а не парачейны.

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

Disclaimer：

1. Эта статья перепечатана с [Институт экологических исследований Polkadot], Все авторские права принадлежат автору оригинала [Институт исследований экосистемы Polkadot]. Если есть возражения к этому перепечатыванию, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.