Вступ

Сьогодні ми вже бачимо проекти, які починають експериментувати з Madara для своїх мереж додатків. Pragma, Kakarot, Mangata Finance і Dojo – лише деякі приклади. Поки ми віримо в багатоланцюгове майбутнє та потужність масштабування zk, у майбутньому ми побачимо ще більше таких проектів. Однак зростання кількості мереж додатків також викликає питання

1. Децентралізація
2. Композиційність
3. Досвід розробки

У цій публікації я спробую пояснити проблеми, які виникають через наявність великої кількості ланцюжків програм, а також запропоную можливе вирішення проблеми, яке я вважаю елегантним і оптимальним для Madara та Starknet. Якщо ви вже добре розбираєтесь у ланцюжках додатків і спільній послідовності, не соромтеся переходити до розділу «Зачекайте, це просто Polkadot знову».

Що відбувається в 100 мережах програм?

Припустімо, що ми живемо в майбутньому, де зараз є 100 різних мереж додатків, які працюють на Ethereum. Давайте розглянемо всі проблеми, які це спричинить.

Фрагментована децентралізація

Кожен ланцюжок додатків повинен буде вирішити проблему децентралізації самостійно. Тепер децентралізація ланцюжків додатків не є такою необхідною, як L1, головним чином тому, що ми покладаємося на L1 для безпеки. Однак нам все ще потрібна децентралізація, щоб забезпечити жвавість, опір цензурі та уникнути монопольних переваг (наприклад, високих зборів). Однак також важливо зазначити, що якщо кожен ланцюжок додатків вирішуватиме децентралізацію власним шляхом, це дуже швидко призведе до фрагментації наборів валідаторів. Кожен ланцюжок додатків мав би розробити економічні стимули для впровадження нових валідаторів. Крім того, валідатори повинні вибрати клієнтів, з якими їм зручно працювати. Не кажучи вже про величезні бар’єри для входу, які це створює для розробників, щоб запускати власні ланцюжки додатків (проти розгортання смарт-контракту, який є лише транзакцією).

Композиційність

Компонування по суті означає взаємодію між програмами. В Ethereum або Starknet це просто означає виклик іншого контракту, а все інше обробляється самим протоколом. Однак із ланцюжками програм це стає набагато складніше. Різні ланцюжки програм мають власні блоки та механізми консенсусу. Кожного разу, коли ви намагаєтесь спробувати взаємодіяти з іншим ланцюжком додатків, вам потрібно ретельно вивчити алгоритм консенсусу та гарантії остаточності та відповідно налаштувати перехресний міст (безпосередньо до ланцюжка або через L1). Якщо ви хочете взаємодіяти з 10 ланцюжками додатків з різними дизайнами, ви повинні зробити це 10 різних разів.

Досвід розробки

Рішення щодо децентралізації та з’єднання непросте. Якщо це є вимогою для кожного ланцюжка додатків, звичайному розробнику смарт-контрактів буде дуже важко створити власний ланцюжок додатків. Крім того, оскільки кожна мережа додатків намагається вирішити ці проблеми по-своєму, незабаром ми побачимо, що різні мережі дотримуються різних стандартів, що ще більше ускладнить приєднання до екосистеми.

Спільні секвенсори можуть вирішити це

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

Спільна децентралізація

Сама суть спільних секвенсорів полягає в тому, що вам не потрібно мати різний набір валідаторів для кожного ланцюжка програм або L2. Натомість ви можете мати дійсно ефективний і децентралізований набір валідаторів, які послідовні блоки для всіх ланцюжків! Уявіть собі блоки, які містять транзакції зі 100 різних мереж додатків. Ви можете подумати, що це справді роздує секвенсор, оскільки вам потрібно вміти керувати механізмами виконання для кожного ланцюжка програм.

Ну, ти ні!

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

1. Механізм замовлення: відповідає за послідовність транзакцій у певному порядку. Після того, як система замовлень прийме рішення про цей порядок, його ПОВИННО виконуватися. Це виконується шляхом фіксації цього порядку на L1 і змушує верифікатори L1 перевіряти, чи транзакції були виконані в необхідному порядку.
2. Механізм зведення: механізм зведення — це, по суті, все інше, що робить зведення — збір транзакцій від користувачів, їх виконання, створення доказів і оновлення стану на L1. В ідеалі це можна розбити на більше компонентів, але ми б уникали цього для цієї публікації.

