статье Киана Паймани, основного разработчика Parity, объясняет новейший протокол JAM Polkadot с технической точки зрения, чтобы помочь людям лучше понять, как JAM привносит новую масштабируемость в экосистему Polkadot.
Автор: Киан Паймани, основной разработчик Parity
Составитель: Polkadot Labs
«Базовый курс по Полкадоту» — это наша серия статей для новичков, которые пытаются объяснить основы Полкадота и предоставить всестороннее понимание этой платформы. Это огромная задача, полная вызовов, но мы надеемся, что благодаря этим усилиям люди смогут правильно понять Полкадот и быстро освоить связанные с ним знания. Сегодняшняя статья является 148-м выпуском этой рубрики, и в ней разработчик ядра Парити Киан Паймани технически рассматривает новый протокол JAM, предложенный для Полкадота, чтобы помочь людям лучше понять, как JAM может принести новые возможности масштабируемости в экосистему Полкадота. В этой статье автор пишет от первого лица.
*Ниже приведено подробное объяснение Polkadot1, Polkadot2 и того, как он превратился в JAM. Эта статья предназначена для технических читателей, особенно для тех, кто не очень хорошо знаком с Polkadot, но имеет некоторые знания о блокчейн-системах и, возможно, знаком с другими технологиями, связанными с экосистемой. *
Я считаю, что прочтение данной статьи является хорошей подготовкой перед прочтением JAM Белой книги. (Подробнее см.**)
Фоновые знания
Этот текст предполагает, что читатель знаком с следующими концепциями:
Описать Блокчейн как функцию перехода состояний.
Понимание того, что такое «состояние». (Подробнее см. _sdk_docs/reference_docs/blockchain_state_machines/index.html)
Экономическая безопасность и аттестация стейкинга。（详情请参见：、）
Введение: Polkadot1
Во-первых, давайте вспомним, что, по моему мнению, самой инновационной особенностью Polkadot1 является.
Социальный аспект:
Polkadot - это огромная Децентрализованная автономная организация (DAO). Сеть реализует полностью автоматизированное управление в блокчейне, включая выполнение обновлений времени выполнения без форков.
Комиссия по ценным бумагам и биржам (SEC) США рассматривает DOT как программное обеспечение, а не как ценную бумагу. (детали см. ниже: )
Большая часть работы по разработке сети выполняется полкадот-стипендиатами (подробнее см. ), а не финансирующими компаниями (например, Parity:).
Технический уровень:
Полка реализовала общую безопасность и Шардинг исполнения.
Используя мета-протокол, основанный на WASM (дополнительные сведения см. в файле _sdk_docs/reference_docs/wasm_meta_protocol/index.html), код блокчейна хранится в состоянии в виде байт-кода. Это позволяет избежать форков при большинстве обновлений, а также реализовать шардинг гетерогенного типа.
Дополнительную информацию о "гетерогенном Шардинге" см. в соответствующих разделах.
Шардинг执行：核心要点
В настоящее время мы обсуждаем сеть уровня 1, которая управляет сетями уровня 2 «блокчейн» и аналогична Polkadot и Ethereum. Поэтому термины уровня 2 и параллельная цепочка (Parachain) могут использоваться взаимозаменяемо.
Основная проблема масштабируемости блокчейна заключается в том, что существует группа валидаторов, которые могут с помощью экономических механизмов Доказательства доли (Proof-of-Stake) обеспечить надежное выполнение определенного кода. По умолчанию эти валидаторы должны повторно выполнять всю работу друг друга. Поэтому, если мы заставим всех валидаторов постоянно повторно выполнять всю работу, вся система будет не масштабируемой.
Обратите внимание, что в этой модели увеличение количества валидаторов на самом деле не повышает пропускную способность системы, только если принцип абсолютной перезапускаемости выше неизмененной.
Выше показана одиночная Блокчейн (в отличие от ШардингБлокчейн). Все валидаторы сети будут по одному обрабатывать входные данные (т.е. Блок).
В такой системе, если Layer1 хочет управлять большим количеством Layer2, то все валидаторы теперь должны повторно выполнить все задачи Layer2. Очевидно, что такой подход не масштабируем. Оптимистичные роллапы - это один из способов избежать этой проблемы, поскольку повторное выполнение происходит только при заявлении о мошенничестве. Роллапы на основе SNARK обходят эту проблему, используя факт, что стоимость проверки SNARK-доказательства намного ниже, чем его генерация, и позволяют всем валидаторам проверить, что SNARK-доказательство является обоснованным. Дополнительную информацию об этом см. в «Приложение: Карта пространства масштабируемости».
Простым решением для Шардинга является разделение набора валидаторов на более мелкие подмножества и повторное выполнение Layer2 Блока этим более маленьким подмножеством. В чем проблема этого подхода? Мы разделяем выполнение и экономическую безопасность сети Шардингом. Безопасность Layer2 при этом ниже, чем у Layer1, и по мере того, как мы дальше разделяем набор валидаторов на большее количество Шардингов, безопасность будет еще ниже.
В отличие от Optimistic Rollups, которые не могут перезапустить выполнение себестоимости, Полка была разработана с учетом Шардинга, что позволяет некоторым валидаторам повторно выполнить блок Layer2, при этом обеспечивая достаточную криптографическую экономическую доказуемость всем участникам сети, что подтверждает безопасность этого блока Layer2, такая же безопасность как если бы его выполнял весь набор валидаторов. Это достигается с помощью нового (недавно официально выпущенного) механизма ELVES. (см. подробности: 01928374656574839201)
Вкратце, ELVES можно рассматривать как механизм "сомнительных роллапов". С помощью активного опроса валидаторами других валидаторов о том, является ли блок Layer2 действительным, мы можем с большой вероятностью подтвердить его действительность. Фактически, при возникновении любых споров требуется немедленное участие всего набора валидаторов. Сооснователь Polkadot Роб Хабермейер подробно объясняет это в своей статье. (Подробнее см. в:)
ELVES делает возможным одновременное присутствие двух ранее считавшихся взаимоисключающих свойств: «Шардинг выполнение» и «Общая безопасность». Это основной технический результат Polkadot1 в области масштабируемости.
Продолжим обсуждение аналогии с "CORE".
Блокчейн, выполняющий Шардинг, очень похож на ЦП: как ЦП может иметь несколько ядер для параллельного выполнения команд, так и Polkadot может параллельно обрабатывать блоки Layer2. Вот почему Layer2 на Polkadot называется парачейн, а среда, в которой более маленький подмножество валидаторов повторно выполняет отдельный блок Layer2, называется «CORE». Каждое ядро можно абстрагировать как «группу сотрудничающих валидаторов».
Вы можете представлять себе отдельную Блокчейн как потребляющую только один Блок в любой временной период, в то время как Полка потребляет один Релецепной блок и один параллельный блок каждого ядра в каждом временном периоде.
Гетерогенность
До сих пор мы обсуждали только масштабируемость и Шардинг, предоставляемый Полка. Следует отметить, что каждый Шардинг в Полка фактически представляет собой полностью разные приложения. Это достигается с использованием реализации Протокола в виде байтового кода: способ хранения Блокчейна в самом состоянии Блокчейна как байтового кода. В Polkadot 1.0 используется WASM в качестве предпочтительного байтового кода, в то время как в JAM используется PVM/RISC-V.
В общем, вот почему Полка называется гетерогенной фрагментированной блокчейном. (см. также: ) Каждый Layer2 - это совершенно отдельное приложение.
Полкадот2
Важной частью Polkadot2 является более гибкое использование основы. В оригинальной модели Polkadot срок аренды основы может варьироваться от 6 месяцев до 2 лет, что подходит для ресурсных предприятий, но не очень подходит для малых команд. Особенностью Polkadot, позволяющей использовать основу более гибко, является «гибкое ядро времени» (agile coretime). В этом режиме срок аренды основы Polkadot может быть как коротким, как один Блок, так и длинным, как один месяц, обеспечивая пользователей, желающих долгосрочную аренду, гарантированным верхним пределом цены.
Другие особенности Polkadot 2 постепенно проявляются в процессе нашего обсуждения, поэтому здесь не нужно слишком много излишеств.
Внутренние операции ядра и в блокчейне
Для понимания JAM сначала нужно понять, что происходит, когда блок Layer2 попадает в ядро Полка.
Следующее содержание было значительно упрощено.
Взглянем на это еще раз: ядро состоит главным образом из группы валидаторов. Поэтому, когда мы говорим "данные отправляются в ядро", на самом деле мы имеем в виду, что эти данные передаются этой группе валидаторов.
Один Layer2 Блок вместе с частью состояния этого Layer2 отправляется в ядро. Эти данные содержат всю необходимую информацию для выполнения этого Layer2 Блок.
Часть проверяющих в ядре повторно выполнит блок Layer2 и продолжит обрабатывать задачи, связанные с Соглашение.
Ядерные валидаторы будут повторно предоставлять необходимые данные другим валидаторам (внешним ядерным валидаторам). Другие валидаторы могут решить повторно выполнить этот Layer2 блок в соответствии с правилами ELVES и им потребуются эти данные для выполнения этой операции.
Обратите внимание, до сих пор все операции происходят вне главного блока и функции изменения состояния Полка. Все происходит внутри ядра и на уровне доступности данных.
В конечном итоге, небольшая часть последнего состояния Layer2 будет видна в основной релецепи Полка. В отличие от всех предыдущих операций, эта операция значительно дешевле фактического повторного выполнения блока Layer2, она повлияет на основное состояние Полка, будет видна в блоке Полка и будет выполнена всеми валидаторами Полка.
Из вышеизложенного мы можем обсудить некоторые действия, которые выполняет Polkadot:
Во-первых, из шага 1 мы можем заключить, что в Полка существует новый способ выполнения, отличный от традиционной функции перехода состояний блокчейна. Обычно, когда все валидаторы в сети выполняют определенную работу, состояние основной цепи блоков обновляется. Мы называем это в блокчейне операцией (on-chain operation), именно это происходит на шаге 3. Однако внутри ядра (шаг 1) происходит что-то отличное. Мы называем этот новый тип вычислений блокчейна in-core ution.
Далее, из пункта 2 мы можем сделать вывод, что Polkadot уже предоставил собой нативный уровень доступности данных (Data-Availability, в дальнейшем - DA), и Layer2 автоматически использует его, чтобы гарантировать доступность своих доказательств в течение определенного времени. Однако данные блоки, которые могут быть размещены на этом уровне DA, являются фиксированными и всегда являются доказательством, необходимым для повторного выполнения Блока Layer2. Кроме того, код парачейна никогда не читает данные с уровня DA.
Понимание вышеупомянутого содержания является основой понимания JAM. Выводы следующие:
In-core ution: относится к операциям, происходящим внутри ядра. Он характеризуется богатством, масштабируемостью и обеспечивает ту же безопасность, что и ончейн-исполнение, благодаря криптоэкономике и ELVES.
в блокчейне выполнение (on-chain ution): это означает операции, выполняемые всеми валидаторами. Валидаторы, обеспечиваемые экономическими гарантиями, по умолчанию обеспечивают безопасность, но это более затратно и ограничено, так как все участники выполняют все операции.
Доступность данных (Data Availability): Валидаторы Polkadot обязуются предоставить доступность определенной информации в течение определенного времени и имеют возможность предоставлять такую информацию другим валидаторам.
ДЖЕМ
Имея понимание предыдущей части, мы можем легко перейти к представлению JAM.
JAM - это новый Протокол, разработанный под влиянием Polkadot и полностью совместимый с ним, который призван заменить ретрансляционную цепочку Polkadot и сделать основное использование полностью децентрализованным и без ограничений.
JAM построен на основе Polkadot2 в попытке сделать ядро Polkadot более доступным, но более гибким и без фиксированных ограничений по сравнению с agile-coretime.
Polkadot2 позволяет более гибко развертывать Layer2 на ядре.
JAM нацелен на то, чтобы любое приложение могло быть развернуто на основе Polkadot, даже если это приложение не является блокчейном или Layer2.
Это достигается в основном путем выявления перед основными концепциями, обсуждаемыми в начале, три основных первоначальных концепции: выполнение на цепочке, выполнение в ядре и уровень DA.
Иными словами, в JAM разработчики могут получить доступ к:
Полная Программируемость ядро и работа в блокчейне.
Разрешить чтение и запись произвольных данных в слой DA Polkadot.
Это базовое описание целей JAM. Не нужно много слов, здесь сделано много упрощений, и протокол возможно еще будет развиваться.
Имея это базовое понимание, мы теперь можем продолжить и более подробно рассмотреть некоторые детали JAM в следующих разделах.
1 Услуги и рабочие элементы
На фоне JAM, то, что ранее называлось Layer2/парачейн, теперь называется "сервис", то, что ранее называлось Блок/транзакция, теперь называется "рабочий элемент" или "рабочий пакет". Конкретно, рабочий элемент принадлежит определенному сервису, а рабочий пакет является совокупностью рабочих элементов. Эти термины были специально разработаны достаточно универсальными, чтобы охватывать различные случаи использования, превышающие блокчейн/Layer2.
Одна служба описывается тремя точками входа, из которых две - это fn refine() и fn accumulate(). Первая описывает содержимое, выполняемое службой в ядре, а вторая - содержимое, выполняемое службой в блокчейне.
Наконец, именно поэтому Протокол называется JAM (Join Accumulate Machine) - это именно поэтому назван JAM (Join Accumulate Machine). Join означает fn refine(), когда все ядра Polkadot параллельно обрабатывают большой объем работы различных сервисов, этот этап называется Join. Данные проходят через этап фильтрации, после чего они переходят к следующему этапу. Accumulate означает, что все вышеперечисленные результаты накапливаются в основном состоянии JAM, то есть в части выполнения в блокчейне.
Рабочие элементы могут точно указывать, что они выполняют в ядре, в блокчейне, и указывать, как / если / откуда читать и записывать содержимое распределенного данных озера (Distributed Data Lake).
2 Полусогласованный
При просмотре имеющейся информации о XCM (язык парачейн-коммуникации, выбранный Полка), обратите внимание, что вся связь является асинхронной. (См. подробности: ) То есть после отправки сообщения нельзя ждать ответа.
Асинхронность является проявлением несогласованности системы и основным недостатком постоянной Шардинг-системы (например, экосистемы Layer2 для существующих блокчейнов Polkadot 1 и Polkadot 2, а также Ethereum).
Однако, как описано в разделе 2.4 белой бумаги, полностью согласованная система, которая всегда синхронизирована со всеми своими арендаторами, может достичь определенного уровня только без ущерба для универсальности, доступности или гибкости. (Подробнее см.: )
Это также еще одна область, в которой JAM выделяется: путем введения различных особенностей JAM достигает нового промежуточного состояния, а именно полусогласованной системы. В этой системе подсистемы с частой связью имеют возможность создавать согласованную среду между собой, не требуя обязательного поддержания согласованности всей системы. Это лучше всего описано в интервью доктора Гавина Вуда, автора Серого книги: (см. подробности: _referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ)
Другой способ понимания - рассматривать Polkadot/JAM как систему Шардинга, где границы этих Шардингов являются подвижными и динамически определяются.
Полка всегда была Шардингом и полностью гетерогенной.
Сейчас это будет Шардингом, гетерогенным, и границы этих Шардингов могут быть гибко определены, как и в «полуконсистентной» системе, о которой Гавин Вуд говорит в Твиттере. (Подробнее см. в: _src=twsrc%5Etfw, )
Особенности, которые делают все это возможным, включают в себя:
Доступ к безсостоятельному, параллельному выполнению ядра, где различные службы могут синхронно взаимодействовать только с другими службами в том же ядре и в определенном Блоке, и выполнению в блокчейне, где службы могут получать доступ ко всем результатам служб по всем ядрам.
JAM не принуждает к выполнению какого-либо конкретного расписания обслуживания. Службы с частым обменом данными могут получать экономические стимулы от своих планировщиков, создавая пакеты работ, включающие эти службы с частым обменом данными. Это позволяет этим службам работать на одном и том же ядре, и их взаимодействие друг с другом происходит так, как будто они находятся в синхронной среде.
Кроме того, JAM сервис может получить доступ к уровню данных (DA) и использовать его в качестве временного, но крайне дешевого уровня данных. Как только данные помещаются в DA, они в конечном итоге распространяются на все ядра, но становятся доступными немедленно внутри одного и того же ядра. Таким образом, JAM сервис может путем планирования себя в одно ядро в последовательном Блоке получить более высокий уровень доступа к данным.
Важно отметить, что, хотя вышеуказанное содержание возможно в JAM, оно не обязательно применяется на уровне протокола. Поэтому ожидается, что некоторые интерфейсы теоретически будут работать асинхронно, но благодаря умным абстракциям и мотивационным мерам они могут проявляться синхронно на практике. Следующая часть будет рассматривать CorePlay как пример такой ситуации.
3 CorePlay
Этот раздел описывает CorePlay, это экспериментальная идея в среде JAM, которую можно описать как новую модель программирования смарт-контрактов. На момент написания этой статьи CorePlay еще не был подробно описан и остается только концепцией.
Для понимания CorePlay сначала нужно ознакомиться с выбранной Виртуальной машины JAM: PVM.
4 PVM
PVM - это важная деталь в JAM и CorePlay. Низкоуровневые детали PVM выходят за рамки этой статьи, лучше всего ознакомиться с описанием экспертов в белой книге. Однако для целей этой статьи достаточно описать несколько свойств PVM:
Эффективное измерение
Возможность приостановки и возобновления выполнения
Последнее особенно важно для CorePlay.
CorePlay - это пример синхронной и масштабируемой среды смарт-контрактов, созданной с использованием гибкого языка JAM, с очень гибким программным интерфейсом. CorePlay рекомендует развертывать смарт-контракты на основе акторов непосредственно на ядре JAM, чтобы они могли использовать синхронный интерфейс программирования, в котором можно писать код, как в обычной функции fn main(), и обмениваться данными через let_result=other_coreplay_actor(data).await?. Если other_coreplay_actor находится на том же ядре JAM в том же блоке, этот вызов будет синхронным; если на другом ядре, актор будет приостановлен и восстановлен в последующем блоке JAM. Это возможно благодаря сервису JAM и его гибкому планированию, а также свойствам PVM.
5 CoreChains услуги
Наконец, давайте подведем итоги основной причины, по которой JAM полностью совместим с Polkadot. Основной продукт Polkadot - это парачейны, работающие в агильном ядре времени, и этот продукт продолжается в JAM.
Вероятно, самые ранние развернутые службы в JAM будут называться CoreChains или Parachains. Этот сервис позволит существующим парачейнам в стиле Polkadot-2 работать на JAM.
Дополнительный сервис можно развернуть на JAM, и существующие сервисы CoreChains могут взаимодействовать с ними, но существующие продукты Polkadot останутся сильными и откроют новые двери только для существующих команд Parachain.
Приложение: данныеШардинг
Большая часть этой статьи рассматривает масштабируемость с точки зрения реализации Шардинга. Мы также можем рассмотреть эту же проблему с точки зрения данных. Интересно, что мы обнаружили, что это аналогично рассмотренной ранее ситуации с полуконсистентностью: в принципе, полностью консистентная система лучше, но не масштабируется; полностью несогласованная система масштабируется, но не идеальна, в то время как JAM, предложив свою модель полуконсистентности, представил новую возможность.
Полностью согласованная система: Это то, что мы видим на платформе смарт-контрактов, полностью синхронизированной, такой как Solana или платформы, смело развертываемые только на уровне Layer1 ETH. Все данные приложений хранятся в блокчейне и легко доступны для всех других приложений. Это программируемое идеальное свойство, но не масштабируемое.
Несогласованная система：данные приложения хранятся вне Layer1 и в отдельных, изолированных Шардингах. Очень масштабируемая, но плохо сочетается в плане комбинирования. Примерами таких случаев являются модели Rollup в Полка и Ethereum.
JAM помимо предоставления вышеупомянутых двух функций также позволяет разработчикам публиковать любые данные на уровне JAM DA, что в определенной степени является промежуточной зоной между данными в блокчейне и данными вне блокчейна. Можно создавать новые приложения, использующие большинство данных приложений на уровне DA, одновременно сохраняя только абсолютно критические данные в состоянии JAM.
Приложение: График возможностей масштабирования
Эта часть переосмысливает наше видение области масштабируемости блокчейна. Это также объясняется в белой книге, здесь представлена более краткая версия.
Масштабируемость блокчейна во многом следует традиционным методам, используемым в распределенных системах: вертикальное масштабирование и горизонтальное масштабирование.
Масштабирование вверх - это работа, которую делают платформы, такие как Solana. Они производят экстремальную оптимизацию кода и аппаратуры для достижения максимальной пропускной способности.
Расширение внешней среды - это стратегия, применяемая в Ethereum и Polkadot для сокращения объема работы, который необходимо выполнить каждому участнику. В традиционных распределенных системах это достигается путем добавления большего количества копировальных устройств. В Блокчейне 'компьютер' представляет собой множество валидаторов всей сети. Путем распределения работы между ними (как это делается в ELVES) или оптимистическим уменьшением их обязанностей (как это делается в оптимистических роллапах), мы уменьшаем нагрузку на весь набор валидаторов, что обеспечивает расширение системы.
В блокчейне расширение аналогично «уменьшению количества машин, необходимых для выполнения всех операций».
Выводы следующие:
Расширение вверх: оптимизация высокопроизводительного оборудования + отдельной блокчейн.
На основе аналогии, предоставленной Робом Хабермайером в Sub02023, эта секция демонстрирует JAM как обновление для Polkadot: обновление ядра на том же аппаратном обеспечении. Подробнее см. Sub02023-YouTube.
В типичном компьютере мы можем разделить весь стек на три части:
Аппаратное обеспечение
ядро
Пользовательское пространство
В Полка, аппаратное обеспечение, то есть сущность, обеспечивающая вычисления и доступность данных, всегда было ядром (ядрами), как было сказано ранее.
В Polkadot ядро фактически[9]До сих пор было две части:
Парачейн (Parachains) Протокол: способ использования ядра визуализации и фиксации мнения.
Набор низкоуровневых функций, таких как Токен DOT и его передаваемость, застейкать, управление и т. д.
Оба из них присутствуют в ретрансляционном блокчейне (Relay Chain) Polkadot.
Приложения пользовательского пространства представляют собой примеры парачейн, их родные Токены и другие построенные над ними содержимое.
Мы можем визуализировать этот процесс следующим образом:
波卡 всегда предполагал передать больше основных функций своим пользователям типа парачейн. Именно это является целью Minimal Relay RFC. (Детали см.:)
Это означает, что центральная цепь Полка обрабатывает только Протокол парачейн, что в некоторой степени сокращает пространство ядра.
После реализации этой архитектуры визуализация процесса миграции JAM станет более простой. JAM значительно уменьшит ядро Polkadot, сделав его более универсальным. Кроме того, Протоколы Parachains перейдут в пользовательское пространство, поскольку это один из немногих способов написания приложений на одном и том же ядре (аппаратном обеспечении) и ядре (JAM).
Это также вновь подтверждает, почему JAM является только альтернативой ретрансляционной цепочке Polkadot, а не альтернативой парачейну.
Другими словами, мы можем рассматривать миграцию JAM как обновление ядра. Аппаратное обеспечение на нижнем уровне остается неизменным, большая часть старого ядра перемещается в пользовательское пространство для упрощения системы.
Хотите принять участие в обсуждении этой статьи? Добро пожаловать в форум, чтобы выразить свое мнение.
Ознакомьтесь с нашим руководством по использованию форума Polkadot, чтобы узнать, как принять участие в обсуждениях на форуме.
《Как участвовать в обсуждении Polkadot: Руководство по использованию официального форума Polkadot》
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
С технической точки зрения раскроем секреты JAM в Полка
Автор: Киан Паймани, основной разработчик Parity
Составитель: Polkadot Labs
«Базовый курс по Полкадоту» — это наша серия статей для новичков, которые пытаются объяснить основы Полкадота и предоставить всестороннее понимание этой платформы. Это огромная задача, полная вызовов, но мы надеемся, что благодаря этим усилиям люди смогут правильно понять Полкадот и быстро освоить связанные с ним знания. Сегодняшняя статья является 148-м выпуском этой рубрики, и в ней разработчик ядра Парити Киан Паймани технически рассматривает новый протокол JAM, предложенный для Полкадота, чтобы помочь людям лучше понять, как JAM может принести новые возможности масштабируемости в экосистему Полкадота. В этой статье автор пишет от первого лица.
*Ниже приведено подробное объяснение Polkadot1, Polkadot2 и того, как он превратился в JAM. Эта статья предназначена для технических читателей, особенно для тех, кто не очень хорошо знаком с Polkadot, но имеет некоторые знания о блокчейн-системах и, возможно, знаком с другими технологиями, связанными с экосистемой. *
Я считаю, что прочтение данной статьи является хорошей подготовкой перед прочтением JAM Белой книги. (Подробнее см.**)
Фоновые знания
Этот текст предполагает, что читатель знаком с следующими концепциями:
Введение: Polkadot1
Во-первых, давайте вспомним, что, по моему мнению, самой инновационной особенностью Polkadot1 является.
Социальный аспект:
Технический уровень:
Дополнительную информацию о "гетерогенном Шардинге" см. в соответствующих разделах.
Шардинг执行：核心要点
В настоящее время мы обсуждаем сеть уровня 1, которая управляет сетями уровня 2 «блокчейн» и аналогична Polkadot и Ethereum. Поэтому термины уровня 2 и параллельная цепочка (Parachain) могут использоваться взаимозаменяемо.
Основная проблема масштабируемости блокчейна заключается в том, что существует группа валидаторов, которые могут с помощью экономических механизмов Доказательства доли (Proof-of-Stake) обеспечить надежное выполнение определенного кода. По умолчанию эти валидаторы должны повторно выполнять всю работу друг друга. Поэтому, если мы заставим всех валидаторов постоянно повторно выполнять всю работу, вся система будет не масштабируемой.
Обратите внимание, что в этой модели увеличение количества валидаторов на самом деле не повышает пропускную способность системы, только если принцип абсолютной перезапускаемости выше неизмененной.
Выше показана одиночная Блокчейн (в отличие от ШардингБлокчейн). Все валидаторы сети будут по одному обрабатывать входные данные (т.е. Блок).
В такой системе, если Layer1 хочет управлять большим количеством Layer2, то все валидаторы теперь должны повторно выполнить все задачи Layer2. Очевидно, что такой подход не масштабируем. Оптимистичные роллапы - это один из способов избежать этой проблемы, поскольку повторное выполнение происходит только при заявлении о мошенничестве. Роллапы на основе SNARK обходят эту проблему, используя факт, что стоимость проверки SNARK-доказательства намного ниже, чем его генерация, и позволяют всем валидаторам проверить, что SNARK-доказательство является обоснованным. Дополнительную информацию об этом см. в «Приложение: Карта пространства масштабируемости».
Простым решением для Шардинга является разделение набора валидаторов на более мелкие подмножества и повторное выполнение Layer2 Блока этим более маленьким подмножеством. В чем проблема этого подхода? Мы разделяем выполнение и экономическую безопасность сети Шардингом. Безопасность Layer2 при этом ниже, чем у Layer1, и по мере того, как мы дальше разделяем набор валидаторов на большее количество Шардингов, безопасность будет еще ниже.
В отличие от Optimistic Rollups, которые не могут перезапустить выполнение себестоимости, Полка была разработана с учетом Шардинга, что позволяет некоторым валидаторам повторно выполнить блок Layer2, при этом обеспечивая достаточную криптографическую экономическую доказуемость всем участникам сети, что подтверждает безопасность этого блока Layer2, такая же безопасность как если бы его выполнял весь набор валидаторов. Это достигается с помощью нового (недавно официально выпущенного) механизма ELVES. (см. подробности: 01928374656574839201)
Вкратце, ELVES можно рассматривать как механизм "сомнительных роллапов". С помощью активного опроса валидаторами других валидаторов о том, является ли блок Layer2 действительным, мы можем с большой вероятностью подтвердить его действительность. Фактически, при возникновении любых споров требуется немедленное участие всего набора валидаторов. Сооснователь Polkadot Роб Хабермейер подробно объясняет это в своей статье. (Подробнее см. в:)
ELVES делает возможным одновременное присутствие двух ранее считавшихся взаимоисключающих свойств: «Шардинг выполнение» и «Общая безопасность». Это основной технический результат Polkadot1 в области масштабируемости.
Продолжим обсуждение аналогии с "CORE".
Блокчейн, выполняющий Шардинг, очень похож на ЦП: как ЦП может иметь несколько ядер для параллельного выполнения команд, так и Polkadot может параллельно обрабатывать блоки Layer2. Вот почему Layer2 на Polkadot называется парачейн, а среда, в которой более маленький подмножество валидаторов повторно выполняет отдельный блок Layer2, называется «CORE». Каждое ядро можно абстрагировать как «группу сотрудничающих валидаторов».
Вы можете представлять себе отдельную Блокчейн как потребляющую только один Блок в любой временной период, в то время как Полка потребляет один Релецепной блок и один параллельный блок каждого ядра в каждом временном периоде.
Гетерогенность
До сих пор мы обсуждали только масштабируемость и Шардинг, предоставляемый Полка. Следует отметить, что каждый Шардинг в Полка фактически представляет собой полностью разные приложения. Это достигается с использованием реализации Протокола в виде байтового кода: способ хранения Блокчейна в самом состоянии Блокчейна как байтового кода. В Polkadot 1.0 используется WASM в качестве предпочтительного байтового кода, в то время как в JAM используется PVM/RISC-V.
В общем, вот почему Полка называется гетерогенной фрагментированной блокчейном. (см. также: ) Каждый Layer2 - это совершенно отдельное приложение.
Полкадот2
Важной частью Polkadot2 является более гибкое использование основы. В оригинальной модели Polkadot срок аренды основы может варьироваться от 6 месяцев до 2 лет, что подходит для ресурсных предприятий, но не очень подходит для малых команд. Особенностью Polkadot, позволяющей использовать основу более гибко, является «гибкое ядро времени» (agile coretime). В этом режиме срок аренды основы Polkadot может быть как коротким, как один Блок, так и длинным, как один месяц, обеспечивая пользователей, желающих долгосрочную аренду, гарантированным верхним пределом цены.
Другие особенности Polkadot 2 постепенно проявляются в процессе нашего обсуждения, поэтому здесь не нужно слишком много излишеств.
Внутренние операции ядра и в блокчейне
Для понимания JAM сначала нужно понять, что происходит, когда блок Layer2 попадает в ядро Полка.
Следующее содержание было значительно упрощено.
Взглянем на это еще раз: ядро состоит главным образом из группы валидаторов. Поэтому, когда мы говорим "данные отправляются в ядро", на самом деле мы имеем в виду, что эти данные передаются этой группе валидаторов.
Один Layer2 Блок вместе с частью состояния этого Layer2 отправляется в ядро. Эти данные содержат всю необходимую информацию для выполнения этого Layer2 Блок.
Часть проверяющих в ядре повторно выполнит блок Layer2 и продолжит обрабатывать задачи, связанные с Соглашение.
Ядерные валидаторы будут повторно предоставлять необходимые данные другим валидаторам (внешним ядерным валидаторам). Другие валидаторы могут решить повторно выполнить этот Layer2 блок в соответствии с правилами ELVES и им потребуются эти данные для выполнения этой операции.
Обратите внимание, до сих пор все операции происходят вне главного блока и функции изменения состояния Полка. Все происходит внутри ядра и на уровне доступности данных.
Из вышеизложенного мы можем обсудить некоторые действия, которые выполняет Polkadot:
Во-первых, из шага 1 мы можем заключить, что в Полка существует новый способ выполнения, отличный от традиционной функции перехода состояний блокчейна. Обычно, когда все валидаторы в сети выполняют определенную работу, состояние основной цепи блоков обновляется. Мы называем это в блокчейне операцией (on-chain operation), именно это происходит на шаге 3. Однако внутри ядра (шаг 1) происходит что-то отличное. Мы называем этот новый тип вычислений блокчейна in-core ution.
Далее, из пункта 2 мы можем сделать вывод, что Polkadot уже предоставил собой нативный уровень доступности данных (Data-Availability, в дальнейшем - DA), и Layer2 автоматически использует его, чтобы гарантировать доступность своих доказательств в течение определенного времени. Однако данные блоки, которые могут быть размещены на этом уровне DA, являются фиксированными и всегда являются доказательством, необходимым для повторного выполнения Блока Layer2. Кроме того, код парачейна никогда не читает данные с уровня DA.
Понимание вышеупомянутого содержания является основой понимания JAM. Выводы следующие:
In-core ution: относится к операциям, происходящим внутри ядра. Он характеризуется богатством, масштабируемостью и обеспечивает ту же безопасность, что и ончейн-исполнение, благодаря криптоэкономике и ELVES.
ДЖЕМ
Имея понимание предыдущей части, мы можем легко перейти к представлению JAM.
JAM - это новый Протокол, разработанный под влиянием Polkadot и полностью совместимый с ним, который призван заменить ретрансляционную цепочку Polkadot и сделать основное использование полностью децентрализованным и без ограничений.
JAM построен на основе Polkadot2 в попытке сделать ядро Polkadot более доступным, но более гибким и без фиксированных ограничений по сравнению с agile-coretime.
Это достигается в основном путем выявления перед основными концепциями, обсуждаемыми в начале, три основных первоначальных концепции: выполнение на цепочке, выполнение в ядре и уровень DA.
Иными словами, в JAM разработчики могут получить доступ к:
Это базовое описание целей JAM. Не нужно много слов, здесь сделано много упрощений, и протокол возможно еще будет развиваться.
Имея это базовое понимание, мы теперь можем продолжить и более подробно рассмотреть некоторые детали JAM в следующих разделах.
1 Услуги и рабочие элементы
На фоне JAM, то, что ранее называлось Layer2/парачейн, теперь называется "сервис", то, что ранее называлось Блок/транзакция, теперь называется "рабочий элемент" или "рабочий пакет". Конкретно, рабочий элемент принадлежит определенному сервису, а рабочий пакет является совокупностью рабочих элементов. Эти термины были специально разработаны достаточно универсальными, чтобы охватывать различные случаи использования, превышающие блокчейн/Layer2.
Одна служба описывается тремя точками входа, из которых две - это fn refine() и fn accumulate(). Первая описывает содержимое, выполняемое службой в ядре, а вторая - содержимое, выполняемое службой в блокчейне.
Наконец, именно поэтому Протокол называется JAM (Join Accumulate Machine) - это именно поэтому назван JAM (Join Accumulate Machine). Join означает fn refine(), когда все ядра Polkadot параллельно обрабатывают большой объем работы различных сервисов, этот этап называется Join. Данные проходят через этап фильтрации, после чего они переходят к следующему этапу. Accumulate означает, что все вышеперечисленные результаты накапливаются в основном состоянии JAM, то есть в части выполнения в блокчейне.
Рабочие элементы могут точно указывать, что они выполняют в ядре, в блокчейне, и указывать, как / если / откуда читать и записывать содержимое распределенного данных озера (Distributed Data Lake).
2 Полусогласованный
При просмотре имеющейся информации о XCM (язык парачейн-коммуникации, выбранный Полка), обратите внимание, что вся связь является асинхронной. (См. подробности: ) То есть после отправки сообщения нельзя ждать ответа.
Асинхронность является проявлением несогласованности системы и основным недостатком постоянной Шардинг-системы (например, экосистемы Layer2 для существующих блокчейнов Polkadot 1 и Polkadot 2, а также Ethereum).
Однако, как описано в разделе 2.4 белой бумаги, полностью согласованная система, которая всегда синхронизирована со всеми своими арендаторами, может достичь определенного уровня только без ущерба для универсальности, доступности или гибкости. (Подробнее см.: )
Синхронизация≈Согласованность||Асинхронный≈Несогласованность
Это также еще одна область, в которой JAM выделяется: путем введения различных особенностей JAM достигает нового промежуточного состояния, а именно полусогласованной системы. В этой системе подсистемы с частой связью имеют возможность создавать согласованную среду между собой, не требуя обязательного поддержания согласованности всей системы. Это лучше всего описано в интервью доктора Гавина Вуда, автора Серого книги: (см. подробности: _referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ)
Другой способ понимания - рассматривать Polkadot/JAM как систему Шардинга, где границы этих Шардингов являются подвижными и динамически определяются.
Полка всегда была Шардингом и полностью гетерогенной.
Сейчас это будет Шардингом, гетерогенным, и границы этих Шардингов могут быть гибко определены, как и в «полуконсистентной» системе, о которой Гавин Вуд говорит в Твиттере. (Подробнее см. в: _src=twsrc%5Etfw, )
Особенности, которые делают все это возможным, включают в себя:
Доступ к безсостоятельному, параллельному выполнению ядра, где различные службы могут синхронно взаимодействовать только с другими службами в том же ядре и в определенном Блоке, и выполнению в блокчейне, где службы могут получать доступ ко всем результатам служб по всем ядрам.
JAM не принуждает к выполнению какого-либо конкретного расписания обслуживания. Службы с частым обменом данными могут получать экономические стимулы от своих планировщиков, создавая пакеты работ, включающие эти службы с частым обменом данными. Это позволяет этим службам работать на одном и том же ядре, и их взаимодействие друг с другом происходит так, как будто они находятся в синхронной среде.
Кроме того, JAM сервис может получить доступ к уровню данных (DA) и использовать его в качестве временного, но крайне дешевого уровня данных. Как только данные помещаются в DA, они в конечном итоге распространяются на все ядра, но становятся доступными немедленно внутри одного и того же ядра. Таким образом, JAM сервис может путем планирования себя в одно ядро в последовательном Блоке получить более высокий уровень доступа к данным.
Важно отметить, что, хотя вышеуказанное содержание возможно в JAM, оно не обязательно применяется на уровне протокола. Поэтому ожидается, что некоторые интерфейсы теоретически будут работать асинхронно, но благодаря умным абстракциям и мотивационным мерам они могут проявляться синхронно на практике. Следующая часть будет рассматривать CorePlay как пример такой ситуации.
3 CorePlay
Этот раздел описывает CorePlay, это экспериментальная идея в среде JAM, которую можно описать как новую модель программирования смарт-контрактов. На момент написания этой статьи CorePlay еще не был подробно описан и остается только концепцией.
Для понимания CorePlay сначала нужно ознакомиться с выбранной Виртуальной машины JAM: PVM.
4 PVM
PVM - это важная деталь в JAM и CorePlay. Низкоуровневые детали PVM выходят за рамки этой статьи, лучше всего ознакомиться с описанием экспертов в белой книге. Однако для целей этой статьи достаточно описать несколько свойств PVM:
Последнее особенно важно для CorePlay.
CorePlay - это пример синхронной и масштабируемой среды смарт-контрактов, созданной с использованием гибкого языка JAM, с очень гибким программным интерфейсом. CorePlay рекомендует развертывать смарт-контракты на основе акторов непосредственно на ядре JAM, чтобы они могли использовать синхронный интерфейс программирования, в котором можно писать код, как в обычной функции fn main(), и обмениваться данными через let_result=other_coreplay_actor(data).await?. Если other_coreplay_actor находится на том же ядре JAM в том же блоке, этот вызов будет синхронным; если на другом ядре, актор будет приостановлен и восстановлен в последующем блоке JAM. Это возможно благодаря сервису JAM и его гибкому планированию, а также свойствам PVM.
5 CoreChains услуги
Наконец, давайте подведем итоги основной причины, по которой JAM полностью совместим с Polkadot. Основной продукт Polkadot - это парачейны, работающие в агильном ядре времени, и этот продукт продолжается в JAM.
Вероятно, самые ранние развернутые службы в JAM будут называться CoreChains или Parachains. Этот сервис позволит существующим парачейнам в стиле Polkadot-2 работать на JAM.
Дополнительный сервис можно развернуть на JAM, и существующие сервисы CoreChains могут взаимодействовать с ними, но существующие продукты Polkadot останутся сильными и откроют новые двери только для существующих команд Parachain.
Приложение: данныеШардинг
Большая часть этой статьи рассматривает масштабируемость с точки зрения реализации Шардинга. Мы также можем рассмотреть эту же проблему с точки зрения данных. Интересно, что мы обнаружили, что это аналогично рассмотренной ранее ситуации с полуконсистентностью: в принципе, полностью консистентная система лучше, но не масштабируется; полностью несогласованная система масштабируется, но не идеальна, в то время как JAM, предложив свою модель полуконсистентности, представил новую возможность.
Полностью согласованная система: Это то, что мы видим на платформе смарт-контрактов, полностью синхронизированной, такой как Solana или платформы, смело развертываемые только на уровне Layer1 ETH. Все данные приложений хранятся в блокчейне и легко доступны для всех других приложений. Это программируемое идеальное свойство, но не масштабируемое.
Несогласованная система：данные приложения хранятся вне Layer1 и в отдельных, изолированных Шардингах. Очень масштабируемая, но плохо сочетается в плане комбинирования. Примерами таких случаев являются модели Rollup в Полка и Ethereum.
JAM помимо предоставления вышеупомянутых двух функций также позволяет разработчикам публиковать любые данные на уровне JAM DA, что в определенной степени является промежуточной зоной между данными в блокчейне и данными вне блокчейна. Можно создавать новые приложения, использующие большинство данных приложений на уровне DA, одновременно сохраняя только абсолютно критические данные в состоянии JAM.
Приложение: График возможностей масштабирования
Эта часть переосмысливает наше видение области масштабируемости блокчейна. Это также объясняется в белой книге, здесь представлена более краткая версия.
Масштабируемость блокчейна во многом следует традиционным методам, используемым в распределенных системах: вертикальное масштабирование и горизонтальное масштабирование.
Масштабирование вверх - это работа, которую делают платформы, такие как Solana. Они производят экстремальную оптимизацию кода и аппаратуры для достижения максимальной пропускной способности.
Расширение внешней среды - это стратегия, применяемая в Ethereum и Polkadot для сокращения объема работы, который необходимо выполнить каждому участнику. В традиционных распределенных системах это достигается путем добавления большего количества копировальных устройств. В Блокчейне 'компьютер' представляет собой множество валидаторов всей сети. Путем распределения работы между ними (как это делается в ELVES) или оптимистическим уменьшением их обязанностей (как это делается в оптимистических роллапах), мы уменьшаем нагрузку на весь набор валидаторов, что обеспечивает расширение системы.
В блокчейне расширение аналогично «уменьшению количества машин, необходимых для выполнения всех операций».
Выводы следующие:
Приложение: Тот же аппарат, обновление ядра
На основе аналогии, предоставленной Робом Хабермайером в Sub02023, эта секция демонстрирует JAM как обновление для Polkadot: обновление ядра на том же аппаратном обеспечении. Подробнее см. Sub02023-YouTube.
В типичном компьютере мы можем разделить весь стек на три части:
Аппаратное обеспечение
ядро
Пользовательское пространство
В Полка, аппаратное обеспечение, то есть сущность, обеспечивающая вычисления и доступность данных, всегда было ядром (ядрами), как было сказано ранее.
В Polkadot ядро фактически[9]До сих пор было две части:
Парачейн (Parachains) Протокол: способ использования ядра визуализации и фиксации мнения.
Набор низкоуровневых функций, таких как Токен DOT и его передаваемость, застейкать, управление и т. д.
Оба из них присутствуют в ретрансляционном блокчейне (Relay Chain) Polkadot.
Приложения пользовательского пространства представляют собой примеры парачейн, их родные Токены и другие построенные над ними содержимое.
Мы можем визуализировать этот процесс следующим образом:
波卡 всегда предполагал передать больше основных функций своим пользователям типа парачейн. Именно это является целью Minimal Relay RFC. (Детали см.:)
Это означает, что центральная цепь Полка обрабатывает только Протокол парачейн, что в некоторой степени сокращает пространство ядра.
После реализации этой архитектуры визуализация процесса миграции JAM станет более простой. JAM значительно уменьшит ядро Polkadot, сделав его более универсальным. Кроме того, Протоколы Parachains перейдут в пользовательское пространство, поскольку это один из немногих способов написания приложений на одном и том же ядре (аппаратном обеспечении) и ядре (JAM).
Это также вновь подтверждает, почему JAM является только альтернативой ретрансляционной цепочке Polkadot, а не альтернативой парачейну.
Другими словами, мы можем рассматривать миграцию JAM как обновление ядра. Аппаратное обеспечение на нижнем уровне остается неизменным, большая часть старого ядра перемещается в пользовательское пространство для упрощения системы.
Хотите принять участие в обсуждении этой статьи? Добро пожаловать в форум, чтобы выразить свое мнение.
Ознакомьтесь с нашим руководством по использованию форума Polkadot, чтобы узнать, как принять участие в обсуждениях на форуме.
《Как участвовать в обсуждении Polkadot: Руководство по использованию официального форума Polkadot》