原文:《Спільні секвенсори для ланцюжків додатків Starknet і Madara》
Автор: Апурв Садана
Складено: Odaily Planet Daily Як чоловіку
! [Де майбутнє розвитку мультичейну Ethereum, можливо, Polkadot може дати еталонну відповідь] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d5ea1f805b-dd1a6f-69ad2a.webp)
Коли все більше і більше ланцюжків додатків L2 покладаються на Ethereum як на розрахунковий рівень, особливо важлива сумісність між кількома ланцюгами та ступінь децентралізації кожного ланцюга.
У цій статті обговорюється концепція спільного замовлення, яка дозволяє різним ланцюжкам додатків спільно використовувати набір валідаторів для досягнення децентралізації, а також обробляє замовлення та виконання транзакцій за допомогою механізму замовлень і механізму зведення.
Однак спільний секвенсор і багатоланцюгова архітектура дизайну Polkadot дуже схожі, чи можна впровадити готову технологію Polkadot в екосистему Ethereum, тим самим покращивши процес розробки мультичейн Ethereum.
Наступне зібрано Odaily Planet Daily.
Що станеться зі 100 ланцюжками додатків?
Скажімо, ми перебуваємо в майбутньому, де зараз на Ethereum встановлено 100 різних ланцюжків додатків. Давайте розв'яжемо проблему, яку це виникне.
Децентралізована фрагментація
Кожен ланцюжок додатків повинен вирішувати проблему децентралізації самостійно. Зараз децентралізація ланцюжка додатків не така потрібна, як L1, головним чином тому, що ми покладаємося на L1 для забезпечення безпеки. Однак децентралізація все ще потрібна, щоб забезпечити життєздатність, протистояти цензурі та уникати монопольних переваг (наприклад, високих комісій). Однак, якщо кожен ланцюжок додатків буде вирішувати проблему децентралізації по-своєму, це призведе до фрагментації наборів валідаторів. Кожен ланцюжок додатків повинен розробляти економічні стимули для залучення нових валідаторів. Крім того, валідатори повинні вибрати, яких клієнтів вони готові запускати. Це створює величезний бар'єр для входу розробників для запуску власних ланцюжків додатків (що є лише транзакцією в порівнянні з розгортанням смарт-контрактів).
Компонування
Компонування в основному означає взаємодію між додатками. На Ethereum або Starknet це просто означає виклик іншого смарт-контракту, а все інше обробляється самим протоколом. Однак в ланцюжку додатків це стає складніше. Різні ланцюжки додатків мають свої власні механізми блокування та консенсусу. Щоразу, коли ви намагаєтеся взаємодіяти з іншим ланцюжком додатків, вам потрібно уважно переглянути алгоритм консенсусу та гарантії остаточності, а також відповідно налаштувати крос-чейн мости (безпосередньо в ончейн або через L1). Якщо ви хочете взаємодіяти з 10 ланцюжками додатків з різним дизайном, вам потрібно зробити це 10 разів.
! [Де майбутнє розвитку мультичейну Ethereum, можливо, Polkadot може дати еталонну відповідь] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-18c07cd8cf-dd1a6f-69ad2a.webp)
Досвід розробки
Розв'язати проблему децентралізації та мосту непросто. Якщо кожному ланцюжку додатків потрібно вирішити ці проблеми, середньостатистичному розробнику смарт-контрактів стане дуже складно побудувати свій власний ланцюжок додатків. Крім того, оскільки кожен ланцюжок додатків намагається вирішити ці проблеми по-своєму, незабаром ми побачимо, що різні ланцюжки дотримуються різних стандартів, що ускладнить приєднання нових учасників проекту до екосистеми.
Спільне використання секвенсора вирішує цю проблему
Якщо ви стежите за простором ланцюжка додатків, ви, напевно, чули термін «спільний секвенсор». Мається на увазі ідея спільного використання загального набору валідаторів для вирішення вищевказаних проблем. Працює це наступним чином.
Децентралізація спільного використання
Основна ідея спільного секвенсора полягає в тому, що немає необхідності мати різний набір валідаторів для кожного ланцюжка додатків або L2. Але можна мати дуже ефективний і децентралізований набір валідаторів, які сортують блоки для всіх ланцюгів. **
Оскільки майже кожен сортувальник сьогодні централізований, замовник розглядається як єдиний додаток, який збирає транзакції, сортує їх, виконує та публікує результати на L1. Однак ці завдання можна розбити на кілька модульних компонентів. Для пояснення я розділив його на дві частини.
Механізм сортування: відповідає за сортування транзакцій у певному порядку. Після того, як сортувальна машина визначить цей порядок, його потрібно дотримуватися. Це реалізується шляхом надсилання цього ордера на L1 і змушує валідаторів L1 перевіряти, чи виконуються транзакції в потрібному порядку.
Механізм зведення: Механізм зведення в основному включає все, що робить Rollup: збір транзакцій від користувачів, виконання транзакцій, створення доказів і оновлення статусу на L1. В ідеалі це можна було б розбити на більшу кількість компонентів, але ми уникатимемо цього в цій статті. Тут рушій сортування — це спільний секвенсор, а рушій Rollup — це, по суті, вся логіка зведення.
Отже, життєвий цикл транзакції виглядає наступним чином.
! [Де майбутнє розвитку мультичейну Ethereum, можливо, Polkadot може дати еталонну відповідь] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-fc5a1b83cf-dd1a6f-69ad2a.webp)
Спільний ордер в основному сортує транзакції в Rollup і надсилає їх до L1. Децентралізуючи спільну колекцію замовлень, спільний ордер децентралізує всі зведення, пов'язані з цією колекцією замовленців.
Компонування
Основною проблемою компонування є розуміння того, коли транзакція нарешті завершується в інших ланцюжках додатків, і відповідні дії в ланцюжку. Але спільне замовлення дозволяє складеним зведенням ділитися фрагментами один з одним. Тому, якщо відкат транзакції відбувається на Rollup B, весь блок відкочується, що також спричиняє відкат транзакції на Rollup A.
Зараз це, безумовно, звучить простіше, ніж є насправді. Для цього комунікація між Rollups має бути ефективною та масштабованою. Спільні секвенсери повинні розробити відповідні стандарти для того, як зведені повідомлення взаємодіють, як мають виглядати крос-чейн повідомлення, як обробляти оновлення зведення тощо. Хоча ці проблеми можна вирішити, їх нелегко досягти.
Досвід розробника
Незважаючи на те, що спільні ордери абстрагуються від децентралізованого аспекту, щоб спростити міжланцюговий обмін повідомленнями, все ще існують деякі стандарти, яких кожна мережа повинна дотримуватися, щоб бути сумісною зі спільними замовленнями. Наприклад, усі транзакції Rollup потрібно конвертувати в загальний формат, зрозумілий сортувальнику. Аналогічно, блоки сортувальника потрібно відфільтрувати, щоб отримати відповідні транзакції. Щоб вирішити цю проблему, я думаю, що спільний секвенсор запустить rollup фреймворк або SDK, який абстрагує шаблонний код і відкриває розробнику ланцюжка додатків лише частину бізнес-логіки. **
Нижче наведена принципова схема ланцюжка додатків з використанням загального секвенсора.
! [Де майбутнє розвитку мультичейну Ethereum, можливо, Polkadot може дати еталонну відповідь] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-849b693227-dd1a6f-69ad2a.webp)
Чи може мультичейн Ethereum вчитися на архітектурі дизайну Polkadot
Polkadot почав працювати над майбутнім мультичейн ще до Ethereum. Насправді над цим працюють вже понад 5 років. Якщо ви знайомі з Polkadot, ви, напевно, помітили, що наведений вище дизайн в основному переосмислює багато речей, які Polkadot вже зробив.
Релейний ланцюг (спільна децентралізація)
Ланцюг реле - це, по суті, двигун замовлення +L1 на схемі послідовності вище. До особливостей Relay Chain можна віднести:
Упорядкуйте всі транзакції зведення, щоб переконатися, що транзакція була виконана правильно (вона не використовує перевірку з нульовим розголошенням, але повторно запускає код виконання зведеного пакета для перевірки відмінностей у станах).
! [Де майбутнє розвитку мультичейну Ethereum, можливо, Polkadot може дати еталонну відповідь] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-a5377511f0-dd1a6f-69ad2a.webp)
Як ви, можливо, зрозуміли, релейний ланцюг - це, по суті, загальний порядок, про який ми говорили вище. Різниця полягає в тому, що Relay Chain також повинен перевіряти виконання, і ми залишаємо це на розсуд Ethereum.
XCM і XCMP
У попередньому розділі ми згадували, що якщо кожен ланцюг побудує свій власний метод для взаємодії з іншими, то незабаром ми побачимо різні стандарти та формати на всіх ланцюгах. Потрібно стежити за всіма цими форматами, які взаємодіють з кожним ланцюжком. Крім того, вам потрібно відповісти на такі питання, як що станеться, якщо ланцюг оновити. Однак ці проблеми можна вирішити, запровадивши стандарти, яким повинні слідувати всі мережі.
Як ви вже могли здогадатися, Polkadot зробив саме це. XCM - це формат повідомлень, XCMP - це протокол повідомлень, і всі дочірні ланцюжки можуть використовувати їх для зв'язку один з одним.
Субстрат і купчастий
Substrate — це фреймворк, розроблений компанією Parity для створення блокчейнів. У той час як усі парачейни на Polkadot використовують Substrate, Substrate насправді побудований у незалежний від ланцюга спосіб. Фреймворк абстрагує всі загальні аспекти блокчейну, зосереджуючись на логіці додатків. Як ми знаємо, Madara побудована на Substrate, як і Polkadot, Polygon Avail та багато інших проєктів. Крім того, Cumulus — це проміжне програмне забезпечення поверх Substrate, яке з'єднує ваш ланцюжок із Polkadot.
Отже, продовжуючи попередню аналогію, Substrate і Cumulus можна розглядати як альтернативи фреймворку Rollup, які дозволяють будувати ланцюжки додатків і з'єднувати їх із загальними секвенсорами.
Спільний секвенсор → релейний ланцюг
Компонування → XCM і XCMP
Фреймворк зведення/Стек → підкладку та купчастий
! [Де майбутнє розвитку мультичейну Ethereum, можливо, Polkadot може дати еталонну відповідь] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-e786adbea4-dd1a6f-69ad2a.webp)
На додаток до того, що це, по суті, копія Polkadot, у Polkadot і Parity є кілька досвідчених і добре фінансованих команд, які продовжують вдосконалювати Substrate і Polkadot, додаючи більше функцій і збільшуючи масштабованість. Ця технологія перевірена в польових умовах протягом багатьох років і має безліч інструментів розробки.
Розрахуватися з Polkadot на Ethereum?
Хоча це правда, що Polkadot почав будувати багатоланцюгове майбутнє ще до Ethereum, не можна заперечувати, що на сьогоднішній день Ethereum є найбільш децентралізованим блокчейном і де знаходиться більшість програм і ліквідності. Однак, що, якби існував спосіб перенести всю технологію Polkadot в екосистему Ethereum?
Власне, ми це вже почали, і Мадара є прикладом. Madara використовує фреймворк Substrate, щоб дозволити будь-кому створити власне рішення L2/L3 на основі zk на Ethereum. Наступне, що нам знадобиться, це релейний ланцюжок Polkadot у вигляді спільного секвенсора. Якщо ми зможемо повторно використовувати ланцюжок ретрансляції Polkadot, але видалимо частину перевірки, оскільки перевірка виконується за допомогою zk proof на L1 Надішліть порядок транзакцій до L1 Оптимізуйте вузли та алгоритми консенсусу для підтримки Tendermint/HotStuff, ми можемо отримати спільний ордер, згаданий раніше.
Очевидно, що це легше сказати, ніж зробити. Однак, на мою думку, цей шлях більш прагматичний, ніж перебудова секвенсора, стандартів і фреймворку з нуля. Polkadot вирішив багато проблем незалежним від ланцюга способом, який ми можемо запозичити для Ethereum. Як побічний продукт ми також отримуємо:
● Активна спільнота розробників, яка продовжує будувати та навчати світ для Substrate.
● Активний набір інструментів для розробки та сильне ком'юніті.
Багато активних парачейнів також можуть зупинитися на Ethereum, якщо вони цього бажають (нещодавно ми бачили, як Astar робить те саме з Polygon CDK).
Висновок
Моя головна мета при написанні цієї статті – викликати дискусію в ширшій екосистемі Starknet та Ethereum. Я думаю, що модель спільного ранжування зіграє важливу роль в децентралізації Starknet і децентралізації всіх ланцюжків додатків, які розглядаються для побудови на ньому. До тих пір, поки ми впевнені в аргументі ланцюжка додатків і розширюваності ZK, ретельний аналіз моделі спільного впорядкування неминучий. Крім того, Starknet вже розпочав роботу над децентралізацією, оскільки Madara переходить у виробництво, і я думаю, що настав час вирішити цю проблему. Тому прошу всіх, хто читає це, будь-які відгуки/пропозиції на цю тему. З нетерпінням чекаю прочитання ваших думок.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Де майбутнє розвитку мультичейна Ethereum, можливо, Polkadot може дати еталонну відповідь
原文:《Спільні секвенсори для ланцюжків додатків Starknet і Madara》
Автор: Апурв Садана
Складено: Odaily Planet Daily Як чоловіку
! [Де майбутнє розвитку мультичейну Ethereum, можливо, Polkadot може дати еталонну відповідь] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d5ea1f805b-dd1a6f-69ad2a.webp)
Що станеться зі 100 ланцюжками додатків?
Скажімо, ми перебуваємо в майбутньому, де зараз на Ethereum встановлено 100 різних ланцюжків додатків. Давайте розв'яжемо проблему, яку це виникне.
Децентралізована фрагментація
Кожен ланцюжок додатків повинен вирішувати проблему децентралізації самостійно. Зараз децентралізація ланцюжка додатків не така потрібна, як L1, головним чином тому, що ми покладаємося на L1 для забезпечення безпеки. Однак децентралізація все ще потрібна, щоб забезпечити життєздатність, протистояти цензурі та уникати монопольних переваг (наприклад, високих комісій). Однак, якщо кожен ланцюжок додатків буде вирішувати проблему децентралізації по-своєму, це призведе до фрагментації наборів валідаторів. Кожен ланцюжок додатків повинен розробляти економічні стимули для залучення нових валідаторів. Крім того, валідатори повинні вибрати, яких клієнтів вони готові запускати. Це створює величезний бар'єр для входу розробників для запуску власних ланцюжків додатків (що є лише транзакцією в порівнянні з розгортанням смарт-контрактів).
Компонування
Компонування в основному означає взаємодію між додатками. На Ethereum або Starknet це просто означає виклик іншого смарт-контракту, а все інше обробляється самим протоколом. Однак в ланцюжку додатків це стає складніше. Різні ланцюжки додатків мають свої власні механізми блокування та консенсусу. Щоразу, коли ви намагаєтеся взаємодіяти з іншим ланцюжком додатків, вам потрібно уважно переглянути алгоритм консенсусу та гарантії остаточності, а також відповідно налаштувати крос-чейн мости (безпосередньо в ончейн або через L1). Якщо ви хочете взаємодіяти з 10 ланцюжками додатків з різним дизайном, вам потрібно зробити це 10 разів.
! [Де майбутнє розвитку мультичейну Ethereum, можливо, Polkadot може дати еталонну відповідь] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-18c07cd8cf-dd1a6f-69ad2a.webp)
Досвід розробки
Розв'язати проблему децентралізації та мосту непросто. Якщо кожному ланцюжку додатків потрібно вирішити ці проблеми, середньостатистичному розробнику смарт-контрактів стане дуже складно побудувати свій власний ланцюжок додатків. Крім того, оскільки кожен ланцюжок додатків намагається вирішити ці проблеми по-своєму, незабаром ми побачимо, що різні ланцюжки дотримуються різних стандартів, що ускладнить приєднання нових учасників проекту до екосистеми.
Спільне використання секвенсора вирішує цю проблему
Якщо ви стежите за простором ланцюжка додатків, ви, напевно, чули термін «спільний секвенсор». Мається на увазі ідея спільного використання загального набору валідаторів для вирішення вищевказаних проблем. Працює це наступним чином.
Децентралізація спільного використання
Основна ідея спільного секвенсора полягає в тому, що немає необхідності мати різний набір валідаторів для кожного ланцюжка додатків або L2. Але можна мати дуже ефективний і децентралізований набір валідаторів, які сортують блоки для всіх ланцюгів. **
Оскільки майже кожен сортувальник сьогодні централізований, замовник розглядається як єдиний додаток, який збирає транзакції, сортує їх, виконує та публікує результати на L1. Однак ці завдання можна розбити на кілька модульних компонентів. Для пояснення я розділив його на дві частини.
Механізм сортування: відповідає за сортування транзакцій у певному порядку. Після того, як сортувальна машина визначить цей порядок, його потрібно дотримуватися. Це реалізується шляхом надсилання цього ордера на L1 і змушує валідаторів L1 перевіряти, чи виконуються транзакції в потрібному порядку.
Механізм зведення: Механізм зведення в основному включає все, що робить Rollup: збір транзакцій від користувачів, виконання транзакцій, створення доказів і оновлення статусу на L1. В ідеалі це можна було б розбити на більшу кількість компонентів, але ми уникатимемо цього в цій статті. Тут рушій сортування — це спільний секвенсор, а рушій Rollup — це, по суті, вся логіка зведення.
Отже, життєвий цикл транзакції виглядає наступним чином.
! [Де майбутнє розвитку мультичейну Ethereum, можливо, Polkadot може дати еталонну відповідь] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-fc5a1b83cf-dd1a6f-69ad2a.webp)
Спільний ордер в основному сортує транзакції в Rollup і надсилає їх до L1. Децентралізуючи спільну колекцію замовлень, спільний ордер децентралізує всі зведення, пов'язані з цією колекцією замовленців.
Компонування
Основною проблемою компонування є розуміння того, коли транзакція нарешті завершується в інших ланцюжках додатків, і відповідні дії в ланцюжку. Але спільне замовлення дозволяє складеним зведенням ділитися фрагментами один з одним. Тому, якщо відкат транзакції відбувається на Rollup B, весь блок відкочується, що також спричиняє відкат транзакції на Rollup A.
Зараз це, безумовно, звучить простіше, ніж є насправді. Для цього комунікація між Rollups має бути ефективною та масштабованою. Спільні секвенсери повинні розробити відповідні стандарти для того, як зведені повідомлення взаємодіють, як мають виглядати крос-чейн повідомлення, як обробляти оновлення зведення тощо. Хоча ці проблеми можна вирішити, їх нелегко досягти.
Досвід розробника
Незважаючи на те, що спільні ордери абстрагуються від децентралізованого аспекту, щоб спростити міжланцюговий обмін повідомленнями, все ще існують деякі стандарти, яких кожна мережа повинна дотримуватися, щоб бути сумісною зі спільними замовленнями. Наприклад, усі транзакції Rollup потрібно конвертувати в загальний формат, зрозумілий сортувальнику. Аналогічно, блоки сортувальника потрібно відфільтрувати, щоб отримати відповідні транзакції. Щоб вирішити цю проблему, я думаю, що спільний секвенсор запустить rollup фреймворк або SDK, який абстрагує шаблонний код і відкриває розробнику ланцюжка додатків лише частину бізнес-логіки. **
Нижче наведена принципова схема ланцюжка додатків з використанням загального секвенсора.
! [Де майбутнє розвитку мультичейну Ethereum, можливо, Polkadot може дати еталонну відповідь] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-849b693227-dd1a6f-69ad2a.webp)
Чи може мультичейн Ethereum вчитися на архітектурі дизайну Polkadot
Polkadot почав працювати над майбутнім мультичейн ще до Ethereum. Насправді над цим працюють вже понад 5 років. Якщо ви знайомі з Polkadot, ви, напевно, помітили, що наведений вище дизайн в основному переосмислює багато речей, які Polkadot вже зробив.
Релейний ланцюг (спільна децентралізація)
Ланцюг реле - це, по суті, двигун замовлення +L1 на схемі послідовності вище. До особливостей Relay Chain можна віднести:
Упорядкуйте всі транзакції зведення, щоб переконатися, що транзакція була виконана правильно (вона не використовує перевірку з нульовим розголошенням, але повторно запускає код виконання зведеного пакета для перевірки відмінностей у станах).
! [Де майбутнє розвитку мультичейну Ethereum, можливо, Polkadot може дати еталонну відповідь] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-a5377511f0-dd1a6f-69ad2a.webp)
Як ви, можливо, зрозуміли, релейний ланцюг - це, по суті, загальний порядок, про який ми говорили вище. Різниця полягає в тому, що Relay Chain також повинен перевіряти виконання, і ми залишаємо це на розсуд Ethereum.
XCM і XCMP
У попередньому розділі ми згадували, що якщо кожен ланцюг побудує свій власний метод для взаємодії з іншими, то незабаром ми побачимо різні стандарти та формати на всіх ланцюгах. Потрібно стежити за всіма цими форматами, які взаємодіють з кожним ланцюжком. Крім того, вам потрібно відповісти на такі питання, як що станеться, якщо ланцюг оновити. Однак ці проблеми можна вирішити, запровадивши стандарти, яким повинні слідувати всі мережі.
Як ви вже могли здогадатися, Polkadot зробив саме це. XCM - це формат повідомлень, XCMP - це протокол повідомлень, і всі дочірні ланцюжки можуть використовувати їх для зв'язку один з одним.
Субстрат і купчастий
Substrate — це фреймворк, розроблений компанією Parity для створення блокчейнів. У той час як усі парачейни на Polkadot використовують Substrate, Substrate насправді побудований у незалежний від ланцюга спосіб. Фреймворк абстрагує всі загальні аспекти блокчейну, зосереджуючись на логіці додатків. Як ми знаємо, Madara побудована на Substrate, як і Polkadot, Polygon Avail та багато інших проєктів. Крім того, Cumulus — це проміжне програмне забезпечення поверх Substrate, яке з'єднує ваш ланцюжок із Polkadot.
Отже, продовжуючи попередню аналогію, Substrate і Cumulus можна розглядати як альтернативи фреймворку Rollup, які дозволяють будувати ланцюжки додатків і з'єднувати їх із загальними секвенсорами.
Спільний секвенсор → релейний ланцюг
Компонування → XCM і XCMP
Фреймворк зведення/Стек → підкладку та купчастий
! [Де майбутнє розвитку мультичейну Ethereum, можливо, Polkadot може дати еталонну відповідь] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-e786adbea4-dd1a6f-69ad2a.webp)
На додаток до того, що це, по суті, копія Polkadot, у Polkadot і Parity є кілька досвідчених і добре фінансованих команд, які продовжують вдосконалювати Substrate і Polkadot, додаючи більше функцій і збільшуючи масштабованість. Ця технологія перевірена в польових умовах протягом багатьох років і має безліч інструментів розробки.
Розрахуватися з Polkadot на Ethereum?
Хоча це правда, що Polkadot почав будувати багатоланцюгове майбутнє ще до Ethereum, не можна заперечувати, що на сьогоднішній день Ethereum є найбільш децентралізованим блокчейном і де знаходиться більшість програм і ліквідності. Однак, що, якби існував спосіб перенести всю технологію Polkadot в екосистему Ethereum?
Власне, ми це вже почали, і Мадара є прикладом. Madara використовує фреймворк Substrate, щоб дозволити будь-кому створити власне рішення L2/L3 на основі zk на Ethereum. Наступне, що нам знадобиться, це релейний ланцюжок Polkadot у вигляді спільного секвенсора. Якщо ми зможемо повторно використовувати ланцюжок ретрансляції Polkadot, але видалимо частину перевірки, оскільки перевірка виконується за допомогою zk proof на L1 Надішліть порядок транзакцій до L1 Оптимізуйте вузли та алгоритми консенсусу для підтримки Tendermint/HotStuff, ми можемо отримати спільний ордер, згаданий раніше.
Очевидно, що це легше сказати, ніж зробити. Однак, на мою думку, цей шлях більш прагматичний, ніж перебудова секвенсора, стандартів і фреймворку з нуля. Polkadot вирішив багато проблем незалежним від ланцюга способом, який ми можемо запозичити для Ethereum. Як побічний продукт ми також отримуємо:
● Активна спільнота розробників, яка продовжує будувати та навчати світ для Substrate.
● Активний набір інструментів для розробки та сильне ком'юніті.
Багато активних парачейнів також можуть зупинитися на Ethereum, якщо вони цього бажають (нещодавно ми бачили, як Astar робить те саме з Polygon CDK).
Висновок
Моя головна мета при написанні цієї статті – викликати дискусію в ширшій екосистемі Starknet та Ethereum. Я думаю, що модель спільного ранжування зіграє важливу роль в децентралізації Starknet і децентралізації всіх ланцюжків додатків, які розглядаються для побудови на ньому. До тих пір, поки ми впевнені в аргументі ланцюжка додатків і розширюваності ZK, ретельний аналіз моделі спільного впорядкування неминучий. Крім того, Starknet вже розпочав роботу над децентралізацією, оскільки Madara переходить у виробництво, і я думаю, що настав час вирішити цю проблему. Тому прошу всіх, хто читає це, будь-які відгуки/пропозиції на цю тему. З нетерпінням чекаю прочитання ваших думок.