Тут механізм упорядкування — це спільний секвенсор, а механізм зведення — це в основному вся логіка зведення. Тож життєвий цикл транзакції виглядає так

Спільні секвенсори в основному впорядковують транзакції між зведеннями та передають їх на L1. Отже, децентралізувавши спільний набір секвенсорів, ви фактично децентралізуєте всі зведення, пов’язані з цим набором секвенсорів! Щоб отримати більш детальне уявлення про роботу спільних секвенсорів, ви також можете звернутися до цієї дивовижної <a href="https://hackmd.io/@EspressoSystems/EspressoSequencer"> статті 17 від Espresso.

Композиційність

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

Тепер це звучить легше сказати, ніж зробити. Для цього. зв’язок між зведеними пакетами має бути ефективним і масштабованим. Спільні секвенсори повинні розробити належні стандарти щодо того, як зведення можуть спілкуватися, як мають виглядати міжланцюгові повідомлення, як працювати з оновленнями зведень тощо. Незважаючи на те, що це розв’язні проблеми, вони складні і їх нелегко вирішити.

Досвід розробника

Хоча спільні секвенсори абстрагують аспект децентралізації та спрощують передачу повідомлень між ланцюжками, все ж є деякі стандарти, яких кожен ланцюжок повинен дотримуватися, щоб бути сумісним із спільним секвенсором. Наприклад, усі транзакції зведення мають бути перетворені в загальний формат, який розуміє секвенсор. Аналогічно, блоки з секвенсора потрібно відфільтрувати, щоб отримати відповідні транзакції. Щоб вирішити цю проблему, я б припустив, що спільні секвенсори створять фреймворки зведення або SDK, які абстрагують шаблонний код і надають розробникам ланцюжка програм лише частину бізнес-логіки.

Ось діаграма того, як виглядатимуть ланцюжки додатків зі спільними секвенсорами

Зачекайте, це знову Полкадот

Polkadot почав працювати над мультиланцюжковим майбутнім набагато раніше Ethereum. Фактично, вони працювали над цим вже більше 5 років, і якщо ви знайомі з Polkadot, ви могли помітити, що вищезгаданий дизайн в основному переосмислює багато речей, які Polkadot вже зробив!

Ланцюг ретрансляції (спільна децентралізація)

Ланцюг реле в основному є системою замовлення + L1 на діаграмі послідовності вище. Ланцюг реле

1. Замовляє транзакції в усіх парачейнах (згортання)
2. Він перевіряє транзакції, виконані правильно (замість перевірки zk, він фактично повторно запускає код виконання зведення, щоб перевірити відмінності стану)

Можливо, ви зрозуміли, що реле — це, в основному, спільний секвенсор, про який ми говорили вище. За винятком того факту, що ланцюг ретрансляції також повинен перевіряти виконання (оскільки Polkadot є L1), тоді як ми залишаємо це Ethereum.

XCM і XCMP

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

Як ви могли здогадатися, Polkadot вже зробив це. XCM — це формат обміну повідомленнями, а XCMP — це протокол обміну повідомленнями, який усі ланцюги субстратів можуть використовувати для зв’язку один з одним. Я не буду вдаватися в подробиці, але ви можете прочитати про це тут 5.

Субстрат і купчасті

Substrate — це фреймворк, розроблений Parity, який можна використовувати для створення блокчейнів. Незважаючи на те, що всі парачейни на Polkadot використовують субстрат, субстрат фактично побудований ланцюгово-агностичним способом. Фреймворк абстрагує всі загальні аспекти блокчейна, щоб ви могли зосередитися лише на логіці програми. Як ми знаємо, Madara побудовано на Substrate, як і Polkadot, Polygon Avail та багато інших проектів. Крім того, Cumulus — це проміжне програмне забезпечення на основі Substrate, яке дозволяє підключити вашу мережу до Polkadot.

Отже, продовжуючи нашу аналогію, як і раніше, Substrate і Cumulus можна розглядати як замінники фреймворків зведення, які дозволяють створювати ланцюжки додатків і підключати їх до спільних секвенсорів.

