原文:《Общие секвенсоры для цепочек приложений Starknet и Madara》
Автор: Апурв Садана
Составитель текста: Odaily Planet Daily Как стать мужем
! [Где будущее развития мультичейна Ethereum, возможно, Polkadot сможет дать справочный ответ] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d5ea1f805b-dd1a6f-69ad2a.webp)
Когда все больше и больше цепочек приложений L2 полагаются на Ethereum в качестве расчетного уровня, взаимодействие между несколькими цепочками и степень децентрализации каждой цепочки особенно важны.
В этой статье обсуждается концепция общего orderer, которая позволяет различным цепочкам приложений совместно использовать набор валидаторов для достижения децентрализации, а также обрабатывает порядок и выполнение транзакций с помощью механизма заказов и механизма свертки.
Тем не менее, общий секвенсор и многоцепочечная архитектура 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. Однако эти задачи можно разбить на несколько модульных компонентов. Для объяснения я разделил его на две части.
Sort Engine: отвечает за сортировку транзакций в определенном порядке. После того, как сортировочная система определит этот порядок, его необходимо соблюдать. Это реализуется путем отправки этого ордера на L1 и принуждения валидаторов L1 проверять, выполняются ли транзакции в нужном порядке.
Движок Rollup: Движок Rollup включает в себя практически все, что делает Rollup: сбор транзакций от пользователей, выполнение транзакций, создание подтверждений и обновление статуса на L1. В идеале его можно разбить на большее количество компонентов, но в этой статье мы не будем этого делать. Здесь механизм сортировки — это общий секвенсор, а механизм Rollup — это, по сути, вся логика Rollup.
Таким образом, жизненный цикл транзакции выглядит следующим образом.
! [Где будущее развития мультичейна Ethereum, возможно, Polkadot сможет дать справочный ответ] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-fc5a1b83cf-dd1a6f-69ad2a.webp)
Служба общего упорядочения в основном сортирует транзакции в Rollup и отправляет их на L1. Децентрализуя коллекцию системы упорядочения, она децентрализует все накопительные пакеты, подключенные к этой коллекции.
Компонуемость
Основная проблема, связанная с компонуемостью, заключается в понимании того, когда транзакция окончательно завершена в других цепочках приложений, и соответствующих действиях в блокчейне. Но общий упорядочиватель позволяет компонуемым сверткам обмениваться блоками друг с другом. Таким образом, если откат транзакции происходит на накопителе B, выполняется откат всего блока, что также приводит к откату транзакции по накопительному пакету A.
Это, конечно, звучит проще, чем есть на самом деле. Для этого обмен данными между накопительными пакетами должен быть эффективным и масштабируемым. Общие секвенсоры должны разработать соответствующие стандарты того, как обмениваются друг с другом накопители, как должны выглядеть кроссчейн-сообщения, как обрабатывать обновления накопителей и так далее. Несмотря на то, что эти проблемы решаемы, их нелегко достичь.
Опыт разработчика
Несмотря на то, что разделяемые ordering-службы абстрагируются от децентрализованного аспекта, чтобы упростить обмен сообщениями между сетями, все же существуют некоторые стандарты, которым каждая цепочка должна следовать, чтобы быть совместимой с разделяемыми orderers. Например, все транзакции 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, мы можем получить общий orderer, упомянутый ранее.
Очевидно, что это легче сказать, чем сделать. Тем не менее, я думаю, что этот путь более прагматичен, чем перестройка секвенсора, стандартов и фреймворка с нуля. 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. Однако эти задачи можно разбить на несколько модульных компонентов. Для объяснения я разделил его на две части.
Sort Engine: отвечает за сортировку транзакций в определенном порядке. После того, как сортировочная система определит этот порядок, его необходимо соблюдать. Это реализуется путем отправки этого ордера на L1 и принуждения валидаторов L1 проверять, выполняются ли транзакции в нужном порядке.
Движок Rollup: Движок Rollup включает в себя практически все, что делает Rollup: сбор транзакций от пользователей, выполнение транзакций, создание подтверждений и обновление статуса на L1. В идеале его можно разбить на большее количество компонентов, но в этой статье мы не будем этого делать. Здесь механизм сортировки — это общий секвенсор, а механизм Rollup — это, по сути, вся логика Rollup.
Таким образом, жизненный цикл транзакции выглядит следующим образом.
! [Где будущее развития мультичейна Ethereum, возможно, Polkadot сможет дать справочный ответ] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-fc5a1b83cf-dd1a6f-69ad2a.webp)
Служба общего упорядочения в основном сортирует транзакции в Rollup и отправляет их на L1. Децентрализуя коллекцию системы упорядочения, она децентрализует все накопительные пакеты, подключенные к этой коллекции.
Компонуемость
Основная проблема, связанная с компонуемостью, заключается в понимании того, когда транзакция окончательно завершена в других цепочках приложений, и соответствующих действиях в блокчейне. Но общий упорядочиватель позволяет компонуемым сверткам обмениваться блоками друг с другом. Таким образом, если откат транзакции происходит на накопителе B, выполняется откат всего блока, что также приводит к откату транзакции по накопительному пакету A.
Это, конечно, звучит проще, чем есть на самом деле. Для этого обмен данными между накопительными пакетами должен быть эффективным и масштабируемым. Общие секвенсоры должны разработать соответствующие стандарты того, как обмениваются друг с другом накопители, как должны выглядеть кроссчейн-сообщения, как обрабатывать обновления накопителей и так далее. Несмотря на то, что эти проблемы решаемы, их нелегко достичь.
Опыт разработчика
Несмотря на то, что разделяемые ordering-службы абстрагируются от децентрализованного аспекта, чтобы упростить обмен сообщениями между сетями, все же существуют некоторые стандарты, которым каждая цепочка должна следовать, чтобы быть совместимой с разделяемыми orderers. Например, все транзакции 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, мы можем получить общий orderer, упомянутый ранее.
Очевидно, что это легче сказать, чем сделать. Тем не менее, я думаю, что этот путь более прагматичен, чем перестройка секвенсора, стандартов и фреймворка с нуля. Polkadot решил многие проблемы независимым от цепочки способом, который мы можем позаимствовать для Ethereum. В качестве побочного продукта мы также получаем:
● Активное сообщество разработчиков, которое продолжает создавать и обучать мир для Substrate.
● Активный набор инструментов разработки и сильное сообщество.
Многие активные парачейны также могут остановиться на Ethereum, если захотят (недавно мы видели, как Astar сделал то же самое с Polygon CDK).
Заключение
Моя главная цель при написании этой статьи — разжечь дискуссию в более широкой экосистеме Starknet и Ethereum. Я думаю, что модель совместного ранжирования будет играть важную роль в децентрализации Starknet и децентрализации всех цепочек приложений, рассматриваемых для ее построения. До тех пор, пока мы уверены в аргументе цепочки приложений и расширяемости ZK, тщательный анализ модели общего упорядочения неизбежен. Кроме того, Starknet уже начал работу над децентрализацией по мере того, как Madara переходит в производство, и я думаю, что пришло время заняться этим. Поэтому я прошу всех, кто читает это, оставить отзывы/предложения по этой теме. С нетерпением жду ваших мыслей.