Баланс между масштабируемостью и безопасностью: архитектурный дизайн Web3 Polkadot
В эпоху постоянного стремления к более высокой эффективности технологий блокчейн, ключевая проблема постепенно выходит на поверхность: как повысить производительность, не жертвуя безопасностью и гибкостью системы? Это не только вызов на техническом уровне, но и глубокие соображения по дизайну архитектуры. Для экосистемы Web3 высокоскоростная система, если она достигается за счет доверия и безопасности, часто не может поддерживать по-настоящему устойчивые инновации.
Является ли Polkadot важным двигателем масштабируемости Web3, который идет на определенные компромиссы в процессе достижения высокой пропускной способности и низкой задержки? Делает ли его модель rollup какие-либо уступки в области децентрализации, безопасности или сетевой интероперабельности? В данной статье мы обсудим эти вопросы, глубоко проанализируем компромиссы и взвешивание Polkadot в дизайне масштабируемости и сравним их с решениями других основных публичных блокчейнов, исследуя их различные выборы в области производительности, безопасности и децентрализации.
Проблемы, с которыми сталкивается дизайн расширения Polkadot
Баланс между гибкостью и децентрализацией
Архитектура Polkadot зависит от сети валидаторов и релейной цепи. Может ли это в каких-то аспектах привести к централизованным рискам? Возможно ли возникновение единой точки отказа или контроля, что повлияет на его децентрализованные характеристики?
Работа Rollup зависит от сортировщика, подключенного к релейной цепи, а его связь использует механизм протокола collator. Этот протокол полностью не требует разрешений и доверия, любой, у кого есть сетевое подключение, может им воспользоваться, подключив несколько узлов релейной цепи и отправив запросы на изменение состояния rollup. Эти запросы будут проверяться каким-либо core релейной цепи, при этом необходимо соблюдение одного условия: они должны быть действительными изменениями состояния, в противном случае состояние rollup не будет продвигаться.
Торговля вертикальным расширением
Rollup может реализовать вертикальное масштабирование, используя многопроцессорную архитектуру Polkadot. Эта новая возможность была введена с функцией «гибкого масштабирования». В процессе проектирования было обнаружено, что поскольку проверка блоков rollup не фиксируется на каком-либо одном ядре, это может повлиять на его гибкость.
Поскольку протокол отправки блоков в промежуточную цепь не требует разрешений и доверия, любой может отправить блок для проверки на любом ядре, назначенном rollup. Злоумышленники могут воспользоваться этим, многократно отправляя ранее проверенные легитимные блоки на разные ядра, злоупотребляя ресурсами и тем самым снижая общую пропускную способность и эффективность rollup.
Цель Polkadot заключается в поддержании гибкости rollup и эффективном использовании ресурсов релейной цепи без ущерба для ключевых характеристик системы.
Проблема доверия Sequencer
Простое решение состоит в том, чтобы установить протокол как "с разрешением": например, использовать механизм белого списка или по умолчанию доверять сортировщикам, которые не будут вести себя злоумышленно, чтобы обеспечить активность rollup.
Однако в концепции дизайна Polkadot мы не можем делать никаких предположений о доверии к sequencer, поскольку необходимо сохранить характеристики системы «без доверия» и «без разрешений». Каждый должен иметь возможность использовать протокол collator для отправки запросов на изменение состояния rollup.
Polkadot: Неуклонное решение
Конечное решение Polkadot заключается в том, чтобы полностью передать проблему функции преобразования состояния rollup (Runtime). Runtime является единственным надежным источником всей информации о консенсусе, поэтому необходимо четко указать в выводе, на каком ядре Polkadot должно выполняться подтверждение.
Этот дизайн обеспечивает двойную защиту гибкости и безопасности. Polkadot будет повторно выполнять преобразования состояния rollup в процессе доступности и обеспечивать правильность распределения core с помощью экономического протокола ELVES.
Перед записью данных о доступности в слое Polkadot в любой rollup блок группа из примерно 5 валидаторов сначала проверит их законность. Они принимают кандидаты на квитанции и доказательства действительности, представленные сортировщиками, которые содержат rollup блок и соответствующие доказательства хранения. Эта информация будет обработана функцией проверки параллельной цепи и повторно выполнена валидаторами на релейной цепи.
Результат проверки включает селектор core, который указывает, на каком core следует проверять блок. Проверяющий сравнит этот индекс с тем, за который он отвечает; если они не совпадают, блок будет отброшен.
Этот механизм гарантирует, что система всегда сохраняет свойства без доверия и без разрешений, предотвращая манипуляции со стороны злонамеренных участников, таких как сортировщики, и обеспечивая устойчивость даже при использовании нескольких ядер в rollup.
безопасность
В процессе стремления к масштабируемости Polkadot не пошел на компромисс в вопросах безопасности. Безопасность rollup обеспечивается релейной цепочкой, и для поддержания жизнеспособности достаточно одного честного сортировщика.
С помощью протокола ELVES Polkadot распространяет свою безопасность на все роллапы, проверяя вычисления на всех ядрах без каких-либо ограничений или предположений о количестве используемых ядер.
Таким образом, rollup Polkadot может достичь истинного масштабирования без жертвы безопасностью.
Универсальность
Эластичное расширение не ограничивает программируемость rollup. Модель rollup в Polkadot поддерживает выполнение вычислений, полноценно соответствующих Тьюрингу, в среде WebAssembly, при условии, что одно выполнение завершается в течение 2 секунд. Благодаря эластичному расширению общее количество вычислений, выполняемых за 6-секундный период, увеличивается, но типы вычислений не изменяются.
Сложность
Более высокая пропускная способность и более низкая задержка неизбежно вводят сложность, что является единственным приемлемым компромиссом в системе проектирования.
Rollup может динамически настраивать ресурсы через интерфейс Agile Coretime для поддержания постоянного уровня безопасности. Они также должны реализовать некоторые требования RFC103, чтобы адаптироваться к различным сценариям использования.
Конкретная сложность зависит от стратегии управления ресурсами rollup, которые могут зависеть от переменных на цепочке или вне цепочки. Например:
Простая стратегия: всегда использовать фиксированное количество core, или вручную настраивать вне цепи;
Легкая стратегия: мониторинг конкретной нагрузки транзакций в мемпуле узла;
Автоматизированная стратегия: предварительная настройка ресурсов с помощью исторических данных и интерфейса XCM для вызова службы coretime.
Хотя автоматизированные методы более эффективны, затраты на их реализацию и тестирование также значительно возрастают.
Интероперабельность
Polkadot поддерживает интероперабельность между различными rollup, при этом эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Сообщения между кросс-роллапами передаются через базовый уровень передачи, и пространство коммуникационных блоков каждого роллапа фиксировано и не зависит от количества выделенных ему ядер.
В будущем Polkadot также будет поддерживать передачу сообщений вне цепи, используя релейную цепь в качестве управляющей плоскости, а не плоскости данных. Это обновление улучшит возможности связи между rollup и одновременно повысит гибкость масштабирования, что дополнительно усилит вертикальные возможности масштабирования системы.
В权衡 других协议
Как известно, повышение производительности часто достигается ценой жертвы децентрализации и безопасности. Но с точки зрения коэффициента Накамото, даже если у некоторых конкурентов Polkadot уровень децентрализации ниже, их производительность также оставляет желать лучшего.
Солана
Solana не использует шардирование Polkadot или Ethereum, а реализует масштабируемость с помощью однопластовой архитектуры с высокой пропускной способностью, полагаясь на доказательство истории, параллельную обработку ЦП и механизм консенсуса на основе лидера, теоретически достигая TPS до 65 000.
Ключевым дизайном является его предварительно опубликованный и проверяемый механизм распределения лидеров:
В начале каждого эпохи (примерно через два дня или 432 000 слотов) слоты распределяются в зависимости от объема стейка;
Чем больше залога, тем больше распределение. Например, валидатор, ставящий 1%, получит около 1% шанса на создание блока;
Все майнеры заранее объявлены, что увеличивает риск целенаправленных DDoS-атак на сеть и частых сбоев.
История показывает, что параллельная обработка требует высоких требований к оборудованию, что приводит к центрированию узлов верификации. Чем больше узлов участвует в стекинге, тем больше у них шансов на создание блока, в то время как у маленьких узлов практически нет слотов, что еще больше усугубляет централизацию и увеличивает риск полного разрушения системы после атаки.
Солана, стремясь к TPS, пожертвовала децентрализацией и устойчивостью к атакам, ее коэффициент Накамото составляет всего 20, что значительно ниже 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 для каждой подсети может достигать ~5,000, подобно подходу Polkadot: уменьшение нагрузки на отдельный шард для достижения масштабируемости. Однако Avalanche позволяет валидаторам свободно выбирать участие в подсетях, и подсети могут устанавливать дополнительные требования, такие как география, KYC и т.д., жертвуя децентрализованностью и безопасностью.
В Polkadot все rollup делят единое обеспечение безопасности; в то время как под сети Avalanche не имеют обязательного обеспечения безопасности, некоторые из них могут быть полностью централизованными. Если вы хотите повысить безопасность, вам все равно придется идти на компромисс в производительности, и трудно обеспечить определенные обязательства по безопасности.
Эфир
Стратегия масштабирования Ethereum заключается в ставке на масштабируемость уровня rollup, а не в прямом решении проблемы на базовом уровне. Этот подход по сути не решает проблему, а передает ее на верхний уровень стека.
Оптимистичный роллап
В настоящее время большинство оптимистичных роллапов централизованы, что приводит к недостаточной безопасности, изоляции друг от друга и высокой задержке (необходимо ждать период доказательства мошенничества, который обычно длится несколько дней).
ZK Rollup
Реализация ZK rollup ограничена объемом данных, которые могут быть обработаны за одну транзакцию. Вычислительные требования для генерации нулевых доказательств чрезвычайно высоки, и механизм "победитель получает все" может привести к централизации системы. Чтобы гарантировать TPS, ZK rollup часто ограничивает объем транзакций в каждой партии, что в условиях высокого спроса может привести к перегрузке сети, росту газа и ухудшению пользовательского опыта.
Сравнительно, стоимость Turing-complete ZK rollup примерно в 2x10^6 раз выше, чем безопасность экономического протокола ядра Polkadot.
Кроме того, проблема доступности данных ZK rollup также усугубит его недостатки. Для того чтобы любой мог проверить транзакцию, необходимо предоставить полные данные о транзакции. Это обычно зависит от дополнительных решений по доступности данных, что еще больше увеличивает стоимость и пользовательские расходы.
Заключение
Конец масштабируемости не должен быть компромиссом.
В отличие от других блокчейнов, Polkadot не выбрала путь централизации ради производительности или предустановленного доверия ради эффективности, а достигла многомерного баланса между безопасностью, децентрализацией и высокой производительностью за счет гибкого масштабирования, проектирования протоколов без разрешений, единого уровня безопасности и гибкого управления ресурсами.
В эпоху стремления к более широкому внедрению, "недоверительная масштабируемость", которую отстаивает Polkadot, возможно, является настоящим решением, способствующим долгосрочному развитию Web3.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
19 Лайков
Награда
19
5
Репост
Поделиться
комментарий
0/400
NFT_Therapy
· 07-16 00:58
Снова вижу своего старого френа dot!
Посмотреть ОригиналОтветить0
LayerZeroHero
· 07-14 19:38
Фактически, определенно есть компромисс, и необходимо провести бенчмаркинг для проверки...
Посмотреть ОригиналОтветить0
BearMarketBuyer
· 07-14 19:17
dot действительно вкусно.. я держатель уже три года
Посмотреть ОригиналОтветить0
WalletAnxietyPatient
· 07-14 19:16
Снова вложился слишком рано, снова умер слишком рано.
Web3-архитектура Polkadot: идеальный баланс между масштабируемостью и безопасностью
Баланс между масштабируемостью и безопасностью: архитектурный дизайн Web3 Polkadot
В эпоху постоянного стремления к более высокой эффективности технологий блокчейн, ключевая проблема постепенно выходит на поверхность: как повысить производительность, не жертвуя безопасностью и гибкостью системы? Это не только вызов на техническом уровне, но и глубокие соображения по дизайну архитектуры. Для экосистемы Web3 высокоскоростная система, если она достигается за счет доверия и безопасности, часто не может поддерживать по-настоящему устойчивые инновации.
Является ли Polkadot важным двигателем масштабируемости Web3, который идет на определенные компромиссы в процессе достижения высокой пропускной способности и низкой задержки? Делает ли его модель rollup какие-либо уступки в области децентрализации, безопасности или сетевой интероперабельности? В данной статье мы обсудим эти вопросы, глубоко проанализируем компромиссы и взвешивание Polkadot в дизайне масштабируемости и сравним их с решениями других основных публичных блокчейнов, исследуя их различные выборы в области производительности, безопасности и децентрализации.
Проблемы, с которыми сталкивается дизайн расширения Polkadot
Баланс между гибкостью и децентрализацией
Архитектура Polkadot зависит от сети валидаторов и релейной цепи. Может ли это в каких-то аспектах привести к централизованным рискам? Возможно ли возникновение единой точки отказа или контроля, что повлияет на его децентрализованные характеристики?
Работа Rollup зависит от сортировщика, подключенного к релейной цепи, а его связь использует механизм протокола collator. Этот протокол полностью не требует разрешений и доверия, любой, у кого есть сетевое подключение, может им воспользоваться, подключив несколько узлов релейной цепи и отправив запросы на изменение состояния rollup. Эти запросы будут проверяться каким-либо core релейной цепи, при этом необходимо соблюдение одного условия: они должны быть действительными изменениями состояния, в противном случае состояние rollup не будет продвигаться.
Торговля вертикальным расширением
Rollup может реализовать вертикальное масштабирование, используя многопроцессорную архитектуру Polkadot. Эта новая возможность была введена с функцией «гибкого масштабирования». В процессе проектирования было обнаружено, что поскольку проверка блоков rollup не фиксируется на каком-либо одном ядре, это может повлиять на его гибкость.
Поскольку протокол отправки блоков в промежуточную цепь не требует разрешений и доверия, любой может отправить блок для проверки на любом ядре, назначенном rollup. Злоумышленники могут воспользоваться этим, многократно отправляя ранее проверенные легитимные блоки на разные ядра, злоупотребляя ресурсами и тем самым снижая общую пропускную способность и эффективность rollup.
Цель Polkadot заключается в поддержании гибкости rollup и эффективном использовании ресурсов релейной цепи без ущерба для ключевых характеристик системы.
Проблема доверия Sequencer
Простое решение состоит в том, чтобы установить протокол как "с разрешением": например, использовать механизм белого списка или по умолчанию доверять сортировщикам, которые не будут вести себя злоумышленно, чтобы обеспечить активность rollup.
Однако в концепции дизайна Polkadot мы не можем делать никаких предположений о доверии к sequencer, поскольку необходимо сохранить характеристики системы «без доверия» и «без разрешений». Каждый должен иметь возможность использовать протокол collator для отправки запросов на изменение состояния rollup.
Polkadot: Неуклонное решение
Конечное решение Polkadot заключается в том, чтобы полностью передать проблему функции преобразования состояния rollup (Runtime). Runtime является единственным надежным источником всей информации о консенсусе, поэтому необходимо четко указать в выводе, на каком ядре Polkadot должно выполняться подтверждение.
Этот дизайн обеспечивает двойную защиту гибкости и безопасности. Polkadot будет повторно выполнять преобразования состояния rollup в процессе доступности и обеспечивать правильность распределения core с помощью экономического протокола ELVES.
Перед записью данных о доступности в слое Polkadot в любой rollup блок группа из примерно 5 валидаторов сначала проверит их законность. Они принимают кандидаты на квитанции и доказательства действительности, представленные сортировщиками, которые содержат rollup блок и соответствующие доказательства хранения. Эта информация будет обработана функцией проверки параллельной цепи и повторно выполнена валидаторами на релейной цепи.
Результат проверки включает селектор core, который указывает, на каком core следует проверять блок. Проверяющий сравнит этот индекс с тем, за который он отвечает; если они не совпадают, блок будет отброшен.
Этот механизм гарантирует, что система всегда сохраняет свойства без доверия и без разрешений, предотвращая манипуляции со стороны злонамеренных участников, таких как сортировщики, и обеспечивая устойчивость даже при использовании нескольких ядер в rollup.
безопасность
В процессе стремления к масштабируемости Polkadot не пошел на компромисс в вопросах безопасности. Безопасность rollup обеспечивается релейной цепочкой, и для поддержания жизнеспособности достаточно одного честного сортировщика.
С помощью протокола ELVES Polkadot распространяет свою безопасность на все роллапы, проверяя вычисления на всех ядрах без каких-либо ограничений или предположений о количестве используемых ядер.
Таким образом, rollup Polkadot может достичь истинного масштабирования без жертвы безопасностью.
Универсальность
Эластичное расширение не ограничивает программируемость rollup. Модель rollup в Polkadot поддерживает выполнение вычислений, полноценно соответствующих Тьюрингу, в среде WebAssembly, при условии, что одно выполнение завершается в течение 2 секунд. Благодаря эластичному расширению общее количество вычислений, выполняемых за 6-секундный период, увеличивается, но типы вычислений не изменяются.
Сложность
Более высокая пропускная способность и более низкая задержка неизбежно вводят сложность, что является единственным приемлемым компромиссом в системе проектирования.
Rollup может динамически настраивать ресурсы через интерфейс Agile Coretime для поддержания постоянного уровня безопасности. Они также должны реализовать некоторые требования RFC103, чтобы адаптироваться к различным сценариям использования.
Конкретная сложность зависит от стратегии управления ресурсами rollup, которые могут зависеть от переменных на цепочке или вне цепочки. Например:
Хотя автоматизированные методы более эффективны, затраты на их реализацию и тестирование также значительно возрастают.
Интероперабельность
Polkadot поддерживает интероперабельность между различными rollup, при этом эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Сообщения между кросс-роллапами передаются через базовый уровень передачи, и пространство коммуникационных блоков каждого роллапа фиксировано и не зависит от количества выделенных ему ядер.
В будущем Polkadot также будет поддерживать передачу сообщений вне цепи, используя релейную цепь в качестве управляющей плоскости, а не плоскости данных. Это обновление улучшит возможности связи между rollup и одновременно повысит гибкость масштабирования, что дополнительно усилит вертикальные возможности масштабирования системы.
В权衡 других协议
Как известно, повышение производительности часто достигается ценой жертвы децентрализации и безопасности. Но с точки зрения коэффициента Накамото, даже если у некоторых конкурентов Polkadot уровень децентрализации ниже, их производительность также оставляет желать лучшего.
Солана
Solana не использует шардирование Polkadot или Ethereum, а реализует масштабируемость с помощью однопластовой архитектуры с высокой пропускной способностью, полагаясь на доказательство истории, параллельную обработку ЦП и механизм консенсуса на основе лидера, теоретически достигая TPS до 65 000.
Ключевым дизайном является его предварительно опубликованный и проверяемый механизм распределения лидеров:
История показывает, что параллельная обработка требует высоких требований к оборудованию, что приводит к центрированию узлов верификации. Чем больше узлов участвует в стекинге, тем больше у них шансов на создание блока, в то время как у маленьких узлов практически нет слотов, что еще больше усугубляет централизацию и увеличивает риск полного разрушения системы после атаки.
Солана, стремясь к TPS, пожертвовала децентрализацией и устойчивостью к атакам, ее коэффициент Накамото составляет всего 20, что значительно ниже 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 для каждой подсети может достигать ~5,000, подобно подходу Polkadot: уменьшение нагрузки на отдельный шард для достижения масштабируемости. Однако Avalanche позволяет валидаторам свободно выбирать участие в подсетях, и подсети могут устанавливать дополнительные требования, такие как география, KYC и т.д., жертвуя децентрализованностью и безопасностью.
В Polkadot все rollup делят единое обеспечение безопасности; в то время как под сети Avalanche не имеют обязательного обеспечения безопасности, некоторые из них могут быть полностью централизованными. Если вы хотите повысить безопасность, вам все равно придется идти на компромисс в производительности, и трудно обеспечить определенные обязательства по безопасности.
Эфир
Стратегия масштабирования Ethereum заключается в ставке на масштабируемость уровня rollup, а не в прямом решении проблемы на базовом уровне. Этот подход по сути не решает проблему, а передает ее на верхний уровень стека.
Оптимистичный роллап
В настоящее время большинство оптимистичных роллапов централизованы, что приводит к недостаточной безопасности, изоляции друг от друга и высокой задержке (необходимо ждать период доказательства мошенничества, который обычно длится несколько дней).
ZK Rollup
Реализация ZK rollup ограничена объемом данных, которые могут быть обработаны за одну транзакцию. Вычислительные требования для генерации нулевых доказательств чрезвычайно высоки, и механизм "победитель получает все" может привести к централизации системы. Чтобы гарантировать TPS, ZK rollup часто ограничивает объем транзакций в каждой партии, что в условиях высокого спроса может привести к перегрузке сети, росту газа и ухудшению пользовательского опыта.
Сравнительно, стоимость Turing-complete ZK rollup примерно в 2x10^6 раз выше, чем безопасность экономического протокола ядра Polkadot.
Кроме того, проблема доступности данных ZK rollup также усугубит его недостатки. Для того чтобы любой мог проверить транзакцию, необходимо предоставить полные данные о транзакции. Это обычно зависит от дополнительных решений по доступности данных, что еще больше увеличивает стоимость и пользовательские расходы.
Заключение
Конец масштабируемости не должен быть компромиссом.
В отличие от других блокчейнов, Polkadot не выбрала путь централизации ради производительности или предустановленного доверия ради эффективности, а достигла многомерного баланса между безопасностью, децентрализацией и высокой производительностью за счет гибкого масштабирования, проектирования протоколов без разрешений, единого уровня безопасности и гибкого управления ресурсами.
В эпоху стремления к более широкому внедрению, "недоверительная масштабируемость", которую отстаивает Polkadot, возможно, является настоящим решением, способствующим долгосрочному развитию Web3.