Спільні секвенсори → Ланцюги ретрансляції
Компонування → XCM і XCMP
Зведені фреймворки/стеки → Субстрат і Cumulus

Тож так, це майже все заново! Окрім цього, Polkadot і Parity мають одні з найбільш досвідчених і фінансованих команд, які продовжують створювати Substrate і Polkadot, щоб додати більше функцій і зробити їх більш масштабованими. Ця технологія вже роками перевірена в боях і має масу готових інструментів для розробників.

Розрахунок Polkadot на Ethereum?

Хоча Polkadot дійсно почав будувати багатоланцюгове майбутнє ще до Ethereum, не можна заперечувати, що на сьогоднішній день Ethereum є найбільш децентралізованим блокчейном і місцем, де зберігається більшість додатків і ліквідності. Однак що, якби був спосіб перенести всю технологію Polkadot в екосистему Ethereum?

Є! Фактично, ми вже почали це з Мадари. Madara використовує фреймворк Substrate, щоб дозволити будь-кому створити власне рішення L2/L3 на базі zk на основі Ethereum. Далі нам потрібен релейний ланцюг Polkadot у формі спільного секвенсора. Отже, якщо ми зможемо повторно використовувати ланцюг реле Polkadot, але

1. Видаліть частину перевірки, як це відбувається на L1 через zk proofs
2. Закріпіть порядок транзакцій для L1
3. Оптимізуйте вузли та алгоритми консенсусу для підтримки Tendermint/HotStuff

Ми можемо отримати спільні секвенсори, як згадувалося раніше. Очевидно, це легше сказати, ніж зробити. Однак я вважаю, що цей шлях більш прагматичний, ніж перебудова секвенсерів, стандартів і фреймворків з нуля. Polkadot вже вирішив багато проблем ланцюгово-агностичним способом, який ми можемо запозичити для Ethereum. Як побічний продукт ми отримуємо

1. Активна група розробників, які продовжують створювати та навчати світ про Substrate
2. Активний набір інструментів для розробників і сильна спільнота
3. Багато активних парачейнів також можуть оселитися на Ethereum, якщо хочуть це зробити (нещодавно ми бачили, як Astar зробив те саме з Polygon CDK).

Висновок

Моя головна ідея написання цього допису полягає в тому, щоб відкрити дискусію серед ширшої екосистеми Starknet та Ethereum. Я вважаю, що спільна модель послідовності зіграє важливу роль у децентралізації не лише Starknet, але й усіх мереж додатків, які розглядають можливість створення на її основі. Поки ми впевнені в тезі про ланцюжок програм і масштабуванні zk, ретельний аналіз спільної моделі секвенування неминучий. Крім того, оскільки Madara рухається до виробництва, а Starknet розпочав роботу над децентралізацією, я вважаю, що цю тему зараз важливо розглянути. Тому я прошу всіх, хто читає це, залишити будь-які відгуки/пропозиції щодо теми. З нетерпінням чекаю на ваші думки!

Додаток

Полкадот проти Космосу

Cosmos, подібно до Polkadot, уже багато років шукає багатоланцюжкове майбутнє. Як наслідок, було зроблено багато розробок із Cosmos SDK та IBC, і ми також бачимо, що багато ланцюжків додатків будуються на екосистемі Cosmos. Отже, цілком справедливо також розглянути Cosmos для цього підходу. Моя особиста точка зору на цю тему полягає в тому, що Polkadot більш актуальний, оскільки він вирішує проблему спільних секвенсорів, тоді як Cosmos вимагає, щоб кожен ланцюжок додатків створював власний набір валідаторів. Крім того, Substrate завжди будувався ланцюгово-агностичним способом, щоб дозволити розробникам створювати блокчейни без жодних припущень щодо консенсусних алгоритмів чи екосистеми Polkadot. Це також причина, чому ми вибрали субстрат для Madara. Однак, з огляду на це, мій досвід роботи з Cosmos обмежений, і я хотів би почути більше про це від більш досвідчених людей! Ви також можете дізнатися більше про порівняння двох мереж тут

Відмова від відповідальності:

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