Введение

Сегодня мы уже видим, как проекты начинают экспериментировать с 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 снова и снова.

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
Свертываемые фреймворки/стеки → Substrate и Cumulus

Так что да, это практически снова Polkadot! Кроме того, в Polkadot и Parity работают одни из самых опытных и финансируемых команд, которые продолжают развивать Substrate и Polkadot, чтобы добавить больше функций и сделать их более масштабируемыми. Технология уже проверена годами и имеет тонну инструментов для разработчиков.

Перевести Polkadot на Ethereum?

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

Есть! На самом деле, мы уже начали это делать с Мадарой. Madara использует фреймворк Substrate, чтобы позволить любому желающему построить собственное решение L2/L3 на базе zk поверх Ethereum. Далее нам нужна цепочка ретрансляции Polkadot в виде общего секвенсора. Так что, по сути, если мы можем повторить цепочку эстафет Polkadot, но

1. Уберите часть проверки, так как это происходит на L1 с помощью zk-доказательств.
2. Зафиксируйте порядок транзакций в L1
3. Оптимизируйте узлы и алгоритмы консенсуса для поддержки Tendermint/HotStuff

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

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

Заключение

Моя основная идея написания этого поста - открыть дискуссию среди более широкой экосистемы Starknet и Ethereum. Мне кажется, что модель совместного секвенирования сыграет важную роль в децентрализации не только Starknet, но и всех цепочек приложений, которые рассматривают возможность создания на ее основе. До тех пор, пока мы уверены в тезисе о цепочке приложений и масштабировании zk, тщательный анализ модели совместного секвенирования неизбежен. Более того, поскольку Madara движется к производству, а Starknet начал работу над децентрализацией, я считаю, что сейчас важно затронуть эту тему. Поэтому я прошу всех, кто читает эту статью, оставлять свои отзывы/предложения по данной теме. С нетерпением жду Ваших мыслей!

Приложение

Polkadot против Cosmos

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

Отказ от ответственности：

1. Эта статья перепечатана с сайта[starknet]. Все авторские права принадлежат оригинальному автору[apoorvsadana]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Предупреждение об ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.