Kian Paimani, основний розробник Parity, технічно розкриває JAM протокол, щоб допомогти людям краще зрозуміти, як JAM може принести новий рівень масштабованості в екосистему Polkadot.
Автор: Кіан Паймані, розробник ядра Parity
Компіляція: Лабораторія Polkadot
"Паритетний основний розробник Кіан Паймані з технічного погляду роз'яснює новий протокол JAM Полка, щоб допомогти людям краще розуміти, як JAM принесе нові можливості для екосистеми Полка щодо масштабованості. Ця стаття написана від першої особи.
*Нижче наведено детальний опис Polkadot1, Polkadot2 та того, як вони еволюціонували в JAM. Ця стаття адресована технічним читачам, особливо тим, хто не дуже знайомий з Polkadot, але має деяке розуміння систем блокчейну та може бути знайомий з іншими технологіями, пов'язаними з екосистемою.
*Я вважаю, що перед читанням JAM Білої книги це дуже хороший прелюд. (Див. деталі: ***)
Знання фону
Даний текст передбачає, що читач знайомий з такими концепціями:
Описується як функція переходу стану Блокчейну.
Розуміння того, що таке "стан". (Докладніше див. _sdk_docs/reference_docs/blockchain_state_machines/index.html)
Економічна безпека та атестація стейкінгу. (Деталі див. )
Вступ: Polkadot1
Спочатку давайте згадаємо, що на мою думку, найбільш інноваційним аспектом в Polkadot1 є.
Соціальний аспект:
Полка - це велика Децентралізована автономна організація (DAO). Ця мережа реалізує повністю у блокчейні, реалізуючи самовиконуване управління, включаючи роботу без форків оновлення в часі виконання.
Комісія з цінних паперів і бірж (SEC) у США вважає DOT програмним забезпеченням, а не цінним папером. (Деталі див. в: )
Більшість робіт з розробки мережі виконується Polkadot Fellowship (детальніше див. у: 01928374656574839201), а не компанією, що фінансується такими компаніями, як Parity:.
Технічний рівень:
Polkadot реалізував спільну безпеку та виконання Шардингу.
Використовуючи протокол на основі WASM (див. деталі за посиланням: _sdk_docs/reference_docs/wasm_meta_protocol/index.html), код блокчейну зберігається у стані у вигляді байткоду. Це дозволяє багатьом оновленням працювати без форків і реалізувати фрагментування.
Для отримання додаткової інформації щодо «Гетерогенного Шардінгу» дивіться відповідний розділ.
Виконання Шардингу: Основні моменти
Наразі ми обговорюємо мережу Layer1, яка хостить інші мережі Layer2 "блокчейн", подібно до Polkadot та Ethereum. Таким чином, терміни Layer2 та Parachain можуть використовуватися взаємозамінно.
Основною проблемою масштабованості блокчейну є наявність групи валідаторів, які можуть забезпечити довіреність виконання певного коду за допомогою економічності Доказу стейкінгу (Proof-of-Stake) Crypto. За замовчуванням ці валідатори повинні повторно виконувати всю роботу один одного. Тому, якщо ми змушуємо всіх валідаторів постійно повторно виконувати все, система в цілому неможливо масштабувати.
Зверніть увагу, що збільшення кількості валідаторів в цій моделі насправді не підвищує пропускну здатність системи, якщо тільки вищезазначений абсолютний принцип повного перевиконання залишається незмінним.
Вище показано, що це єдиний блокчейн (у відміну від ШардингБлокчейн). Усі мережеві валідатори по черзі обробляють вхід (тобто Блок).
У такій системі, якщо Layer1 хоче господарювати більше Layer2, всі валідатори повинні перевиконати всю роботу Layer2. Очевидно, що цей підхід не масштабується. Оптимістичні Rollups - це один з способів уникнути цієї проблеми, оскільки перевиконання відбувається тільки тоді, коли хтось заявляє про шахрайство (доказ шахрайства). Rollups, засновані на SNARK, уникають цю проблему, використовуючи той факт, що вартість перевірки доказу SNARK набагато нижча, ніж його генерація, тому всі валідатори можуть перевірити його. Для отримання додаткової інформації зверніться до "Додаток: Графік простору масштабованості".
Простим рішенням для Шардинга є розбиття колекції валідаторів на менші підмножини і виконання Блоку Layer2 з цим меншим підмножинам. Яка проблема з таким підходом? Ми проводимо Шардинг виконання та економічної безпеки мережі. Безпека Layer2 такого методу менша, ніж Layer1, і з подальшим поділом колекції валідаторів на більше Шардингів, безпека додатково зменшується.
Наприклад, у відміну від Optimistic Rollups, які не можуть повністю перевиконати витрати на виконання, Polkadot розраховує на Шардинг в процесі проектування, що дозволяє частині валідаторів перевиконати Лейер2 Блок, надаючи при цьому достатньо криптографічних доказів економіки для всіх учасників мережі, що підтверджують безпеку цього Лейер2 Блоку та його повторне виконання всією групою валідаторів. Це досягається за допомогою новаторського механізму ELVES (що був недавно офіційно випущений). (Деталі див. в: )
Згадуючи, ELVES можна розглядати як механізм «підозрюваного роллапу». Шляхом активного запитування деяких валідаторів інших валідаторів щодо того, чи є дійсним певний блок Layer2, ми можемо з великою ймовірністю підтвердити його дійсність. Фактично, в разі будь-яких суперечок незабаром буде вимагатися участь всього набору валідаторів. Роб Хабермейєр, співзасновник Polkadot, ретельно пояснив це в одній зі статей. (Докладніше: )
ELVES дозволяє Polkadot мати одночасно дві властивості, які раніше вважалися взаємовиключними: "Шардинг виконання" та "спільна безпека". Це основний технічний результат Polkadot1 в плані масштабованості.
Зараз продовжимо розмову про аналогію класу "CORE".
Блокчейн, який виконує Шардинг, дуже схожий на процесор: як і у процесорі можуть бути декілька паралельних ядер, Полка може паралельно обробляти Блоки Layer2. Тому Layer2 на Полці називаються парачейном, а середовище, в якому відбувається повторне виконання окремого Блоку Layer2 малим підмножинами валідаторів, називається «ядерна (core)». Кожне ядро можна абстрагувати як «групу співпрацюючих валідаторів».
Ти можеш уявити собі одиночний Блокчейн як систему, що в будь-який момент часу приймає лише один Блок, тоді як Polkadot приймає Реле ланцюжок Блок і кожен паралельний ланцюжок ядра в кожний період часу.
Гетерогенність
До цього моменту ми обговорювали лише масштабованість та Шардинг, який надає Polkadot. Варто зазначити, що кожен Шардинг Polkadot насправді є повністю різним додатком. Це досягається за допомогою метапротоколу, який зберігається як байт-код на Блокчейні: протоколу, який визначає Блокчейн як байт-код, збережений у стані самого Блокчейну. У Polkadot 1.0 використовується WASM як пріоритетний байт-код, а в JAM використовується PVM/RISC-V.
Загалом, ось чому Polkadot називається гетерогенною фрагментаційною блокчейн-платформою. (Докладніше див. на: ) Кожен шар 2 є окремою програмою.
Polkadot2
Важливою частиною Polkadot2 є зробити використання основи більш гнучким. У первісній моделі Polkadot термін дії основи може становити від 6 місяців до 2 років, що підходить для компаній з ресурсами, але не дуже підходить для малих команд. Функція Polkadot, яка дозволяє більш гнучкий термін дії основи, називається «агільний час основи» (agile coretime) (див. деталі:). У цьому режимі термін дії основи Polkadot може бути скорочений до одного Блоку або тривати до одного місяця і забезпечувати гарантію максимальної ціни для користувачів, які хочуть довгостроково орендувати.
Інші функції Polkadot 2 поступово проявлятимуться під час обговорення, тому тут не потрібно занадто детально описувати.
Операції ядра внутрішньої системи та у блокчейні
Для того щоб зрозуміти JAM, спочатку потрібно зрозуміти, що відбувається, коли Блок Layer2 входить в основу Полоцьк.
Нижче наведено значну спрощену версію.
Підсумовуючи, ядро в основному складається з групи валідаторів. Таким чином, коли ми кажемо “дані відправлені в ядро”, ми насправді маємо на увазі, що ці дані передані цій групі валідаторів.
Один блок Layer2 разом із частиною стану цього Layer2 надсилається до ядра. Ці дані містять усю необхідну інформацію для виконання цього блоку Layer2.
1.Частина валідаторів у ядрі виконає перевиконання блоку Layer2 Блок та продовжить обробку завдань, пов'язаних з Консенсус .
Ядро валідаторів знову виконає необхідні дані для інших валідаторів (зовнішніх валідаторів ядра). Інші валідатори можуть вирішити знову виконати цей блок Layer2 згідно правил ELVES, і вони потребують ці дані для виконання цієї операції.
Зверніть увагу, до цього моменту всі операції відбувалися поза основним блоком Polkadot та функцією зміни стану. Усе це відбувається всередині ядра та на рівні доступності даних.
Нарешті, невелика частина останнього стану Layer2 буде видима на головному релеційному ланцюжку Polkadot. На відміну від усіх попередніх дій, ця операція відбувається набагато дешевше, ніж фактичне повторне виконання Блоку Layer2, вона впливає на головний стан Polkadot, видимий у Блоку Polkadot та виконується всіма валідаторами Polkadot.
З вищезазначеного ми можемо розглянути деякі дії, які виконує Polkadot:
Спочатку, з кроку 1, ми можемо зрозуміти, що в Polkadot існує новий спосіб виконання, відмінний від традиційної функції переходу стану блокчейну. Зазвичай, коли всі валідатори в мережі виконують певну роботу, стан основного блокчейну оновлюється. Ми називаємо цю ситуацію у блокчейні операцією (on-chain operation), це те, що відбувається на кроці 3. Однак, внутрішній процес, який відбувається в ядрі (крок 1), є іншим. Ми називаємо цей новий тип обчислення блокчейну ядром (in-core ution).
Далі, з пункту 2 ми можемо зробити висновок, що Polkadot вже надає вбудовану можливість доступності даних (DA) та Layer2 автоматично використовує її, щоб забезпечити доступність свідоцтв про виконання протягом певного часу. Однак дані блоків, які можуть бути розміщені в цьому DA шарі, є фіксовані та завжди є свідоцтвами, які потрібні для виконання Layer2 Блоку. Крім того, код парачейна ніколи не читає дані з DA шару.
Розуміння вищезазначеного є основою розуміння JAM. Загальний підсумок такий:
Виконання у ядрі (in-core ution): це означає операції, що відбуваються всередині ядра. Вони є багатими, масштабованими та забезпечені такою ж безпекою, як у виконанні в у блокчейні, завдяки криптовалютній економіці та ELVES.
Виконання на блокчейні (on-chain execution): вказує на операції, які виконують всі валідатори. Валідатори, які отримують безпеку за рахунок економічних гарантій, за замовчуванням мають більш високі витрати і обмеження, оскільки всі виконують всі операції.
Доступність даних (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). Join означає fn refine(), коли всі ядра Polkadot паралельно обробляють великий обсяг роботи різних служб, цю фазу називають Join. Після фільтрації дані переходять до наступної фази. Accumulate означає процес накопичення всіх вищезазначених результатів в основний стан JAM, тобто частину, що виконується у блокчейні.
Робочі елементи можуть точно вказувати, який код вони виконують у ядрі, у блокчейні та як вони читають / записують вміст розподіленого дата-озера (Distributed Data Lake) звідки / як / чи взагалі.
2 Півсумісність
При перегляді наявної інформації про XCM (мову парачейну, обрану для Полкавалето), всі комунікації є асинхронними. (Докладніше див. :) Це означає, що після відправки повідомлення неможливо очікувати його відповіді.
Асинхронність є проявом непослідовності системи, основним недоліком постійної системи Шардингу (наприклад, екосистеми Layer2 для Polkadot 1 і Polkadot 2, а також існуючої екосистеми Ethereum).
Однак, як описано в розділі 2.4 Сірої книги, повністю консистентна система, яка завжди синхронізується для всіх своїх орендарів, може досягти певного рівня зростання, лише якщо не жертвує загальнодоступністю, доступністю або еластичністю. (Детальніше:)
Це також є ще одна сфера, в якій JAM виділяється: шляхом введення різноманітних функцій JAM реалізує новий проміжний стан, тобто систему напів-консистентності. У цій системі підсистеми, що часто взаємодіють, мають можливість створювати консистентне середовище одна для одної, не зобов'язуючи весь систему до підтримки консистентності. Це найкраще описано в інтерв'ю з автором Сірим Дровом (Gavin Wood): (див. деталі: _referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ)
Ще одним способом розуміння Polkadot/JAM є система Шардингу, де межі цих Шардінгів є рухомими і динамічно визначаються.
Полка завжди була Шардингом і повністю гетерогенною.
Зараз він буде розділений на Шардинг, гетерогенний, при цьому границі цих Шардингів можуть бути гнучко визначені, як сказав Ґевін Вуд у своєму твіттері про систему «півконсенсусу» (див. деталі: _src=twsrc%5Etfw).
Функції, які зробили це все можливим, включають:
Доступ до безстатевого, паралельного виконання ядра, де різні служби можуть взаємодіяти лише синхронно з іншими службами в тому ж ядрі, але в певному блоку, а також виконання у блокчейні, де служби можуть отримувати доступ до результатів всіх служб на всіх ядрах.
2.JAM не накладає обов'язкового виконання будь-якого конкретного розкладу обслуговування. Служби, які часто зв'язуються, можуть надавати економічні стимули своїм сортувальникам, створюючи пакети робіт, які містять ці служби, що часто зв'язуються. Це дозволяє цим службам працювати в одному ядрі, а комунікація між ними відбувається, наче в синхронному середовищі.
Крім того, послуга JAM може отримати доступ до рівня даних та використовувати його як тимчасове, але дуже економне Рівень даних. Як тільки дані розміщені в 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 є парачейни (Parachains), які працюють за принципом гнучкого осередку часу, і цей продукт продовжується в JAM.
Найбільш ранні послуги, що розгортається в JAM, можуть називатися CoreChains або Parachains. Ця служба дозволить існуючим парашейнам у стилі Polkadot-2 працювати на JAM.
Додаткові послуги можна розгорнути на JAM, і існуючі служби CoreChains можуть взаємодіяти з ними, але існуючі продукти Polkadot залишаться міцними і лише відкриють нові двері для існуючих команд Parachain.
Додаток: Шардинг даних
Більшість цього тексту досліджує масштабованість з точки зору виконання Шардинга. Ми також можемо розглянути цю ж проблему з точки зору даних. Цікаво, що ми виявили, що це схоже на раніше згаданий випадок напів-консистентності: в принципі, повністю консистентна система краще, але неможливо масштабувати; повністю не консистентна система може масштабуватися, але не є ідеальною, тоді як JAM з його моделлю напів-консистентності вносить нову можливість.
Система повної відповідності: Це те, що ми бачимо на платформі смарт-контрактів, повністю синхронізованій, такі як Solana, або на тих, що сміливо розгортаються лише на рівні Layer1 ETH блокчейну. Усі дані додатків зберігаються у блокчейні та легко доступні для всіх інших додатків. Це програмована властивість, але не масштабована.
Несумісна система: додаткові дані зберігаються поза Layer1 і в різних, ізольованих Шардинг. Дуже масштабована, але показує погану комбінативність. Модель Rollup для Polkadot та Ethereum відноситься до цього випадку.
JAM крім надання вищезазначених функцій, також дозволяє розробникам публікувати будь-які дані на рівень JAM DA, що в певній мірі є проміжною зоною між у блокчейні дані та поза блокчейном. Можна створювати нові застосунки, які використовують більшість даних застосунків на рівні DA, при цьому лише важливі дані зберігаються в стані JAM.
Додаток: Діаграма простору масштабованості
Цей розділ переінтерпретує наші погляди на скальність в галузі блокчейну. Це також пояснено в сірій книзі, тут наведено більш стислу версію.
Масштабованість блокчейну в значній мірі дотримується методів, що використовуються у традиційних розподілених системах: вертикального та горизонтального масштабування.
Розширення вгору - це робота, яку робить платформа, подібна до Solana. Шляхом максимальної оптимізації коду та обладнання досягається максимальна пропускна здатність.
Масштабування — це стратегія, яку використовують Ethereum і Polkadot: зменшити обсяг роботи, яку потрібно виконати для всіх. У традиційній розподіленій системі це досягається додаванням більшої кількості реплікаційних машин. У ланцюжку Блок «комп'ютер» - це сукупність валідаторів всієї мережі. Розподіливши роботу між ними (як це роблять ELVES), або оптимістично скоротивши їхні обов'язки (як це оптимально роблять Rollups), ми зменшили навантаження на всю валідаторну колекцію, дозволивши системі масштабуватися.
У блокчейні розширення схоже на «зменшення кількості машин, які потрібно виконати всі операції».
Підсумовуючи:
Розширення вгору: високопродуктивне обладнання + оптимізація одноблочного ланцюга.
Розширення зовнішнього світу:
Оптимістичні роллапи
Роллапи на основі SNARK
ELVES: цинічні роллапи Поки (Cynical Rollups)
Додаток: Оновлення ядра на тому самому обладнанні
Цей розділ, заснований на аналозі, який запропонував Роб Хабермейєр у Sub02023: Поле для користувача/ядра Поле для користувача/ядра|Sub02023-YouTube (див. деталі за посиланням:), демонструє JAM як оновлення для Поле для користувача/ядра на тій самій апаратурі.
У типовому комп'ютері ми можемо розділити весь стек на три частини:
апаратне забезпечення
ядро
Простір користувача
У Полоці апаратне забезпечення, яке завжди було основним (як було сказано вище), є суттєвим для надання обчислень та доступності даних.
У Polkadot ядро насправді[9]До цього моменту було включено дві частини:
1.парачейн（парачейни）протокол：один спосіб узгодження, фіксоване використання ядра.
Група низькорівневих функцій, таких як DOT Токен та його переносність, застейкати, управління тощо.
Ці обидва існують в релейному ланцюзі (Relay Chain) Полка.
Додатки простору користувача - це приклади парачейнів, їхні власні Токени та інші вміст, що будується на них.
Ми можемо візуалізувати цей процес наступним чином:
Полка завжди уявляла, що більше основних функцій буде перенесено до свого унікального користувача - парачейн. Це саме те, що має на меті досягти Minimal Relay RFC. (Деталі див. в: )
Це означає, що мережа Polkadot обробляє лише протокол парачейну, що деяким чином зменшує простір ядра.
Як тільки ця архітектура буде реалізована, буде набагато простіше візуалізувати, як виглядатиме міграція JAM. JAM суттєво зменшить простір ядра Polkadot, зробивши його більш універсальним. Крім того, протоколи Parachains будуть переміщені в простір користувача, оскільки це один з небагатьох способів написання додатків на тому ж ядрі (апаратному забезпеченні) та ядрі (JAM).
Це також ще раз підтверджує, чому JAM є лише альтернативою для релейної ланки Polkadot, а не альтернативою для парачейну.
Іншими словами, ми можемо розглядати міграцію JAM як оновлення ядра. Основне обладнання залишається незмінним, а більшість старого ядра переміщується у простір користувача для спрощення системи.
Щоб приєднатися до обговорення цієї статті, заохочуємо висловити свою думку на форумі:
Щодо участі в обговоренні на форумі, будь ласка, див. Наш посібник з використання форуму Polkadot, який ми випустили:
《Як брати участь у дискусіях про Polkadot: Посібник користувача офіційного форуму Polkadot》
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Розкриття JAM Полка з технічної точки зору
Автор: Кіан Паймані, розробник ядра Parity
Компіляція: Лабораторія Polkadot
"Паритетний основний розробник Кіан Паймані з технічного погляду роз'яснює новий протокол JAM Полка, щоб допомогти людям краще розуміти, як JAM принесе нові можливості для екосистеми Полка щодо масштабованості. Ця стаття написана від першої особи.
*Нижче наведено детальний опис Polkadot1, Polkadot2 та того, як вони еволюціонували в JAM. Ця стаття адресована технічним читачам, особливо тим, хто не дуже знайомий з Polkadot, але має деяке розуміння систем блокчейну та може бути знайомий з іншими технологіями, пов'язаними з екосистемою.
*Я вважаю, що перед читанням JAM Білої книги це дуже хороший прелюд. (Див. деталі: ***)
Знання фону
Даний текст передбачає, що читач знайомий з такими концепціями:
Вступ: Polkadot1
Спочатку давайте згадаємо, що на мою думку, найбільш інноваційним аспектом в Polkadot1 є.
Соціальний аспект:
Технічний рівень:
Для отримання додаткової інформації щодо «Гетерогенного Шардінгу» дивіться відповідний розділ.
Виконання Шардингу: Основні моменти
Наразі ми обговорюємо мережу Layer1, яка хостить інші мережі Layer2 "блокчейн", подібно до Polkadot та Ethereum. Таким чином, терміни Layer2 та Parachain можуть використовуватися взаємозамінно.
Основною проблемою масштабованості блокчейну є наявність групи валідаторів, які можуть забезпечити довіреність виконання певного коду за допомогою економічності Доказу стейкінгу (Proof-of-Stake) Crypto. За замовчуванням ці валідатори повинні повторно виконувати всю роботу один одного. Тому, якщо ми змушуємо всіх валідаторів постійно повторно виконувати все, система в цілому неможливо масштабувати.
Зверніть увагу, що збільшення кількості валідаторів в цій моделі насправді не підвищує пропускну здатність системи, якщо тільки вищезазначений абсолютний принцип повного перевиконання залишається незмінним.
Вище показано, що це єдиний блокчейн (у відміну від ШардингБлокчейн). Усі мережеві валідатори по черзі обробляють вхід (тобто Блок).
У такій системі, якщо Layer1 хоче господарювати більше Layer2, всі валідатори повинні перевиконати всю роботу Layer2. Очевидно, що цей підхід не масштабується. Оптимістичні Rollups - це один з способів уникнути цієї проблеми, оскільки перевиконання відбувається тільки тоді, коли хтось заявляє про шахрайство (доказ шахрайства). Rollups, засновані на SNARK, уникають цю проблему, використовуючи той факт, що вартість перевірки доказу SNARK набагато нижча, ніж його генерація, тому всі валідатори можуть перевірити його. Для отримання додаткової інформації зверніться до "Додаток: Графік простору масштабованості".
Простим рішенням для Шардинга є розбиття колекції валідаторів на менші підмножини і виконання Блоку Layer2 з цим меншим підмножинам. Яка проблема з таким підходом? Ми проводимо Шардинг виконання та економічної безпеки мережі. Безпека Layer2 такого методу менша, ніж Layer1, і з подальшим поділом колекції валідаторів на більше Шардингів, безпека додатково зменшується.
Наприклад, у відміну від Optimistic Rollups, які не можуть повністю перевиконати витрати на виконання, Polkadot розраховує на Шардинг в процесі проектування, що дозволяє частині валідаторів перевиконати Лейер2 Блок, надаючи при цьому достатньо криптографічних доказів економіки для всіх учасників мережі, що підтверджують безпеку цього Лейер2 Блоку та його повторне виконання всією групою валідаторів. Це досягається за допомогою новаторського механізму ELVES (що був недавно офіційно випущений). (Деталі див. в: )
Згадуючи, ELVES можна розглядати як механізм «підозрюваного роллапу». Шляхом активного запитування деяких валідаторів інших валідаторів щодо того, чи є дійсним певний блок Layer2, ми можемо з великою ймовірністю підтвердити його дійсність. Фактично, в разі будь-яких суперечок незабаром буде вимагатися участь всього набору валідаторів. Роб Хабермейєр, співзасновник Polkadot, ретельно пояснив це в одній зі статей. (Докладніше: )
ELVES дозволяє Polkadot мати одночасно дві властивості, які раніше вважалися взаємовиключними: "Шардинг виконання" та "спільна безпека". Це основний технічний результат Polkadot1 в плані масштабованості.
Зараз продовжимо розмову про аналогію класу "CORE".
Блокчейн, який виконує Шардинг, дуже схожий на процесор: як і у процесорі можуть бути декілька паралельних ядер, Полка може паралельно обробляти Блоки Layer2. Тому Layer2 на Полці називаються парачейном, а середовище, в якому відбувається повторне виконання окремого Блоку Layer2 малим підмножинами валідаторів, називається «ядерна (core)». Кожне ядро можна абстрагувати як «групу співпрацюючих валідаторів».
Ти можеш уявити собі одиночний Блокчейн як систему, що в будь-який момент часу приймає лише один Блок, тоді як Polkadot приймає Реле ланцюжок Блок і кожен паралельний ланцюжок ядра в кожний період часу.
Гетерогенність
До цього моменту ми обговорювали лише масштабованість та Шардинг, який надає Polkadot. Варто зазначити, що кожен Шардинг Polkadot насправді є повністю різним додатком. Це досягається за допомогою метапротоколу, який зберігається як байт-код на Блокчейні: протоколу, який визначає Блокчейн як байт-код, збережений у стані самого Блокчейну. У Polkadot 1.0 використовується WASM як пріоритетний байт-код, а в JAM використовується PVM/RISC-V.
Загалом, ось чому Polkadot називається гетерогенною фрагментаційною блокчейн-платформою. (Докладніше див. на: ) Кожен шар 2 є окремою програмою.
Polkadot2
Важливою частиною Polkadot2 є зробити використання основи більш гнучким. У первісній моделі Polkadot термін дії основи може становити від 6 місяців до 2 років, що підходить для компаній з ресурсами, але не дуже підходить для малих команд. Функція Polkadot, яка дозволяє більш гнучкий термін дії основи, називається «агільний час основи» (agile coretime) (див. деталі:). У цьому режимі термін дії основи Polkadot може бути скорочений до одного Блоку або тривати до одного місяця і забезпечувати гарантію максимальної ціни для користувачів, які хочуть довгостроково орендувати.
Інші функції Polkadot 2 поступово проявлятимуться під час обговорення, тому тут не потрібно занадто детально описувати.
Операції ядра внутрішньої системи та у блокчейні
Для того щоб зрозуміти JAM, спочатку потрібно зрозуміти, що відбувається, коли Блок Layer2 входить в основу Полоцьк.
Нижче наведено значну спрощену версію.
Підсумовуючи, ядро в основному складається з групи валідаторів. Таким чином, коли ми кажемо “дані відправлені в ядро”, ми насправді маємо на увазі, що ці дані передані цій групі валідаторів.
1.Частина валідаторів у ядрі виконає перевиконання блоку Layer2 Блок та продовжить обробку завдань, пов'язаних з Консенсус .
Зверніть увагу, до цього моменту всі операції відбувалися поза основним блоком Polkadot та функцією зміни стану. Усе це відбувається всередині ядра та на рівні доступності даних.
З вищезазначеного ми можемо розглянути деякі дії, які виконує Polkadot:
Спочатку, з кроку 1, ми можемо зрозуміти, що в Polkadot існує новий спосіб виконання, відмінний від традиційної функції переходу стану блокчейну. Зазвичай, коли всі валідатори в мережі виконують певну роботу, стан основного блокчейну оновлюється. Ми називаємо цю ситуацію у блокчейні операцією (on-chain operation), це те, що відбувається на кроці 3. Однак, внутрішній процес, який відбувається в ядрі (крок 1), є іншим. Ми називаємо цей новий тип обчислення блокчейну ядром (in-core ution).
Далі, з пункту 2 ми можемо зробити висновок, що Polkadot вже надає вбудовану можливість доступності даних (DA) та Layer2 автоматично використовує її, щоб забезпечити доступність свідоцтв про виконання протягом певного часу. Однак дані блоків, які можуть бути розміщені в цьому DA шарі, є фіксовані та завжди є свідоцтвами, які потрібні для виконання Layer2 Блоку. Крім того, код парачейна ніколи не читає дані з DA шару.
Розуміння вищезазначеного є основою розуміння JAM. Загальний підсумок такий:
ВАРЕННЯ
За допомогою розуміння попередньої частини, ми можемо успішно перейти до вступу в 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). Join означає fn refine(), коли всі ядра Polkadot паралельно обробляють великий обсяг роботи різних служб, цю фазу називають Join. Після фільтрації дані переходять до наступної фази. Accumulate означає процес накопичення всіх вищезазначених результатів в основний стан JAM, тобто частину, що виконується у блокчейні.
Робочі елементи можуть точно вказувати, який код вони виконують у ядрі, у блокчейні та як вони читають / записують вміст розподіленого дата-озера (Distributed Data Lake) звідки / як / чи взагалі.
2 Півсумісність
При перегляді наявної інформації про XCM (мову парачейну, обрану для Полкавалето), всі комунікації є асинхронними. (Докладніше див. :) Це означає, що після відправки повідомлення неможливо очікувати його відповіді.
Асинхронність є проявом непослідовності системи, основним недоліком постійної системи Шардингу (наприклад, екосистеми Layer2 для Polkadot 1 і Polkadot 2, а також існуючої екосистеми Ethereum).
Однак, як описано в розділі 2.4 Сірої книги, повністю консистентна система, яка завжди синхронізується для всіх своїх орендарів, може досягти певного рівня зростання, лише якщо не жертвує загальнодоступністю, доступністю або еластичністю. (Детальніше:)
Синхронізація≈Узгодженість||Асинхронія≈Незбіжність
Це також є ще одна сфера, в якій JAM виділяється: шляхом введення різноманітних функцій JAM реалізує новий проміжний стан, тобто систему напів-консистентності. У цій системі підсистеми, що часто взаємодіють, мають можливість створювати консистентне середовище одна для одної, не зобов'язуючи весь систему до підтримки консистентності. Це найкраще описано в інтерв'ю з автором Сірим Дровом (Gavin Wood): (див. деталі: _referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ)
Ще одним способом розуміння Polkadot/JAM є система Шардингу, де межі цих Шардінгів є рухомими і динамічно визначаються.
Полка завжди була Шардингом і повністю гетерогенною.
Зараз він буде розділений на Шардинг, гетерогенний, при цьому границі цих Шардингів можуть бути гнучко визначені, як сказав Ґевін Вуд у своєму твіттері про систему «півконсенсусу» (див. деталі: _src=twsrc%5Etfw).
Функції, які зробили це все можливим, включають:
2.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 є парачейни (Parachains), які працюють за принципом гнучкого осередку часу, і цей продукт продовжується в JAM.
Найбільш ранні послуги, що розгортається в JAM, можуть називатися CoreChains або Parachains. Ця служба дозволить існуючим парашейнам у стилі Polkadot-2 працювати на JAM.
Додаткові послуги можна розгорнути на JAM, і існуючі служби CoreChains можуть взаємодіяти з ними, але існуючі продукти Polkadot залишаться міцними і лише відкриють нові двері для існуючих команд Parachain.
Додаток: Шардинг даних
Більшість цього тексту досліджує масштабованість з точки зору виконання Шардинга. Ми також можемо розглянути цю ж проблему з точки зору даних. Цікаво, що ми виявили, що це схоже на раніше згаданий випадок напів-консистентності: в принципі, повністю консистентна система краще, але неможливо масштабувати; повністю не консистентна система може масштабуватися, але не є ідеальною, тоді як JAM з його моделлю напів-консистентності вносить нову можливість.
Система повної відповідності: Це те, що ми бачимо на платформі смарт-контрактів, повністю синхронізованій, такі як Solana, або на тих, що сміливо розгортаються лише на рівні Layer1 ETH блокчейну. Усі дані додатків зберігаються у блокчейні та легко доступні для всіх інших додатків. Це програмована властивість, але не масштабована.
Несумісна система: додаткові дані зберігаються поза Layer1 і в різних, ізольованих Шардинг. Дуже масштабована, але показує погану комбінативність. Модель Rollup для Polkadot та Ethereum відноситься до цього випадку.
JAM крім надання вищезазначених функцій, також дозволяє розробникам публікувати будь-які дані на рівень JAM DA, що в певній мірі є проміжною зоною між у блокчейні дані та поза блокчейном. Можна створювати нові застосунки, які використовують більшість даних застосунків на рівні DA, при цьому лише важливі дані зберігаються в стані JAM.
Додаток: Діаграма простору масштабованості
Цей розділ переінтерпретує наші погляди на скальність в галузі блокчейну. Це також пояснено в сірій книзі, тут наведено більш стислу версію.
Масштабованість блокчейну в значній мірі дотримується методів, що використовуються у традиційних розподілених системах: вертикального та горизонтального масштабування.
Розширення вгору - це робота, яку робить платформа, подібна до Solana. Шляхом максимальної оптимізації коду та обладнання досягається максимальна пропускна здатність.
Масштабування — це стратегія, яку використовують Ethereum і Polkadot: зменшити обсяг роботи, яку потрібно виконати для всіх. У традиційній розподіленій системі це досягається додаванням більшої кількості реплікаційних машин. У ланцюжку Блок «комп'ютер» - це сукупність валідаторів всієї мережі. Розподіливши роботу між ними (як це роблять ELVES), або оптимістично скоротивши їхні обов'язки (як це оптимально роблять Rollups), ми зменшили навантаження на всю валідаторну колекцію, дозволивши системі масштабуватися.
У блокчейні розширення схоже на «зменшення кількості машин, які потрібно виконати всі операції».
Підсумовуючи:
Додаток: Оновлення ядра на тому самому обладнанні
Цей розділ, заснований на аналозі, який запропонував Роб Хабермейєр у Sub02023: Поле для користувача/ядра Поле для користувача/ядра|Sub02023-YouTube (див. деталі за посиланням:), демонструє JAM як оновлення для Поле для користувача/ядра на тій самій апаратурі.
У типовому комп'ютері ми можемо розділити весь стек на три частини:
апаратне забезпечення
ядро
Простір користувача
У Полоці апаратне забезпечення, яке завжди було основним (як було сказано вище), є суттєвим для надання обчислень та доступності даних.
У Polkadot ядро насправді[9]До цього моменту було включено дві частини:
1.парачейн（парачейни）протокол：один спосіб узгодження, фіксоване використання ядра.
Ці обидва існують в релейному ланцюзі (Relay Chain) Полка.
Додатки простору користувача - це приклади парачейнів, їхні власні Токени та інші вміст, що будується на них.
Ми можемо візуалізувати цей процес наступним чином:
Полка завжди уявляла, що більше основних функцій буде перенесено до свого унікального користувача - парачейн. Це саме те, що має на меті досягти Minimal Relay RFC. (Деталі див. в: )
Це означає, що мережа Polkadot обробляє лише протокол парачейну, що деяким чином зменшує простір ядра.
Як тільки ця архітектура буде реалізована, буде набагато простіше візуалізувати, як виглядатиме міграція JAM. JAM суттєво зменшить простір ядра Polkadot, зробивши його більш універсальним. Крім того, протоколи Parachains будуть переміщені в простір користувача, оскільки це один з небагатьох способів написання додатків на тому ж ядрі (апаратному забезпеченні) та ядрі (JAM).
Це також ще раз підтверджує, чому JAM є лише альтернативою для релейної ланки Polkadot, а не альтернативою для парачейну.
Іншими словами, ми можемо розглядати міграцію JAM як оновлення ядра. Основне обладнання залишається незмінним, а більшість старого ядра переміщується у простір користувача для спрощення системи.
Щоб приєднатися до обговорення цієї статті, заохочуємо висловити свою думку на форумі:
Щодо участі в обговоренні на форумі, будь ласка, див. Наш посібник з використання форуму Polkadot, який ми випустили:
《Як брати участь у дискусіях про Polkadot: Посібник користувача офіційного форуму Polkadot》