Нижче наведено детальне пояснення 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). Мережа реалізує повністю ланцюжкове, самовиконуюче управління, включаючи оновлення рантайму без відгалужень.
• Комісія з цінних паперів та бірж визнала 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. Для отримання докладнішої інформації див. "Додаток: Діаграма простору масштабовності."

Простим рішенням для розділення є розділення набору перевіряючих на менші підмножини та повторний виконання блоків Layer2 цих менших підмножин. Які проблеми з таким підходом? По суті, ми розділяємо як виконання, так і економічну безпеку мережі. Таке рішення Layer2 має меншу безпеку порівняно з Layer1, і його безпека подальше зменшується, коли ми ділимо набір перевіряючих на більше кущів.

На відміну від оптимістичних ролапів, де витрати на повторне виконання не завжди можна уникнути, Polkadot був спроектований з урахуванням розділеного виконання. Це дозволяє частині валідаторів повторно виконувати блоки рівня 2, надаючи достатньо криптекономічних доказів всій мережі, щоб довести, що блок рівня 2 є таким же безпечним, якщо б повний набір валідаторів повторно виконав його. Це досягається за допомогою новаторського (і недавно формалізованого) механізму, відомого як ELVES. (Докладніше див.:https://eprint.iacr.org/2024/961)

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

Ельфи дозволяють Polkadot мати як розділене виконання, так і спільну безпеку, дві властивості, які раніше вважалися взаємовиключними. Це є основним технічним досягненням Polkadot1 у питанні масштабованості.

Тепер давайте рухатися вперед з аналогією "Ядро". Розшарене блокчейн-виконання схоже на ЦП: так само, як ЦП може мати кілька ядер, що виконують інструкції паралельно, Polkadot може обробляти Layer 2 блоки паралельно. Тому Layer 2 на Polkadot називається парачейном, а середовище, де менші підмножини валідаторів повторно виконують один Layer 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 поступово розкриваються по мірі розвитку нашої дискусії, тому немає потреби докладніше розглядати їх тут.

Операції In-Core проти On-Chain

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

Нагадайте, що ядро складається головним чином з набору перевіряючих. Так що коли ми кажемо «дані відправлені до ядра», це означає, що дані передаються цьому набору перевіряючих.

1. Блок Layer 2 разом із частиною стану цього Layer 2 відправляється в ядро. Ці дані містять всю інформацію, необхідну для виконання блоку Layer 2.

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

3. Ці основні перевіряльники надають перевиконані дані іншим перевіряльникам поза основними. Згідно з правилами ELVES, ці перевіряльники можуть вирішити, чи потрібно перевиконати блок рівня 2, щоб зробити це.

Важливо зауважити, що дотепер всі ці операції відбуваються поза основним блоком Polkadot та функцією переходу до стану. Все відбувається у межах ядра та шару доступності даних.

1. Нарешті, невелика частина останнього стану шару 2 стає видимою на головному реле-ланцюгу Polkadot. На відміну від попередніх операцій, цей крок набагато дешевший, ніж повторне виконання блоку шару 2, і він впливає на головний стан Polkadot. Це видно в блоку Polkadot та виконується всіма перевіряючими Polkadot.

З цього ми можемо дослідити кілька ключових операцій, які виконує Polkadot:

• З кроку 1 ми можемо зробити висновок, що Polkadot ввів новий тип виконання, відмінний від традиційних функцій переходу стану блокчейну. Зазвичай, коли всі валідатори мережі виконують завдання, стан головного ланцюжка блокчейну оновлюється. Це те, що ми називаємовиконання на ланцюжку, і це те, що відбувається на етапі 3. Однак те, що відбувається всередині ядра (Етап 1), відрізняється. Ця нова форма обчислень у блокчейні відома як Внутрішнє виконання.
• З кроку 2 ми виводимо, що у Polkadot є власний Доступність даних (DA)шар і Layer 2 автоматично використовують його, щоб забезпечити доступність доказів свого виконання на певний період. Проте блоки даних, які можуть бути опубліковані на шар DA, фіксовані, містять лише докази, необхідні для повторного виконання Layer 2. Крім того, код паралелі не читає дані шару DA.

Розуміння цього становить основу для усвідомлення JAM. Ось краткий виклад:

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

JAM

З цим розумінням ми тепер можемо представити JAM.

JAM - це новий протокол, натхненний дизайном Polkadot, повністю сумісний з ним, що має на меті замінити реле-ланцюг Polkadot та зробити основне використання повністю децентралізованим та необмеженим.

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

• Polkadot 2 дозволяє розгортання рівня 2 на ядрі бути більш динамічним.
• JAM має на меті дозволити розгортання будь-якої програми на основі Polkadot, навіть якщо ці програми не мають структури блокчейнів або другого рівня.

Це досягається в основному шляхом викриття розробникам трьох основних концепцій, які обговорювалися раніше: виконання на ланцюжку, внутрішнє виконання та шар DA.

Іншими словами, в JAM розробники можуть:

• Повністю програмуйте як в ядрі, так і на ланцюжку завдань.
• Зчитування та запис до DA-шару Polkadot з довільними даними.

Це утворює основний огляд цілей JAM. Зрозуміло, що багато цього було спрощено, і протокол, ймовірно, буде далі розвиватися.

З цим базовим розумінням ми тепер можемо заглибитися в деякі конкретики JAM у наступних розділах.

Послуги та робочі елементи

У JAM тепер раніше називались Layer 2s або парачейни, тепер називаютьсяПослуги, і те, що раніше називали блоками або транзакціями, зараз називаютьсяРобочі елементиабоРобочі пакетиЗокрема, робочий елемент належить до сервісу, а робочий пакет - це колекція робочих елементів. Ці терміни спеціально широкі, щоб охопити випадки використання поза сценаріями блокчейну/Layer 2.

Службу описується трьома точками входу, дві з яких є fn refine() та fn accumulate(). Перше описує, що служба робить під час виконання в ядрі, а останнє описує, що вона робить під час виконання на ланцюжку.

Нарешті, назви цих точок входу є причиною, чому протокол називається JAM (Join Accumulate Machine).Приєднуйтесьвідноситься доfn refine(), яка є фазою, коли всі ядра Polkadot обробляють великий обсяг роботи паралельно в різних службах. Після обробки даних вони переходять до наступної стадії. Накопичувати refers to the process of accumulating all of these results into the main JAM state, which happens during the on-chain execution phase.

Робочі елементи можуть точно вказати код, який вони виконують в ядрі та на ланцюжку, а також те, як, чи, і звідки вони читають або записують вміст у Розподіленому Дата-озері.

Пів-консистентність

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

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

• Синхронний ≈ Послідовність || Асинхронний ≈ Неспівмірність

Ось де вирізняється 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 завжди був розсіяний та повністю гетерогенним.

Зараз він не лише розщеплений і гетерогенний, але ці межі розщеплення можуть бути гнучко визначені—так, як Гевін Вуд називає цю систему «напів-консистентною» у своїх твітах та Сірому папері. (див.: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), обрану Gate: PVM.

PVM

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

• Ефективне вимірювання
• Можливість призупинення та відновлення виконання

Останнє особливо важливо для CorePlay.

CorePlay є прикладом того, як гнучкі примітиви JAM можуть бути використані для створення синхронного та масштабованого середовища смарт-контрактів з дуже гнучким інтерфейсом програмування. CorePlay пропонує, щоб смарт-контракти на основі акторів розгорталися безпосередньо на ядрах JAM, що дозволяє їм отримувати вигоду від синхронних інтерфейсів програмування. Розробники можуть писати смарт-контракти так, ніби вони є простими функціями fn main(), використовуючи такі вирази, як let result = other_coreplay_actor(data).await?щоб спілкуватися. Якщоінший актор ядра гризнаходиться на тій же ядрі 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 відносяться до цієї категорії.

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

Додаток: Ландшафт масштабованості

Цей розділ переглядає нашу перспективу щодо масштабованості блокчейну, про яку також йдеться в Сірому папері, але тут вона представлена у більш стислій формі.

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

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

Горизонтальне масштабування — це стратегія, прийнята Ethereum і Polkadot: зменшення робочого навантаження, з яким повинен впоратися кожен учасник. У традиційних розподілених системах це досягається додаванням більшої кількості машин-реплік. У блокчейні «комп'ютер» – це вся мережа валідаторів. Розподіляючи завдання між ними (як це роблять ELVES) або оптимістично зменшуючи їхні обов'язки (як у Optimistic Rollups), ми зменшуємо навантаження на весь набір валідаторів, таким чином досягаючи горизонтального масштабування.

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

У підсумку:

1. Вертикальне масштабування: Високопродуктивний апаратний засіб + оптимізація монолітних блокчейнів.
2. Горизонтальне масштабування:
   • Оптимістичні Rollups
   • SNARK-розрахунки на основі Rollups
   • ELVES: Цинічні роллапи 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, роблячи його більш універсальним. Крім того, протокол Парачейнів переїде в простір користувача, оскільки це один з небагатьох способів будувати додатки на тому ж ядрі (апаратному забезпеченні) та ядрі (JAM).

Це також підтверджує, чому JAM є заміною для ланцюга ретрансляції Polkadot, а не для паралельних ланцюгів.

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

Відмова:

1. Ця стаття передрукована з [Інститут досліджень екологічного полотна], Усі авторські права належать оригінальному автору [Інститут досліджень екологічного середовища Polkadot]. Якщо є зауваження до цього повторення, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно займуться цим.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконуються командою вивчення Gate. Якщо не зазначено, копіювання, поширення або плагіат перекладених статей заборонено.