В эпоху блокчейна, стремящегося к более высокой эффективности, постепенно возникает ключевая проблема: как одновременно увеличить производительность, не жертвуя безопасностью и гибкостью системы? Это не только технический вызов, но и глубокий выбор в архитектурном дизайне. Для экосистемы Web3 более быстрая система, если она основывается на жертвах доверия и безопасности, часто не может поддерживать по-настоящему устойчивые инновации.
Как важный движущая сила масштабируемости Web3, жертвует ли Polkadot некоторыми аспектами в целях высокой пропускной способности и низкой задержки? Уступает ли его модель rollup в области децентрализации, безопасности или сетевой интероперабельности?
В данной статье будут рассмотрены эти вопросы, проведен глубокий анализ компромиссов и взвешиваний в дизайне масштабируемости Polkadot, а также проведено сравнение с решениями других основных публичных блокчейнов, исследуя их различные пути выбора между производительностью, безопасностью и децентрализацией.
Проблемы, с которыми сталкивается дизайн расширения Polkadot
Баланс гибкости и децентрализации
Архитектура Polkadot зависит от сети валидаторов и релейной цепи. Может ли это в некоторых аспектах привести к рискам централизации? Может ли возникнуть единственная точка сбоя или контроля, что повлияет на его характеристики децентрализованности?
Работа Rollup зависит от сортировщика, подключенного к релейной цепи, а его связь использует механизм протокола collator. Этот протокол полностью без разрешений и без доверия, любой человек с подключением к сети может его использовать, подключив небольшое количество узлов релейной цепи и подав запросы на изменение состояния rollup. Эти запросы будут проверены каким-либо core релейной цепи, при этом необходимо выполнить одно условие: они должны быть действительными изменениями состояния, в противном случае состояние rollup не будет обновлено.
Торговля вертикальным расширением
Rollup может достичь вертикального масштабирования, используя многоядерную архитектуру Polkadot. Эта новая возможность была введена функцией "гибкого масштабирования". В процессе проектирования было установлено, что поскольку проверка блоков 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, проверяя все вычисления на ядре, без необходимости ограничивать или предполагать количество используемых ядер.
Поэтому rollup Polkadot может достичь истинного масштабирования без ущерба для безопасности.
универсальность
Эластичное масштабирование не ограничивает программируемость rollup. Модель rollup в Polkadot поддерживает выполнение вычислений с полной вычислительной мощностью в среде WebAssembly, при условии, что одно выполнение завершится за 2 секунды. С помощью эластичного масштабирования общее количество вычислений, выполняемых за 6-секундный цикл, увеличивается, но типы вычислений не затрагиваются.
сложность
Более высокая пропускная способность и более низкая задержка неизбежно вводят сложность, что является единственным приемлемым компромиссом в системном дизайне.
Rollup может динамически регулировать ресурсы через интерфейс Agile Coretime для поддержания согласованного уровня безопасности. Они также должны выполнить часть требований RFC103, чтобы адаптироваться к различным сценариям использования.
Конкретная сложность зависит от стратегии управления ресурсами rollup, которые могут зависеть от переменных на цепочке или вне цепочки. Например:
Простая стратегия: всегда использовать фиксированное количество core, или вручную регулировать вне цепи;
Легкая стратегия: мониторинг определенной нагрузки транзакций в mempool узла;
Автоматизированные стратегии: предварительная настройка ресурсов через сервис coretime с использованием исторических данных и интерфейса XCM.
Хотя автоматизированные методы более эффективны, затраты на их реализацию и тестирование также значительно увеличиваются.
Интероперабельность
Polkadot поддерживает взаимодействие между различными rollup, и эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Сообщения между rollup-ами передаются через нижний уровень транспортного слоя, и пространство блока связи для каждого rollup фиксировано, независимо от числа выделенных ему ядер.
В будущем Polkadot также будет поддерживать передачу сообщений вне цепочки, при этом релейная цепь будет выступать в качестве управляющего уровня, а не уровня данных. Это обновление повысит возможности связи между rollup'ами вместе с эластичным масштабированием, что further улучшит вертикальные возможности масштабирования системы.
Какие компромиссы были сделаны другими протоколами?
Как известно, повышение производительности часто достигается за счет жертвования децентрализацией и безопасностью. Однако, с точки зрения коэффициента Накамото, даже если некоторые конкуренты Polkadot имеют низкий уровень децентрализации, их производительность также не впечатляет.
Солана
Solana не использует архитектуру шардирования Polkadot или Ethereum, а реализует масштабируемость с помощью одноуровневой высокопроизводительной архитектуры, полагаясь на историческое доказательство (PoH), параллельную обработку CPU и механизм согласования на основе лидера, теоретически достигая TPS до 65,000.
Ключевым элементом дизайна является предшествующий открытый и проверяемый механизм назначения лидеров:
В начале каждого эпохи (примерно каждые два дня или 432 000 слотов) слоты распределяются в зависимости от объема стейкинга;
Чем больше заложено, тем больше распределение. Например, валидатор, заложивший 1%, получит около 1% шансов на создание блока;
Все майнеры заранее объявлены, что увеличивает риск направленных DDoS-атак на сеть и частых сбоев.
PoH и параллельная обработка предъявляют крайне высокие требования к аппаратному обеспечению, что приводит к централизации валидаторских узлов. Чем больше узлов ставят, тем выше их шансы на создание блока, в то время как у малых узлов практически нет слотов, что еще больше усугубляет централизацию и увеличивает риск паралича системы после атаки.
Солана жертвует децентрализацией и устойчивостью к атакам ради достижения TPS, её коэффициент Накамото составляет всего 20, что значительно ниже, чем у Polkadot, который равен 172.
ТОК
TON заявляет, что его TPS может достигать 104,715, но эта цифра была достигнута в частной тестовой сети с 256 узлами при идеальных сетевых и аппаратных условиях. В то время как Polkadot уже достиг 128K TPS в децентрализованной публичной сети.
У механизмаConsensus 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, а не в непосредственном решении проблем на базовом уровне. Этот подход по сути не решает проблему, а передает ее на уровень выше в стеке.
Оптимистичный Роллап
В настоящее время большинство Optimistic rollup централизованы (некоторые даже имеют только один последователь), что приводит к недостаточной безопасности, изоляции друг от друга и высокой задержке (необходимо ожидание периода мошеннического доказательства, обычно несколько дней).
ZK Rollup
Реализация ZK rollup ограничена объемом данных, которые могут быть обработаны в одной транзакции. Вычислительные требования для генерации нулевого знания доказательства очень высоки, и механизм "победитель получает все" легко приводит к централизации системы. Для обеспечения TPS ZK rollup часто ограничивает объем транзакций в каждой партии, что в условиях высокого спроса может привести к перегрузке сети, росту газов и ухудшению пользовательского опыта.
В сравнении, стоимость Turing-совместимого ZK rollup примерно в 2×10^6 раз выше, чем стоимость основного протокола безопасности криптоэкономики Polkadot.
Кроме того, проблемы с доступностью данных ZK rollup также усугубят его недостатки. Чтобы обеспечить возможность проверки транзакций любому желающему, необходимо предоставить полные данные о транзакциях. Это обычно зависит от дополнительных решений по доступности данных, что дополнительно увеличивает затраты и расходы пользователей.
Заключение
Конец масштабируемости не должен быть компромиссом.
В отличие от других публичных блокчейнов, Polkadot не пошел по пути централизации в обмен на производительность и предустановленного доверия в обмен на эффективность, а достиг многомерного баланса безопасности, децентрализации и высокой производительности благодаря эластичному масштабированию, безразрешительным протоколам, единому уровню безопасности и гибким механизмам управления ресурсами.
В условиях стремления к более широкому применению, подход Polkadot к "нулевой доверительной масштабируемости" возможно является действительно решением, которое сможет поддержать долгосрочное развитие Web3.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
12 Лайков
Награда
12
8
Поделиться
комментарий
0/400
LiquidityWhisperer
· 07-22 15:35
Разве нельзя иметь и скорость, и безопасность?
Посмотреть ОригиналОтветить0
DiamondHands
· 07-22 13:17
Скорость и безопасность изначально противоречат друг другу, не так ли?
Посмотреть ОригиналОтветить0
GasGuru
· 07-21 22:12
Снова цепочка занимается балансировкой.
Посмотреть ОригиналОтветить0
TokenVelocity
· 07-21 22:10
Пока действительно стабилен? Или будут играть для лохов?
Посмотреть ОригиналОтветить0
BearMarketSage
· 07-21 21:53
Нельзя иметь и рыбу, и медведя.
Посмотреть ОригиналОтветить0
MidnightSeller
· 07-21 21:52
Жертвовать безопасностью ради скорости, почти что жди, когда попадешь на крышу.
Посмотреть ОригиналОтветить0
PermabullPete
· 07-21 21:48
Понял, но где точка?
Посмотреть ОригиналОтветить0
MEVSandwichMaker
· 07-21 21:48
Цена жертвы всегда должна быть оплачена, только вопрос, кто первым взорвется.
Как Polkadot реализует расширение без доверия, ведя будущее Web3
Торговля расширяемостью: Вызовы Polkadot и Web3
В эпоху блокчейна, стремящегося к более высокой эффективности, постепенно возникает ключевая проблема: как одновременно увеличить производительность, не жертвуя безопасностью и гибкостью системы? Это не только технический вызов, но и глубокий выбор в архитектурном дизайне. Для экосистемы Web3 более быстрая система, если она основывается на жертвах доверия и безопасности, часто не может поддерживать по-настоящему устойчивые инновации.
Как важный движущая сила масштабируемости Web3, жертвует ли Polkadot некоторыми аспектами в целях высокой пропускной способности и низкой задержки? Уступает ли его модель rollup в области децентрализации, безопасности или сетевой интероперабельности?
В данной статье будут рассмотрены эти вопросы, проведен глубокий анализ компромиссов и взвешиваний в дизайне масштабируемости Polkadot, а также проведено сравнение с решениями других основных публичных блокчейнов, исследуя их различные пути выбора между производительностью, безопасностью и децентрализацией.
Проблемы, с которыми сталкивается дизайн расширения Polkadot
Баланс гибкости и децентрализации
Архитектура Polkadot зависит от сети валидаторов и релейной цепи. Может ли это в некоторых аспектах привести к рискам централизации? Может ли возникнуть единственная точка сбоя или контроля, что повлияет на его характеристики децентрализованности?
Работа Rollup зависит от сортировщика, подключенного к релейной цепи, а его связь использует механизм протокола collator. Этот протокол полностью без разрешений и без доверия, любой человек с подключением к сети может его использовать, подключив небольшое количество узлов релейной цепи и подав запросы на изменение состояния rollup. Эти запросы будут проверены каким-либо core релейной цепи, при этом необходимо выполнить одно условие: они должны быть действительными изменениями состояния, в противном случае состояние rollup не будет обновлено.
Торговля вертикальным расширением
Rollup может достичь вертикального масштабирования, используя многоядерную архитектуру Polkadot. Эта новая возможность была введена функцией "гибкого масштабирования". В процессе проектирования было установлено, что поскольку проверка блоков 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, проверяя все вычисления на ядре, без необходимости ограничивать или предполагать количество используемых ядер.
Поэтому rollup Polkadot может достичь истинного масштабирования без ущерба для безопасности.
универсальность
Эластичное масштабирование не ограничивает программируемость rollup. Модель rollup в Polkadot поддерживает выполнение вычислений с полной вычислительной мощностью в среде WebAssembly, при условии, что одно выполнение завершится за 2 секунды. С помощью эластичного масштабирования общее количество вычислений, выполняемых за 6-секундный цикл, увеличивается, но типы вычислений не затрагиваются.
сложность
Более высокая пропускная способность и более низкая задержка неизбежно вводят сложность, что является единственным приемлемым компромиссом в системном дизайне.
Rollup может динамически регулировать ресурсы через интерфейс Agile Coretime для поддержания согласованного уровня безопасности. Они также должны выполнить часть требований RFC103, чтобы адаптироваться к различным сценариям использования.
Конкретная сложность зависит от стратегии управления ресурсами rollup, которые могут зависеть от переменных на цепочке или вне цепочки. Например:
Простая стратегия: всегда использовать фиксированное количество core, или вручную регулировать вне цепи;
Легкая стратегия: мониторинг определенной нагрузки транзакций в mempool узла;
Автоматизированные стратегии: предварительная настройка ресурсов через сервис coretime с использованием исторических данных и интерфейса XCM.
Хотя автоматизированные методы более эффективны, затраты на их реализацию и тестирование также значительно увеличиваются.
Интероперабельность
Polkadot поддерживает взаимодействие между различными rollup, и эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Сообщения между rollup-ами передаются через нижний уровень транспортного слоя, и пространство блока связи для каждого rollup фиксировано, независимо от числа выделенных ему ядер.
В будущем Polkadot также будет поддерживать передачу сообщений вне цепочки, при этом релейная цепь будет выступать в качестве управляющего уровня, а не уровня данных. Это обновление повысит возможности связи между rollup'ами вместе с эластичным масштабированием, что further улучшит вертикальные возможности масштабирования системы.
Какие компромиссы были сделаны другими протоколами?
Как известно, повышение производительности часто достигается за счет жертвования децентрализацией и безопасностью. Однако, с точки зрения коэффициента Накамото, даже если некоторые конкуренты Polkadot имеют низкий уровень децентрализации, их производительность также не впечатляет.
Солана
Solana не использует архитектуру шардирования Polkadot или Ethereum, а реализует масштабируемость с помощью одноуровневой высокопроизводительной архитектуры, полагаясь на историческое доказательство (PoH), параллельную обработку CPU и механизм согласования на основе лидера, теоретически достигая TPS до 65,000.
Ключевым элементом дизайна является предшествующий открытый и проверяемый механизм назначения лидеров:
В начале каждого эпохи (примерно каждые два дня или 432 000 слотов) слоты распределяются в зависимости от объема стейкинга;
Чем больше заложено, тем больше распределение. Например, валидатор, заложивший 1%, получит около 1% шансов на создание блока;
Все майнеры заранее объявлены, что увеличивает риск направленных DDoS-атак на сеть и частых сбоев.
PoH и параллельная обработка предъявляют крайне высокие требования к аппаратному обеспечению, что приводит к централизации валидаторских узлов. Чем больше узлов ставят, тем выше их шансы на создание блока, в то время как у малых узлов практически нет слотов, что еще больше усугубляет централизацию и увеличивает риск паралича системы после атаки.
Солана жертвует децентрализацией и устойчивостью к атакам ради достижения TPS, её коэффициент Накамото составляет всего 20, что значительно ниже, чем у Polkadot, который равен 172.
ТОК
TON заявляет, что его TPS может достигать 104,715, но эта цифра была достигнута в частной тестовой сети с 256 узлами при идеальных сетевых и аппаратных условиях. В то время как Polkadot уже достиг 128K TPS в децентрализованной публичной сети.
У механизмаConsensus 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, а не в непосредственном решении проблем на базовом уровне. Этот подход по сути не решает проблему, а передает ее на уровень выше в стеке.
Оптимистичный Роллап
В настоящее время большинство Optimistic rollup централизованы (некоторые даже имеют только один последователь), что приводит к недостаточной безопасности, изоляции друг от друга и высокой задержке (необходимо ожидание периода мошеннического доказательства, обычно несколько дней).
ZK Rollup
Реализация ZK rollup ограничена объемом данных, которые могут быть обработаны в одной транзакции. Вычислительные требования для генерации нулевого знания доказательства очень высоки, и механизм "победитель получает все" легко приводит к централизации системы. Для обеспечения TPS ZK rollup часто ограничивает объем транзакций в каждой партии, что в условиях высокого спроса может привести к перегрузке сети, росту газов и ухудшению пользовательского опыта.
В сравнении, стоимость Turing-совместимого ZK rollup примерно в 2×10^6 раз выше, чем стоимость основного протокола безопасности криптоэкономики Polkadot.
Кроме того, проблемы с доступностью данных ZK rollup также усугубят его недостатки. Чтобы обеспечить возможность проверки транзакций любому желающему, необходимо предоставить полные данные о транзакциях. Это обычно зависит от дополнительных решений по доступности данных, что дополнительно увеличивает затраты и расходы пользователей.
Заключение
Конец масштабируемости не должен быть компромиссом.
В отличие от других публичных блокчейнов, Polkadot не пошел по пути централизации в обмен на производительность и предустановленного доверия в обмен на эффективность, а достиг многомерного баланса безопасности, децентрализации и высокой производительности благодаря эластичному масштабированию, безразрешительным протоколам, единому уровню безопасности и гибким механизмам управления ресурсами.
В условиях стремления к более широкому применению, подход Polkadot к "нулевой доверительной масштабируемости" возможно является действительно решением, которое сможет поддержать долгосрочное развитие Web3.