Баланс расширяемости Блокчейн: Выбор между Polkadot и Web3
В эпоху, когда технологии Блокчейн постоянно стремятся к более высокой эффективности, постепенно возникает ключевая проблема: как повысить производительность, одновременно сохраняя безопасность и устойчивость системы? Это не только технический вызов, но и глубокий выбор архитектурного проектирования. Для экосистемы Web3 система, которая лишь быстрее, если она основана на жертве доверия и безопасности, часто не может поддерживать действительно устойчивые инновации.
Как важный движущий фактор масштабируемости Web3, делает ли Polkadot какие-то компромиссы в процессе достижения высокой пропускной способности и низкой задержки? Делает ли его модель rollup уступки в децентрализации, безопасности или сетевой интероперабельности? В этой статье будут обсуждены эти вопросы, глубоко проанализированы компромиссы и взвешивания Polkadot в дизайне масштабируемости, а также проведено сравнение с решениями других основных публичных блокчейнов, исследуя их различные выборы путей в производительности, безопасности и децентрализации.
Проблемы, с которыми сталкивается дизайн расширения Polkadot
Баланс между гибкостью и децентрализацией
Архитектура Polkadot зависит от сети валидаторов и централизованной релейной цепи, может ли это потенциально ввести риски централизации в некоторых аспектах? Возможно ли создание единой точки отказа или контроля, что повлияет на его децентрализованные характеристики?
Работа Rollup зависит от сортировщика, связанного с релейной цепочкой, а его коммуникация использует механизм, называемый протоколом коллатора. Этот протокол полностью без разрешений и без доверия, любой человек с сетевым подключением может использовать его, подключить небольшое количество узлов релейной цепочки и подать запросы на изменение состояния rollup. Эти запросы будут проверены на каком-то основном уровне релейной цепочки, при этом необходимо выполнить одно условие: они должны быть действительными изменениями состояния, иначе состояние этого rollup не будет продвинуто.
Торговля вертикальным расширением
Rollup может реализовать вертикальное масштабирование, используя многопроцессорную архитектуру Polkadot. Эта новая возможность была введена функцией "гибкого масштабирования". В процессе проектирования было обнаружено, что поскольку валидация блоков rollup не фиксируется на каком-то одном процессоре, это может повлиять на его гибкость.
Поскольку протокол подачи блока в релейную цепь является безразрешительным и бездоверительным, любой может отправить блок на любое ядро, назначенное для rollup, для его проверки. Злоумышленники могут воспользоваться этим, повторно отправляя ранее проверенные законные блоки на разные ядра, злоумышленно потребляя ресурсы и тем самым снижая общую пропускную способность и эффективность rollup.
Цель Polkadot состоит в том, чтобы поддерживать гибкость rollup и эффективное использование ресурсов релейной цепи без ущерба для ключевых характеристик системы.
Sequencer стоит ли доверять?
Одним из простых решений является установка протокола в режим "с разрешением": например, использование механизма белого списка или доверие к сортировщику по умолчанию, что обеспечит активность rollup.
Однако, в концепции дизайна Polkadot мы не можем делать никаких предположений о доверии к sequencer, поскольку необходимо поддерживать характеристики системы "без доверия" и "без разрешений". Любой должен иметь возможность использовать протокол collator для подачи запросов на изменение состояния rollup.
Polkadot: Непримиримое решение
Полкадот в конечном итоге выбрала решение: полностью передать проблему функции преобразования состояния rollup (Runtime). Runtime является единственным надежным источником всей информации о консенсусе, поэтому необходимо явно указать, на каком ядре Polkadot должно выполняться подтверждение.
Этот дизайн обеспечивает двойную защиту как гибкости, так и безопасности. Polkadot будет повторно выполнять преобразования состояния rollup в процессе доступности и обеспечивать правильность распределения core через экономический протокол ELVES.
Перед записью данных rollup блоков в уровень доступности данных Polkadot группа из примерно 5 валидаторов сначала проверит их законность. Они получают кандидатные квитанции и доказательства действительности, поданные сортировщиком, которые содержат rollup блоки и соответствующие доказательства хранения. Эта информация будет обработана функцией проверки параллельной цепи и повторно выполнена валидаторами на релейной цепи.
В результате проверки содержится селектор core, который указывает, на каком core следует проверять блок. Проверяющий сравнит этот индекс с тем, за который он отвечает; если они не совпадают, этот блок будет отброшен.
Этот механизм гарантирует, что система всегда сохраняет свойства, не требующие доверия и разрешений, предотвращая манипуляции со стороны злонамеренных игроков, таких как сортировщики, и обеспечивая устойчивость, даже если роллап использует несколько ядер.
безопасность
В процессе достижения масштабируемости Polkadot не пошел на компромисс в вопросах безопасности. Безопасность rollup обеспечивается релейной цепочкой, для поддержания жизнеспособности достаточно одного честного порядковщика.
С помощью протокола ELVES Polkadot полностью расширяет свою безопасность на все rollup, проверяя все вычисления на core, без необходимости налагать какие-либо ограничения или предположения на количество используемых core.
Таким образом, rollup Polkadot может обеспечить истинное масштабирование без ущерба для безопасности.
Универсальность
Гибкое масштабирование не ограничивает программируемость rollup. Модель rollup в Polkadot поддерживает выполнение вычислений с полным набором Тьюринга в среде WebAssembly, при условии, что одно выполнение завершается в течение 2 секунд. Благодаря гибкому масштабированию общий объем вычислений, выполняемых за период в 6 секунд, увеличивается, но тип вычислений не изменяется.
Сложность
Более высокая пропускная способность и более низкая задержка неизбежно вводят сложность, что является единственным приемлемым компромиссом в системном дизайне.
Rollup может динамически настраивать ресурсы через интерфейс Agile Coretime для поддержания согласованного уровня безопасности. Им также необходимо реализовать часть требований RFC103, чтобы адаптироваться к различным сценариям использования.
Конкретная сложность зависит от стратегии управления ресурсами rollup, которые могут полагаться на переменные в цепочке или вне цепочки. Например:
Простая стратегия: всегда использовать фиксированное количество core, или вручную регулировать через оффчейн;
Легкая стратегия: мониторинг определенной нагрузки транзакций в мемпуле узла;
Автоматизированная стратегия: предварительный вызов сервиса coretime через исторические данные и интерфейс XCM для настройки ресурсов.
Хотя автоматизированные методы более эффективны, стоимость их реализации и тестирования также значительно возрастает.
Интероперабельность
Polkadot поддерживает межоперабельность между различными rollup, а эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Сообщения между кросс-роллапами передаются через базовый уровень передачи, и пространство для коммуникационных блоков каждого роллапа фиксировано и не зависит от количества выделенных ядер.
В будущем Polkadot также будет поддерживать обмен сообщениями вне цепи, используя релейную цепь в качестве управляющей плоскости, а не в качестве плоскости данных. Это обновление повысит возможности связи между роллапами вместе с эластичным масштабированием, еще больше усиливая вертикальную масштабируемость системы.
Какие компромиссы сделали другие протоколы?
Как известно, повышение производительности часто достигается за счет жертвования децентрализацией и безопасностью. Однако, судя по коэффициенту Накамото, даже если некоторые конкуренты Polkadot имеют более низкий уровень децентрализации, их производительность также оставляет желать лучшего.
Солана
Solana не использует архитектуру шардирования Polkadot или Ethereum, а реализует масштабируемость с помощью одноуровневой архитектуры с высокой пропускной способностью, полагаясь на историческое доказательство (PoH), параллельную обработку CPU и механизм согласия на основе лидера, теоретически достигая TPS до 65 000.
Одним из ключевых элементов дизайна является его предварительно открытый и проверяемый механизм назначения лидеров:
В начале каждого эпохи (примерно каждые два дня или 432 000 слотов) слоты распределяются в зависимости от объема залога;
Чем больше заложено, тем больше распределение. Например, валидатор, ставящий на кон 1%, получит около 1% шансов на создание блока;
Все майнеры объявляются заранее, что увеличивает риск направленных DDoS-атак и частых сбоев сети.
PoH и параллельная обработка предъявляют высокие требования к аппаратному обеспечению, что приводит к централизации узлов проверки. Чем больше узлов ставится, тем больше шанс на создание блока, в то время как у малых узлов практически нет слотов, что еще больше усиливает централизацию и увеличивает риск паралича системы после атаки.
Solana жертвует децентрализацией и устойчивостью к атакам в стремлении к TPS, его коэффициент Накамото составляет всего 20, что значительно ниже, чем у Polkadot, равного 172.
ТОН
TON утверждает, что TPS может достигать 104715, но это число было получено в частной тестовой сети при 256 узлах, идеальных условиях сети и аппаратного обеспечения. В то время как Polkadot уже достиг 128K TPS в децентрализованной публичной сети.
У механизма консенсуса TON есть уязвимости безопасности: идентичность узлов верификации шардов может быть заранее раскрыта. В белой книге TON также четко указано, что хотя это может оптимизировать пропускную способность, это также может быть использовано злоумышленниками. Из-за отсутствия механизма "банкротства игрока" атакующий может дождаться, когда какой-либо шар будет полностью контролироваться им, или с помощью DDoS-атаки заблокировать честных верификаторов, тем самым изменяя состояние.
В отличие от этого, валидаторы Polkadot распределяются случайным образом и раскрываются с задержкой, злоумышленники не могут заранее узнать идентичность валидатора, атака требует ставить всю контрольную сумму на успех, если хотя бы один честный валидатор инициирует спор, атака потерпит неудачу и приведет к потерям залога злоумышленника.
Авала́нш
Avalanche использует архитектуру основной сети + подсетей для масштабирования. Основная сеть состоит из X-Chain (переводы, ~4,500 TPS), C-Chain (умные контракты, ~100-200 TPS) и P-Chain (управление валидаторами и подсетями).
Теоретическая TPS каждой подсети может достигать ~5,000, аналогично подходу Polkadot: уменьшение нагрузки на отдельный Блок для обеспечения масштабируемости. Однако Avalanche позволяет валидаторам свободно выбирать участие в подсетях, и подсети могут устанавливать дополнительные требования, такие как географические ограничения и KYC, жертвуя децентрализацией и безопасностью.
В Polkadot все роллапы делят единую систему безопасности; в то время как под сети Avalanche не имеют гарантии безопасности по умолчанию, некоторые из них могут быть полностью централизованными. Если вы хотите повысить безопасность, вам всё равно придется пойти на компромиссы по производительности, и трудно обеспечить детерминированные обещания безопасности.
Эфириум
Стратегия масштабирования Ethereum заключается в ставках на масштабируемость уровня rollup, а не в прямом решении проблем на базовом уровне. Этот подход по сути не решает проблему, а передает ее на уровень выше в стеке.
Оптимистичный Роллап
В настоящее время большинство оптимистичных роллапов централизованы (некоторые даже имеют только один секвенсер), что приводит к недостаточной безопасности, изолированности друг от друга и высокой задержке (необходимо дождаться периода подтверждения мошенничества, который обычно составляет несколько дней).
ZK Rollup
Реализация ZK rollup ограничена объемом данных, которые могут обрабатываться за одну транзакцию. Вычислительные требования для генерации нулевых доказательств крайне высоки, и механика "победитель получает все" может привести к централизации системы. Чтобы обеспечить TPS, ZK rollup часто ограничивает объем транзакций в каждой партии, что в условиях высокого спроса может вызвать перегрузку сети, рост газов и ухудшение пользовательского опыта.
Сравнительно, стоимость ZK rollup с полной вычислительной мощностью Тьюринга примерно в 2x10^6 раз выше, чем безопасность экономического протокола ядра Polkadot.
Кроме того, проблема доступности данных ZK rollup также усугубляет его недостатки. Для обеспечения возможности проверки транзакций любым желающим необходимо предоставление полных данных о транзакциях. Это обычно зависит от дополнительных решений по доступности данных, что еще больше увеличивает затраты и расходы пользователей.
Заключение
Конец масштабируемости не должен быть компромиссом.
В отличие от других публичных цепочек, Polkadot не пошел по пути централизации ради производительности и предварительно заданного доверия ради эффективности, а вместо этого достиг многомерного баланса безопасности, децентрализации и высокой производительности через гибкое масштабирование, проектирование без разрешений, унифицированный уровень безопасности и гибкие механизмы управления ресурсами.
В условиях стремления к более крупным масштабам применения, "нулевая доверительная расширяемость", которой придерживается Polkadot, возможно, является истинным решением, способствующим долгосрочному развитию Web3.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Гибкое масштабирование Polkadot: решение без компромиссов в экосистеме Web3
Баланс расширяемости Блокчейн: Выбор между Polkadot и Web3
В эпоху, когда технологии Блокчейн постоянно стремятся к более высокой эффективности, постепенно возникает ключевая проблема: как повысить производительность, одновременно сохраняя безопасность и устойчивость системы? Это не только технический вызов, но и глубокий выбор архитектурного проектирования. Для экосистемы Web3 система, которая лишь быстрее, если она основана на жертве доверия и безопасности, часто не может поддерживать действительно устойчивые инновации.
Как важный движущий фактор масштабируемости Web3, делает ли Polkadot какие-то компромиссы в процессе достижения высокой пропускной способности и низкой задержки? Делает ли его модель rollup уступки в децентрализации, безопасности или сетевой интероперабельности? В этой статье будут обсуждены эти вопросы, глубоко проанализированы компромиссы и взвешивания Polkadot в дизайне масштабируемости, а также проведено сравнение с решениями других основных публичных блокчейнов, исследуя их различные выборы путей в производительности, безопасности и децентрализации.
Проблемы, с которыми сталкивается дизайн расширения Polkadot
Баланс между гибкостью и децентрализацией
Архитектура Polkadot зависит от сети валидаторов и централизованной релейной цепи, может ли это потенциально ввести риски централизации в некоторых аспектах? Возможно ли создание единой точки отказа или контроля, что повлияет на его децентрализованные характеристики?
Работа Rollup зависит от сортировщика, связанного с релейной цепочкой, а его коммуникация использует механизм, называемый протоколом коллатора. Этот протокол полностью без разрешений и без доверия, любой человек с сетевым подключением может использовать его, подключить небольшое количество узлов релейной цепочки и подать запросы на изменение состояния rollup. Эти запросы будут проверены на каком-то основном уровне релейной цепочки, при этом необходимо выполнить одно условие: они должны быть действительными изменениями состояния, иначе состояние этого rollup не будет продвинуто.
Торговля вертикальным расширением
Rollup может реализовать вертикальное масштабирование, используя многопроцессорную архитектуру Polkadot. Эта новая возможность была введена функцией "гибкого масштабирования". В процессе проектирования было обнаружено, что поскольку валидация блоков rollup не фиксируется на каком-то одном процессоре, это может повлиять на его гибкость.
Поскольку протокол подачи блока в релейную цепь является безразрешительным и бездоверительным, любой может отправить блок на любое ядро, назначенное для rollup, для его проверки. Злоумышленники могут воспользоваться этим, повторно отправляя ранее проверенные законные блоки на разные ядра, злоумышленно потребляя ресурсы и тем самым снижая общую пропускную способность и эффективность rollup.
Цель Polkadot состоит в том, чтобы поддерживать гибкость rollup и эффективное использование ресурсов релейной цепи без ущерба для ключевых характеристик системы.
Sequencer стоит ли доверять?
Одним из простых решений является установка протокола в режим "с разрешением": например, использование механизма белого списка или доверие к сортировщику по умолчанию, что обеспечит активность rollup.
Однако, в концепции дизайна Polkadot мы не можем делать никаких предположений о доверии к sequencer, поскольку необходимо поддерживать характеристики системы "без доверия" и "без разрешений". Любой должен иметь возможность использовать протокол collator для подачи запросов на изменение состояния rollup.
Polkadot: Непримиримое решение
Полкадот в конечном итоге выбрала решение: полностью передать проблему функции преобразования состояния rollup (Runtime). Runtime является единственным надежным источником всей информации о консенсусе, поэтому необходимо явно указать, на каком ядре Polkadot должно выполняться подтверждение.
Этот дизайн обеспечивает двойную защиту как гибкости, так и безопасности. Polkadot будет повторно выполнять преобразования состояния rollup в процессе доступности и обеспечивать правильность распределения core через экономический протокол ELVES.
Перед записью данных rollup блоков в уровень доступности данных Polkadot группа из примерно 5 валидаторов сначала проверит их законность. Они получают кандидатные квитанции и доказательства действительности, поданные сортировщиком, которые содержат rollup блоки и соответствующие доказательства хранения. Эта информация будет обработана функцией проверки параллельной цепи и повторно выполнена валидаторами на релейной цепи.
В результате проверки содержится селектор core, который указывает, на каком core следует проверять блок. Проверяющий сравнит этот индекс с тем, за который он отвечает; если они не совпадают, этот блок будет отброшен.
Этот механизм гарантирует, что система всегда сохраняет свойства, не требующие доверия и разрешений, предотвращая манипуляции со стороны злонамеренных игроков, таких как сортировщики, и обеспечивая устойчивость, даже если роллап использует несколько ядер.
безопасность
В процессе достижения масштабируемости Polkadot не пошел на компромисс в вопросах безопасности. Безопасность rollup обеспечивается релейной цепочкой, для поддержания жизнеспособности достаточно одного честного порядковщика.
С помощью протокола ELVES Polkadot полностью расширяет свою безопасность на все rollup, проверяя все вычисления на core, без необходимости налагать какие-либо ограничения или предположения на количество используемых core.
Таким образом, rollup Polkadot может обеспечить истинное масштабирование без ущерба для безопасности.
Универсальность
Гибкое масштабирование не ограничивает программируемость rollup. Модель rollup в Polkadot поддерживает выполнение вычислений с полным набором Тьюринга в среде WebAssembly, при условии, что одно выполнение завершается в течение 2 секунд. Благодаря гибкому масштабированию общий объем вычислений, выполняемых за период в 6 секунд, увеличивается, но тип вычислений не изменяется.
Сложность
Более высокая пропускная способность и более низкая задержка неизбежно вводят сложность, что является единственным приемлемым компромиссом в системном дизайне.
Rollup может динамически настраивать ресурсы через интерфейс Agile Coretime для поддержания согласованного уровня безопасности. Им также необходимо реализовать часть требований RFC103, чтобы адаптироваться к различным сценариям использования.
Конкретная сложность зависит от стратегии управления ресурсами rollup, которые могут полагаться на переменные в цепочке или вне цепочки. Например:
Простая стратегия: всегда использовать фиксированное количество core, или вручную регулировать через оффчейн;
Легкая стратегия: мониторинг определенной нагрузки транзакций в мемпуле узла;
Автоматизированная стратегия: предварительный вызов сервиса coretime через исторические данные и интерфейс XCM для настройки ресурсов.
Хотя автоматизированные методы более эффективны, стоимость их реализации и тестирования также значительно возрастает.
Интероперабельность
Polkadot поддерживает межоперабельность между различными rollup, а эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Сообщения между кросс-роллапами передаются через базовый уровень передачи, и пространство для коммуникационных блоков каждого роллапа фиксировано и не зависит от количества выделенных ядер.
В будущем Polkadot также будет поддерживать обмен сообщениями вне цепи, используя релейную цепь в качестве управляющей плоскости, а не в качестве плоскости данных. Это обновление повысит возможности связи между роллапами вместе с эластичным масштабированием, еще больше усиливая вертикальную масштабируемость системы.
Какие компромиссы сделали другие протоколы?
Как известно, повышение производительности часто достигается за счет жертвования децентрализацией и безопасностью. Однако, судя по коэффициенту Накамото, даже если некоторые конкуренты Polkadot имеют более низкий уровень децентрализации, их производительность также оставляет желать лучшего.
Солана
Solana не использует архитектуру шардирования Polkadot или Ethereum, а реализует масштабируемость с помощью одноуровневой архитектуры с высокой пропускной способностью, полагаясь на историческое доказательство (PoH), параллельную обработку CPU и механизм согласия на основе лидера, теоретически достигая TPS до 65 000.
Одним из ключевых элементов дизайна является его предварительно открытый и проверяемый механизм назначения лидеров:
В начале каждого эпохи (примерно каждые два дня или 432 000 слотов) слоты распределяются в зависимости от объема залога;
Чем больше заложено, тем больше распределение. Например, валидатор, ставящий на кон 1%, получит около 1% шансов на создание блока;
Все майнеры объявляются заранее, что увеличивает риск направленных DDoS-атак и частых сбоев сети.
PoH и параллельная обработка предъявляют высокие требования к аппаратному обеспечению, что приводит к централизации узлов проверки. Чем больше узлов ставится, тем больше шанс на создание блока, в то время как у малых узлов практически нет слотов, что еще больше усиливает централизацию и увеличивает риск паралича системы после атаки.
Solana жертвует децентрализацией и устойчивостью к атакам в стремлении к TPS, его коэффициент Накамото составляет всего 20, что значительно ниже, чем у Polkadot, равного 172.
ТОН
TON утверждает, что TPS может достигать 104715, но это число было получено в частной тестовой сети при 256 узлах, идеальных условиях сети и аппаратного обеспечения. В то время как Polkadot уже достиг 128K TPS в децентрализованной публичной сети.
У механизма консенсуса TON есть уязвимости безопасности: идентичность узлов верификации шардов может быть заранее раскрыта. В белой книге TON также четко указано, что хотя это может оптимизировать пропускную способность, это также может быть использовано злоумышленниками. Из-за отсутствия механизма "банкротства игрока" атакующий может дождаться, когда какой-либо шар будет полностью контролироваться им, или с помощью DDoS-атаки заблокировать честных верификаторов, тем самым изменяя состояние.
В отличие от этого, валидаторы Polkadot распределяются случайным образом и раскрываются с задержкой, злоумышленники не могут заранее узнать идентичность валидатора, атака требует ставить всю контрольную сумму на успех, если хотя бы один честный валидатор инициирует спор, атака потерпит неудачу и приведет к потерям залога злоумышленника.
Авала́нш
Avalanche использует архитектуру основной сети + подсетей для масштабирования. Основная сеть состоит из X-Chain (переводы, ~4,500 TPS), C-Chain (умные контракты, ~100-200 TPS) и P-Chain (управление валидаторами и подсетями).
Теоретическая TPS каждой подсети может достигать ~5,000, аналогично подходу Polkadot: уменьшение нагрузки на отдельный Блок для обеспечения масштабируемости. Однако Avalanche позволяет валидаторам свободно выбирать участие в подсетях, и подсети могут устанавливать дополнительные требования, такие как географические ограничения и KYC, жертвуя децентрализацией и безопасностью.
В Polkadot все роллапы делят единую систему безопасности; в то время как под сети Avalanche не имеют гарантии безопасности по умолчанию, некоторые из них могут быть полностью централизованными. Если вы хотите повысить безопасность, вам всё равно придется пойти на компромиссы по производительности, и трудно обеспечить детерминированные обещания безопасности.
Эфириум
Стратегия масштабирования Ethereum заключается в ставках на масштабируемость уровня rollup, а не в прямом решении проблем на базовом уровне. Этот подход по сути не решает проблему, а передает ее на уровень выше в стеке.
Оптимистичный Роллап
В настоящее время большинство оптимистичных роллапов централизованы (некоторые даже имеют только один секвенсер), что приводит к недостаточной безопасности, изолированности друг от друга и высокой задержке (необходимо дождаться периода подтверждения мошенничества, который обычно составляет несколько дней).
ZK Rollup
Реализация ZK rollup ограничена объемом данных, которые могут обрабатываться за одну транзакцию. Вычислительные требования для генерации нулевых доказательств крайне высоки, и механика "победитель получает все" может привести к централизации системы. Чтобы обеспечить TPS, ZK rollup часто ограничивает объем транзакций в каждой партии, что в условиях высокого спроса может вызвать перегрузку сети, рост газов и ухудшение пользовательского опыта.
Сравнительно, стоимость ZK rollup с полной вычислительной мощностью Тьюринга примерно в 2x10^6 раз выше, чем безопасность экономического протокола ядра Polkadot.
Кроме того, проблема доступности данных ZK rollup также усугубляет его недостатки. Для обеспечения возможности проверки транзакций любым желающим необходимо предоставление полных данных о транзакциях. Это обычно зависит от дополнительных решений по доступности данных, что еще больше увеличивает затраты и расходы пользователей.
Заключение
Конец масштабируемости не должен быть компромиссом.
В отличие от других публичных цепочек, Polkadot не пошел по пути централизации ради производительности и предварительно заданного доверия ради эффективности, а вместо этого достиг многомерного баланса безопасности, децентрализации и высокой производительности через гибкое масштабирование, проектирование без разрешений, унифицированный уровень безопасности и гибкие механизмы управления ресурсами.
В условиях стремления к более крупным масштабам применения, "нулевая доверительная расширяемость", которой придерживается Polkadot, возможно, является истинным решением, способствующим долгосрочному развитию Web3.