Балансировка масштабируемости Блокчейна: выбор между Polkadot и Web3
В эпоху постоянного стремления к повышению эффективности в Блокчейн, ключевая проблема постепенно выходит на поверхность: как обеспечить расширение производительности, не жертвуя безопасностью и гибкостью системы?
Это не только технологический вызов, но и глубокий выбор архитектурного дизайна. Для экосистемы Web3 стремление к более быстрому системному решению, игнорируя доверие и безопасность, не сможет поддержать по-настоящему устойчивые инновации.
В качестве важного катализатора масштабируемости Web3, совершил ли Polkadot какие-то компромиссы в стремлении к высокой пропускной способности и низкой задержке? Не было ли компромиссов в его модели rollup в отношении децентрализации, безопасности или межсетевой совместимости?
В данной статье будет обсуждаться эти вопросы, подробно анализируя компромиссы Polkadot в дизайне масштабируемости и сравнивая их с решениями других основных публичных цепочек, исследуя их различные выборы в области производительности, безопасности и децентрализации.
Проблемы, с которыми сталкивается дизайн расширения Polkadot
Баланс между гибкостью и децентрализацией
Архитектура Polkadot зависит от сети валидаторов и релейной цепи, может ли это в некоторых аспектах привести к рискам централизации? Возможно ли возникновение единой точки отказа или контроля, что может повлиять на ее децентрализованные характеристики?
Работа Rollup зависит от сортировщика промежуточной цепи, а его связь использует механизм протокола collator. Этот протокол полностью не требует разрешения и доверия, любой, кто имеет сетевое соединение, может им пользоваться, подключаясь к небольшому количеству узлов промежуточной цепи и отправляя запросы на изменение состояния rollup. Эти запросы будут проверены каким-либо core промежуточной цепи, при этом необходимо выполнить одно условие: изменение состояния должно быть действительным, в противном случае состояние rollup не будет продвинуто.
Торговля вертикальным расширением
Rollup может достигать вертикального масштабирования, используя многопроцессорную архитектуру Polkadot. Эта новая возможность была введена функцией «гибкого масштабирования». В процессе проектирования было обнаружено, что поскольку проверка блоков rollup не фиксируется на определенном ядре, это может повлиять на его гибкость.
Поскольку протокол подачи блоков в релейную цепь является без разрешения и без доверия, любой может подавать блоки для проверки на любом ядре, назначенном для rollup. Нападающие могут воспользоваться этим, повторно отправляя ранее проверенные легитимные блоки на разные ядра, злоумышленно потребляя ресурсы, тем самым снижая общую пропускную способность и эффективность rollup.
Цель Polkadot состоит в том, чтобы поддерживать гибкость rollup и эффективное использование ресурсов релейной цепи, не влияя на ключевые характеристики системы.
Доверять Sequencer?
Одним из простых решений является установка протокола в режим "с лицензией": например, использование механизма белого списка или предположение о том, что доверенный сортировщик не будет вести себя злонамеренно, что обеспечит активность rollup.
Однако в концепции дизайна Polkadot мы не можем делать никаких доверительных предположений относительно секвенсера, поскольку необходимо сохранять характеристики системы «без доверия» и «без разрешений». Любой человек должен иметь возможность использовать протокол коллатора для подачи запросов на изменение состояния роллапа.
Polkadot: Непромежуточное решение
Полкадот в конечном итоге выбрала решение: полностью передать проблему функции преобразования состояния rollup (Runtime). Runtime является единственным надежным источником всей информации о консенсусе, поэтому в выводе необходимо четко указать, на каком ядре Polkadot выполнять проверку.
Данный дизайн обеспечивает двойную защиту как гибкости, так и безопасности. Polkadot будет повторно выполнять переход состояния rollup в процессе доступности и обеспечивать правильность распределения core через экономический протокол ELVES.
Перед записью данных о rollup блоках в слой доступности данных Polkadot, небольшая группа из около 5 валидаторов сначала проверяет их законность. Они получают кандидаты на подтверждение и доказательства действительности, представленные сортировщиком, которые содержат rollup блок и соответствующее доказательство хранения. Эта информация будет обработана функцией проверки параллельной цепи и повторно выполнена валидаторами на релейной цепи.
В результате проверки содержится селектор core, который указывает, на каком core следует проверять блок. Проверяющий сравнит этот индекс с тем, за который он отвечает; если они не совпадают, блок будет отброшен.
Механизм гарантирует, что система всегда сохраняет свойства, не требующие доверия и разрешения, избегая манипуляций со стороны злонамеренных участников, таких как сортировщики, и обеспечивая, что даже при использовании нескольких ядер в rollup сохраняется устойчивость.
Безопасность
В процессе достижения масштабируемости Polkadot не пошел на компромисс в вопросах безопасности. Безопасность rollup обеспечивается релейной цепью, и для поддержания жизнеспособности достаточно одного честного сортировщика.
С помощью протокола ELVES Polkadot полностью расширяет свою безопасность на все роллапы, проверяя все вычисления на основных узлах, без необходимости устанавливать какие-либо ограничения или предположения по количеству используемых основных узлов.
Таким образом, rollup Polkadot может обеспечить настоящее масштабирование без ущерба для безопасности.
Универсальность
Эластичное масштабирование не ограничивает программируемость роллапов. Модель роллапов Polkadot поддерживает выполнение тьюринговых вычислений в среде WebAssembly, при условии, что одно выполнение завершается в пределах 2 секунд. С помощью эластичного масштабирования общее количество выполняемых вычислений за каждые 6 секунд увеличивается, но типы вычислений не затрагиваются.
Сложность
Более высокая пропускная способность и более низкая задержка неизбежно вводят сложность, что является единственным приемлемым компромиссом в проектировании систем.
Rollup может динамически настраивать ресурсы через интерфейс Agile Coretime для поддержания постоянного уровня безопасности. Им также необходимо выполнить часть требований RFC103 для адаптации к различным сценариям использования.
Конкретная сложность зависит от стратегии управления ресурсами rollup, которые могут зависеть от переменных на цепочке или вне цепочки. Например:
Простая стратегия: всегда используйте фиксированное количество core или вручную настраивайте вне цепи;
Легкая стратегия: мониторинг определенной нагрузки транзакций в мемпуле узла;
Автоматизированная стратегия: предварительная настройка ресурсов через сервис coretime с использованием исторических данных и интерфейса XCM.
Хотя автоматизированный способ более эффективен, затраты на его реализацию и тестирование также значительно возрастают.
Интероперабельность
Polkadot поддерживает интероперабельность между различными роллапами, при этом эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Сообщения между кросс-роллапами реализуются на основе нижнего транспортного уровня, пространство коммуникационных блоков каждого роллапа фиксировано и не зависит от количества выделенных ядер.
В будущем Polkadot также будет поддерживать межсетевую передачу сообщений, используя релейную цепь в качестве контрольной плоскости, а не плоскости данных. Это обновление повысит возможности связи между rollup в соответствии с эластичным масштабированием, что дополнительно усилит вертикальные возможности масштабирования системы.
Балансы других протоколов
Как известно, повышение производительности часто достигается за счет жертвы децентрализацией и безопасностью. Однако, судя по коэффициенту Накамото, даже если степень децентрализации некоторых конкурентов Polkadot ниже, их производительность также оставляет желать лучшего.
Солана
Solana не использует архитектуру шардинга Polkadot или Ethereum, а реализует масштабируемость с помощью одноуровневой высокопроизводительной архитектуры, полагаясь на доказательство истории (PoH), параллельную обработку CPU и механизм консенсуса на основе лидера, теоретическая TPS может достигать 65 000.
Ключевым дизайном является его заранее открытый и проверяемый механизм распределения лидеров:
В начале каждого эпохи (примерно через два дня или 432 000 слотов) слоты распределяются в зависимости от объема стейкинга;
Чем больше залог, тем больше распределение. Например, валидатор, ставящий 1%, получит примерно 1% шанс на создание блока;
Все майнеры заранее объявлены, что увеличивает риск целенаправленных DDoS-атак на сеть и частых сбоев.
PoH и параллельная обработка предъявляют высокие требования к оборудованию, что приводит к централизации узлов проверки. Чем больше узлов ставят, тем больше у них шансов на создание блока, у небольших узлов практически нет слотов, что еще больше усугубляет централизацию и увеличивает риск паралича системы после атаки.
Solana, стремясь к высокой пропускной способности TPS, пожертвовала децентрализацией и устойчивостью к атакам, ее коэффициент Накамото составляет всего 20, что значительно ниже, чем у Polkadot, равного 172.
ТОННА
TON заявляет, что TPS может достигать 104,715, но это число было достигнуто в частной тестовой сети, с 256 узлами, при идеальных условиях сети и оборудования. В то же время Polkadot уже достиг 128K TPS на децентрализованной публичной сети.
У механизма консенсуса TON есть уязвимости в безопасности: личность узлов валидации шардов может быть раскрыта заранее. В белой книге TON также четко указано, что это может оптимизировать пропускную способность, но также может быть использовано злонамеренно. Из-за отсутствия механизма "банкротства игрока" злоумышленники могут дождаться, когда какой-либо шард будет полностью под их контролем, или с помощью DDoS-атаки блокировать честных валидаторов, тем самым изменяя состояние.
В отличие от этого, валидаторы Polkadot назначаются случайным образом и вскрываются с задержкой, что не позволяет злоумышленникам заранее узнать идентичность валидаторов. Атакующий должен рискнуть всей контролируемой суммой для успешного нападения, и если хотя бы один честный валидатор поднимет спор, атака потерпит неудачу и приведет к потерям для злоумышленника.
Аваланш
Avalanche использует архитектуру основной сети + подсетей для расширения, где основная сеть состоит из X-Chain (переводы, ~4,500 TPS), C-Chain (умные контракты, ~100-200 TPS) и P-Chain (управление валидаторами и подсетями).
Теоретическая TPS каждой подсети может достигать ~5000, аналогично подходу 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 или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
16 Лайков
Награда
16
6
Репост
Поделиться
комментарий
0/400
Fren_Not_Food
· 07-23 13:22
Проект выглядит неплохо, посмотрим на фактические результаты.
Посмотреть ОригиналОтветить0
BlockchainDecoder
· 07-23 11:10
Ссылаясь на недавние данные исследовательской группы Cho, одноканальная пропускная способность TPS в основном ниже 3k, проблема компромисса требует срочного решения.
Polkadot без компромиссов в масштабируемости: новый выбор для экосистемы Web3
Балансировка масштабируемости Блокчейна: выбор между Polkadot и Web3
В эпоху постоянного стремления к повышению эффективности в Блокчейн, ключевая проблема постепенно выходит на поверхность: как обеспечить расширение производительности, не жертвуя безопасностью и гибкостью системы?
Это не только технологический вызов, но и глубокий выбор архитектурного дизайна. Для экосистемы Web3 стремление к более быстрому системному решению, игнорируя доверие и безопасность, не сможет поддержать по-настоящему устойчивые инновации.
В качестве важного катализатора масштабируемости Web3, совершил ли Polkadot какие-то компромиссы в стремлении к высокой пропускной способности и низкой задержке? Не было ли компромиссов в его модели rollup в отношении децентрализации, безопасности или межсетевой совместимости?
В данной статье будет обсуждаться эти вопросы, подробно анализируя компромиссы Polkadot в дизайне масштабируемости и сравнивая их с решениями других основных публичных цепочек, исследуя их различные выборы в области производительности, безопасности и децентрализации.
Проблемы, с которыми сталкивается дизайн расширения Polkadot
Баланс между гибкостью и децентрализацией
Архитектура Polkadot зависит от сети валидаторов и релейной цепи, может ли это в некоторых аспектах привести к рискам централизации? Возможно ли возникновение единой точки отказа или контроля, что может повлиять на ее децентрализованные характеристики?
Работа Rollup зависит от сортировщика промежуточной цепи, а его связь использует механизм протокола collator. Этот протокол полностью не требует разрешения и доверия, любой, кто имеет сетевое соединение, может им пользоваться, подключаясь к небольшому количеству узлов промежуточной цепи и отправляя запросы на изменение состояния rollup. Эти запросы будут проверены каким-либо core промежуточной цепи, при этом необходимо выполнить одно условие: изменение состояния должно быть действительным, в противном случае состояние rollup не будет продвинуто.
Торговля вертикальным расширением
Rollup может достигать вертикального масштабирования, используя многопроцессорную архитектуру Polkadot. Эта новая возможность была введена функцией «гибкого масштабирования». В процессе проектирования было обнаружено, что поскольку проверка блоков rollup не фиксируется на определенном ядре, это может повлиять на его гибкость.
Поскольку протокол подачи блоков в релейную цепь является без разрешения и без доверия, любой может подавать блоки для проверки на любом ядре, назначенном для rollup. Нападающие могут воспользоваться этим, повторно отправляя ранее проверенные легитимные блоки на разные ядра, злоумышленно потребляя ресурсы, тем самым снижая общую пропускную способность и эффективность rollup.
Цель Polkadot состоит в том, чтобы поддерживать гибкость rollup и эффективное использование ресурсов релейной цепи, не влияя на ключевые характеристики системы.
Доверять Sequencer?
Одним из простых решений является установка протокола в режим "с лицензией": например, использование механизма белого списка или предположение о том, что доверенный сортировщик не будет вести себя злонамеренно, что обеспечит активность rollup.
Однако в концепции дизайна Polkadot мы не можем делать никаких доверительных предположений относительно секвенсера, поскольку необходимо сохранять характеристики системы «без доверия» и «без разрешений». Любой человек должен иметь возможность использовать протокол коллатора для подачи запросов на изменение состояния роллапа.
Polkadot: Непромежуточное решение
Полкадот в конечном итоге выбрала решение: полностью передать проблему функции преобразования состояния rollup (Runtime). Runtime является единственным надежным источником всей информации о консенсусе, поэтому в выводе необходимо четко указать, на каком ядре Polkadot выполнять проверку.
Данный дизайн обеспечивает двойную защиту как гибкости, так и безопасности. Polkadot будет повторно выполнять переход состояния rollup в процессе доступности и обеспечивать правильность распределения core через экономический протокол ELVES.
Перед записью данных о rollup блоках в слой доступности данных Polkadot, небольшая группа из около 5 валидаторов сначала проверяет их законность. Они получают кандидаты на подтверждение и доказательства действительности, представленные сортировщиком, которые содержат rollup блок и соответствующее доказательство хранения. Эта информация будет обработана функцией проверки параллельной цепи и повторно выполнена валидаторами на релейной цепи.
В результате проверки содержится селектор core, который указывает, на каком core следует проверять блок. Проверяющий сравнит этот индекс с тем, за который он отвечает; если они не совпадают, блок будет отброшен.
Механизм гарантирует, что система всегда сохраняет свойства, не требующие доверия и разрешения, избегая манипуляций со стороны злонамеренных участников, таких как сортировщики, и обеспечивая, что даже при использовании нескольких ядер в rollup сохраняется устойчивость.
Безопасность
В процессе достижения масштабируемости Polkadot не пошел на компромисс в вопросах безопасности. Безопасность rollup обеспечивается релейной цепью, и для поддержания жизнеспособности достаточно одного честного сортировщика.
С помощью протокола ELVES Polkadot полностью расширяет свою безопасность на все роллапы, проверяя все вычисления на основных узлах, без необходимости устанавливать какие-либо ограничения или предположения по количеству используемых основных узлов.
Таким образом, rollup Polkadot может обеспечить настоящее масштабирование без ущерба для безопасности.
Универсальность
Эластичное масштабирование не ограничивает программируемость роллапов. Модель роллапов Polkadot поддерживает выполнение тьюринговых вычислений в среде WebAssembly, при условии, что одно выполнение завершается в пределах 2 секунд. С помощью эластичного масштабирования общее количество выполняемых вычислений за каждые 6 секунд увеличивается, но типы вычислений не затрагиваются.
Сложность
Более высокая пропускная способность и более низкая задержка неизбежно вводят сложность, что является единственным приемлемым компромиссом в проектировании систем.
Rollup может динамически настраивать ресурсы через интерфейс Agile Coretime для поддержания постоянного уровня безопасности. Им также необходимо выполнить часть требований RFC103 для адаптации к различным сценариям использования.
Конкретная сложность зависит от стратегии управления ресурсами rollup, которые могут зависеть от переменных на цепочке или вне цепочки. Например:
Хотя автоматизированный способ более эффективен, затраты на его реализацию и тестирование также значительно возрастают.
Интероперабельность
Polkadot поддерживает интероперабельность между различными роллапами, при этом эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Сообщения между кросс-роллапами реализуются на основе нижнего транспортного уровня, пространство коммуникационных блоков каждого роллапа фиксировано и не зависит от количества выделенных ядер.
В будущем Polkadot также будет поддерживать межсетевую передачу сообщений, используя релейную цепь в качестве контрольной плоскости, а не плоскости данных. Это обновление повысит возможности связи между rollup в соответствии с эластичным масштабированием, что дополнительно усилит вертикальные возможности масштабирования системы.
Балансы других протоколов
Как известно, повышение производительности часто достигается за счет жертвы децентрализацией и безопасностью. Однако, судя по коэффициенту Накамото, даже если степень децентрализации некоторых конкурентов Polkadot ниже, их производительность также оставляет желать лучшего.
Солана
Solana не использует архитектуру шардинга Polkadot или Ethereum, а реализует масштабируемость с помощью одноуровневой высокопроизводительной архитектуры, полагаясь на доказательство истории (PoH), параллельную обработку CPU и механизм консенсуса на основе лидера, теоретическая TPS может достигать 65 000.
Ключевым дизайном является его заранее открытый и проверяемый механизм распределения лидеров:
PoH и параллельная обработка предъявляют высокие требования к оборудованию, что приводит к централизации узлов проверки. Чем больше узлов ставят, тем больше у них шансов на создание блока, у небольших узлов практически нет слотов, что еще больше усугубляет централизацию и увеличивает риск паралича системы после атаки.
Solana, стремясь к высокой пропускной способности TPS, пожертвовала децентрализацией и устойчивостью к атакам, ее коэффициент Накамото составляет всего 20, что значительно ниже, чем у Polkadot, равного 172.
ТОННА
TON заявляет, что TPS может достигать 104,715, но это число было достигнуто в частной тестовой сети, с 256 узлами, при идеальных условиях сети и оборудования. В то же время Polkadot уже достиг 128K TPS на децентрализованной публичной сети.
У механизма консенсуса TON есть уязвимости в безопасности: личность узлов валидации шардов может быть раскрыта заранее. В белой книге TON также четко указано, что это может оптимизировать пропускную способность, но также может быть использовано злонамеренно. Из-за отсутствия механизма "банкротства игрока" злоумышленники могут дождаться, когда какой-либо шард будет полностью под их контролем, или с помощью DDoS-атаки блокировать честных валидаторов, тем самым изменяя состояние.
В отличие от этого, валидаторы Polkadot назначаются случайным образом и вскрываются с задержкой, что не позволяет злоумышленникам заранее узнать идентичность валидаторов. Атакующий должен рискнуть всей контролируемой суммой для успешного нападения, и если хотя бы один честный валидатор поднимет спор, атака потерпит неудачу и приведет к потерям для злоумышленника.
Аваланш
Avalanche использует архитектуру основной сети + подсетей для расширения, где основная сеть состоит из X-Chain (переводы, ~4,500 TPS), C-Chain (умные контракты, ~100-200 TPS) и P-Chain (управление валидаторами и подсетями).
Теоретическая TPS каждой подсети может достигать ~5000, аналогично подходу Polkadot: снижение нагрузки на отдельный шард для достижения масштабируемости. Но Avalanche позволяет валидаторам свободно выбирать участие в подсетях, и подсети могут устанавливать дополнительные требования, такие как географические или KYC, жертвуя децентрализацией и безопасностью.
В Polkadot все роллапы разделяют единую безопасность; в то время как подсети Avalanche не имеют стандартной гарантии безопасности, некоторые из них могут быть полностью централизованными. Если вы хотите повысить безопасность, вам все равно придется пойти на компромисс в производительности, и трудно предоставить определенные гарантии безопасности.
Эфириум
Стратегия масштабирования Ethereum заключается в ставке на масштабируемость уровня rollup, а не в непосредственном решении проблем на базовом уровне. Этот подход по сути не решает проблему, а передает её на уровень выше в стеке.
Оптимистичный роллап
В настоящее время большинство оптимистичных роллапов централизованы (некоторые из них имеют только один секвенсер), что приводит к недостаточной безопасности, изолированности друг от друга и высокой задержке (необходимо ожидание периода доказательства мошенничества, который обычно длится несколько дней).
ZK Rollup
Реализация ZK rollup ограничена объемом данных, которые могут быть обработаны за одну транзакцию. Требования к вычислениям для генерации нулевых доказательств очень высоки, а механизм "победитель получает все" может привести к централизации системы. Для обеспечения TPS ZK rollup часто ограничивает объем транзакций в каждой партии, что в условиях высокого спроса может вызвать сетевые перегрузки, рост газовых сборов и негативно сказаться на пользовательском опыте.
В сравнении, стоимость ZK rollup с полной вычислительной способностью Тьюринга примерно в 2x10^6 раз выше, чем стоимость безопасного протокола экономической безопасности ядра Polkadot.
Кроме того, проблема доступности данных ZK rollup также усугубит его недостатки. Чтобы гарантировать, что любой может проверить транзакцию, необходимо предоставить полные данные о транзакции. Это обычно зависит от дополнительных решений по доступности данных, что еще больше увеличивает затраты и комиссии для пользователей.
Заключение
Конец масштабируемости не должен быть компромиссом.
В отличие от других публичных блокчейнов, Polkadot не выбрал путь централизации ради производительности и предустановленного доверия ради эффективности, а добился многомерного баланса между безопасностью, децентрализацией и высокой производительностью через эластичное масштабирование, проектирование бессрочных протоколов, унифицированный уровень безопасности и гибкий механизм управления ресурсами.
В стремлении к более масштабному применению сегодня, "нулевая доверительная масштабируемость", на которой настаивает Polkadot, возможно, является истинным решением, способным поддерживать долгосрочное развитие Web3.