JAM после 2.0 — это ускоренная разработка, в которой участвует более 30 команд, использующих разные языки программирования и различные команды разработчиков для реализации децентрализованного клиента JAM (основанного на протоколе серого документа JAM). Первоначальный ETH требовал, чтобы все транзакции проверялись всеми валидаторами (эту часть можно посмотреть в желтой книге Ethereum, а также в более хорошем интерпретационном варианте). L2 позволяет выполнять вычисления на меньшем подмножестве вне цепи двумя способами: один из них — это доказательство мошенничества (при обнаружении мошенничества повторно выполняется код транзакции для проверки), другой — это zk-доказательство, которое не требует повторных вычислений, но требует более дорогих GPU для генерации доказательства, на цепи просто проверяется доказательство, без повторного выполнения кода функции преобразования предыдущей транзакции. Ранее @Polkadot 1.0 использовал алгоритм, называемый ELVES, который, в отличие от мошеннического алгоритма ETH, использует пассивную проверку, а применяет вероятностный алгоритм для активной проверки. В @polkadot 2.0 набор валидаторов уже был упакован в концепцию, называемую Core, которая по сути является подмножеством набора валидаторов. 2.0 поддерживает Agile Coretime, что означает динамическое использование core; в 1.0 одна цепь могла использовать только один Core, а в 2.0, после запуска, поддерживается Agile Coretime, что позволяет одной цепи динамически использовать coretime (количество валидирующих подмножеств) в зависимости от потребностей, тем самым увеличивая нагрузку на систему. Таким образом, JAM эволюционировал на основе этих идей, появилось множество zk, op, смарт-контрактов и даже обычных безстатусных приложений web2. Могут ли они быть дополнительно абстрагированы для лучшего соответствия различным моделям приложений и позволить им взаимодействовать друг с другом? Поэтому JAM сделал дальнейшую абстракцию на этой основе. - Различные L2/параллельные цепи теперь называются услугами. - Блоки/транзакции теперь называются рабочими элементами или рабочими пакетами. - Рабочие элементы принадлежат услугам, а рабочий пакет — это набор рабочих элементов. - Услуга описывается тремя точками входа, две из которых — fn refine() и fn accumulated. - Эти два названия точек входа и являются причиной, по которой этот протокол называется JAM: соединительная накопительная машина (Join Accumulate Machine). Соединение (Join) относится к fn refine(), все ядра Polkadot будут параллельно выполнять множество работ для различных услуг. Соединение означает извлечение данных в более мелкое подмножество, которое затем передается на следующий этап. - Накопление означает накопление результатов всех вышеупомянутых операций в основном состоянии JAM. - Поддерживаются различные формы услуг (op rollups, zkrollups, параллельные цепи, безстатусные приложения, смарт-контракты). Эпоха ETH — это общая состояние однопоточной машины. Эпоха @polkadot 1.0 — это взаимосвязываемая вероятностная шардовая машина. Эпоха @polkadot 2.0 — это машина Agile Coretime. Эпоха JAM — это Join Accumulate Machine (JAM). Есть много деталей и особенностей, здесь я только синхронизировал информацию, которую понял. Более глубокое понимание того, почему JAM может поддерживать работающие программы без необходимости инициировать их через транзакции, какие новые модели продуктов могут возникнуть в будущем в сочетании с DEFI? Почему JAM может выполнять нестатусные приложения, такие как JAM DOOM? Подробности смотрите в видео: Учебные материалы: