Масштабируемость и компромиссы: Технический выбор между Polkadot и экосистемой Web3
В эпоху постоянного стремления технологий блокчейн к более высокой эффективности возникает ключевой вопрос: как обеспечить безопасность и устойчивость системы одновременно с расширением производительности? Это не только вызов на техническом уровне, но и глубокий выбор в архитектурном дизайне. Для экосистемы Web3 просто стремиться к более быстрым системам в ущерб доверию и безопасности невозможно для поддержания действительно устойчивых инноваций.
Как важный движущая сила масштабируемости Web3, жертвовал ли Polkadot чем-то в стремлении достичь высокой пропускной способности и низкой задержки? Не идет ли его модель rollup на компромисс в области децентрализации, безопасности или сетевой интероперабельности? В этой статье мы сосредоточимся на этих вопросах, глубоко проанализируем компромиссы и баланс, которые Polkadot делает в своем дизайне масштабируемости, и сравним их с решениями других основных публичных блокчейнов, исследуя различные пути выбора между производительностью, безопасностью и децентрализацией.
Проблемы, с которыми сталкивается дизайн расширения Polkadot
Баланс между гибкостью и децентрализацией
Архитектура Polkadot зависит от сети валидаторов и релейной цепи, может ли это в некоторых аспектах привести к централизованным рискам? Возможно ли возникновение единой точки отказа или контроля, что повлияет на его децентрализованные характеристики?
Работа Rollup зависит от сортировщика, подключенного к релейной цепи, а его связь использует механизм протокола collator. Этот протокол полностью не требует разрешений и доверия; любой, кто имеет подключение к сети, может использовать его, подключив небольшое количество узлов релейной цепи и отправив запросы на изменение состояния rollup. Эти запросы будут проверены через определённый ядро релейной цепи, при этом необходимо соблюсти одно условие: они должны быть действительными изменениями состояния, в противном случае состояние этого rollup не будет продвинуто.
Торговля вертикальным расширением
Rollup может достичь вертикального масштабирования, используя многопроцессорную архитектуру Polkadot. Эта новая возможность была внедрена с функцией "гибкого масштабирования". В процессе проектирования было обнаружено, что поскольку валидация rollup блоков не фиксируется на каком-либо одном ядре, это может повлиять на его гибкость.
Поскольку протокол подачи блоков в промежуточную цепь не требует разрешения и доверия, любой может представить блок для проверки на любом ядре, назначенном для rollup. Злоумышленники могут использовать это, чтобы многократно отправлять ранее проверенные легитимные блоки на разные ядра, злоупотребляя ресурсами и тем самым снижая общую пропускную способность и эффективность rollup.
Цель Polkadot состоит в том, чтобы поддерживать гибкость rollup и эффективное использование ресурсов релейной цепи без ущерба для ключевых характеристик системы.
Проблема доверия к Sequencer
Одно простое решение состоит в том, чтобы установить протокол как "с разрешением": например, использовать механизм белого списка или по умолчанию доверять сортировщику, который не будет вести себя злоумышленно, тем самым обеспечивая активность rollup.
Однако в концепции дизайна Polkadot мы не можем делать никаких доверительных предположений о sequencer, поскольку необходимо поддерживать характеристики системы "без доверия" и "без разрешений". Любой должен иметь возможность использовать протокол collator для подачи запросов на изменение состояния rollup.
Polkadot: Неумолимое решение
В конечном итоге выбранное решение для Polkadot заключается в том, что все проблемы будут решаться функцией преобразования состояния rollup (Runtime). Runtime является единственным доверенным источником всей информации о консенсусе, поэтому необходимо четко указать, на каком ядре Polkadot должна выполняться проверка.
Этот дизайн обеспечивает двойную защиту эластичности и безопасности. Polkadot будет повторно выполнять преобразования состояния rollup в процессе доступности и обеспечивать правильность распределения core с помощью экономического протокола ELVES.
Перед тем как данные о rollup-блоке будут записаны в слой доступности данных (DA) Polkadot, группа из примерно 5 валидаторов сначала проверяет их законность. Они получают от сортировщика поданные кандидаты на квитанции и доказательства их действительности, которые содержат rollup-блок и соответствующее доказательство хранения. Эта информация будет обработана функцией проверки параллельной цепи и повторно выполнена валидаторами на релейной цепи.
В результате проверки содержится селектор core, который указывает, на каком core следует валидировать блок. Валидатор будет сравнивать этот индекс с тем, за который он отвечает; если они не совпадают, блок будет отброшен.
Этот механизм гарантирует, что система всегда сохраняет свойства без доверия и без разрешений, избегая манипуляций со стороны злонамеренных участников, таких как сортировщики, и обеспечивает устойчивость даже при использовании нескольких ядер в rollup.
безопасность
В процессе стремления к масштабируемости Polkadot не пошел на компромисс в области безопасности. Безопасность rollup обеспечивается релейной цепью, и для поддержания жизнеспособности требуется всего лишь один честный сортировщик.
С помощью протокола ELVES Polkadot полностью расширяет свою безопасность на все rollup, проверяя все вычисления на core, без необходимости ограничивать или делать предположения о количестве используемых core.
Таким образом, rollup Polkadot может обеспечить реальное масштабирование без ущерба для безопасности.
Универсальность
Эластичное масштабирование не ограничивает программируемость роллапов. Модель роллапов Polkadot поддерживает выполнение вычислений с полным числом Тьюринга в среде WebAssembly, при условии, что одно выполнение завершается в течение 2 секунд. Благодаря эластичному масштабированию общее количество вычислений, выполняемых за 6-секундный цикл, увеличивается, но типы вычислений не изменяются.
Комплексность
Более высокая пропускная способность и более низкая задержка неизбежно вводят сложность, что является единственным приемлемым компромиссом в проектировании систем.
Rollup может динамически настраивать ресурсы через интерфейс Agile Coretime для поддержания согласованного уровня безопасности. Они также должны реализовать некоторые требования RFC103, чтобы адаптироваться к различным сценариям использования.
Конкретная сложность зависит от стратегии управления ресурсами rollup, которые могут зависеть от переменных на цепи или вне цепи. Например:
Простая стратегия: всегда используйте фиксированное количество core или вручную настраивайте его вне сети;
Легкая стратегия: мониторинг конкретной нагрузки транзакций в узле mempool;
Автоматизированные стратегии: предварительный вызов сервиса coretime для настройки ресурсов с помощью исторических данных и интерфейса XCM.
Хотя автоматизированные методы более эффективны, затраты на их реализацию и тестирование также значительно возросли.
Интероперабельность
Polkadot поддерживает интероперабельность между различными rollup, а эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Связь сообщений между кросс-роллапами реализуется на уровне нижнего транспортного слоя, при этом пространство для коммуникационных блоков каждого роллапа фиксировано и не зависит от количества выделенных ядёр.
В будущем Polkadot также будет поддерживать передачу сообщений вне цепи, используя релейную цепь в качестве управляющей плоскости, а не плоскости данных. Это обновление повысит возможности связи между rollup и одновременно улучшит эластичное масштабирование, что дополнительно усилит вертикальные возможности масштабирования системы.
Балансы других протоколов
Как известно, повышение производительности часто требует жертвы в виде децентрализации и безопасности. Однако с точки зрения коэффициента Накамото, даже если у некоторых конкурентов Polkadot уровень децентрализации ниже, их производительность также оставляет желать лучшего.
Некоторый публичный блокчейн A
Некоторый блокчейн A не использует архитектуру шардирования Polkadot или Ethereum, а реализует масштабируемость с помощью одноуровневой архитектуры с высокой пропускной способностью, полагаясь на историческое доказательство, параллельную обработку ЦП и механизм согласования на основе лидера, теоретически достигая TPS до 65,000.
Ключевым дизайном является его заранее опубликованная и проверяемая механика распределения лидеров:
В начале каждого эпохи (примерно каждые два дня или 432 000 слотов) слоты распределяются в зависимости от объема ставки;
Чем больше заложено, тем больше распределение. Например, валидатор, заложивший 1%, получит примерно 1% шансов на создание блока;
Все майнеры заранее объявлены, что увеличивает риск целенаправленных DDoS-атак на сеть и частых сбоев.
История показывает, что параллельная обработка требует крайне высоких аппаратных ресурсов, что приводит к централизации узлов валидации. Чем больше узлов ставится, тем выше вероятность их участия в создании блоков, в то время как у малых узлов почти нет слотов, что усугубляет централизацию и увеличивает риск паралича системы после атаки.
Некоторый блокчейн A в погоне за TPS пожертвовал децентрализацией и устойчивостью к атакам, его коэффициент Накамото составляет всего 20, что значительно ниже, чем у Polkadot, равного 172.
Некоторый публичный блокчейн B
Некоторый публичный блокчейн B заявляет, что его TPS может достигать 104,715, но эта цифра была достигнута в частной тестовой сети, с 256 узлами, в идеальных условиях сети и оборудования. В то же время Polkadot уже достиг 128K TPS в децентрализованной публичной сети.
У механизма консенсуса определенной публичной цепочки B существуют проблемы с безопасностью: идентичность узлов проверки фрагментов будет заранее раскрыта. В белой книге данной публичной цепочки B также четко указано, что хотя это и может оптимизировать пропускную способность, это также может быть использовано злонамеренно. Из-за отсутствия механизма "банкротства игрока" злоумышленник может дождаться, когда определенный фрагмент будет полностью под его контролем, или с помощью DDoS-атаки блокировать честных проверяющих, тем самым изменяя состояние.
В отличие от этого, валидаторы Polkadot распределяются случайным образом и раскрываются с задержкой, атакующие не могут заранее узнать личность валидаторов, для успешной атаки необходимо контролировать все, и если хотя бы один честный валидатор инициирует спор, атака потерпит неудачу и приведет к убыткам атакующего от залога.
Некоторая публичная цепочка C
Некоторый публичный блокчейн C использует архитектуру основной сети + подсетей для масштабирования, при этом основная сеть состоит из X-Chain (переводы, ~4,500 TPS), C-Chain (умные контракты, ~100-200 TPS) и P-Chain (управление валидаторами и подсетями).
Теоретическая TPS для каждой подсети может достигать ~5,000, аналогично подходу Polkadot: снижение нагрузки на отдельные шардов для достижения масштабируемости. Однако в некотором публичном блокчейне C разрешается валидаторам свободно выбирать участие в подсетях, и подсети могут устанавливать дополнительные требования, такие как географические и KYC, что жертвует децентрализацией и безопасностью.
В Polkadot все rollup делят единое обеспечение безопасности; однако у подсети некоторой публичной цепи C нет стандартной гарантии безопасности, и некоторые из них могут быть полностью централизованными. Если вы хотите повысить безопасность, вам все равно придется пойти на компромисс в производительности, и трудно предоставить определенные обязательства по безопасности.
Некоторая публичная цепочка D
Стратегия масштабирования определённой публичной цепочки D заключается в ставках на масштабируемость уровня rollup, а не в прямом решении проблем на базовом уровне. Этот подход по сути не решает проблему, а передаёт её на уровень выше в стеке.
Оптимистичный Роллап
В настоящее время большинство оптимистичных роллапов централизованы (некоторые из них имеют только один секвенсер), что приводит к недостаточной безопасности, изоляции друг от друга и высокой задержке (необходимость ожидания периода мошеннического доказательства, обычно несколько дней).
ZK Rollup
Реализация ZK rollup ограничена объемом данных, которые могут быть обработаны за одну транзакцию. Вычислительные требования для генерации нулевых доказательств очень высоки, и механизм "победитель получает все" может привести к централизации системы. Чтобы обеспечить TPS, ZK rollup часто ограничивает объем транзакций в каждой партии, что в условиях высокого спроса может вызвать перегрузку сети, рост газа и негативно сказаться на пользовательском опыте.
В сравнении, стоимость ZK rollup с полной вычислительной мощностью Тьюринга примерно в 2x10^6 раз превышает стоимость основного криптоэкономического протокола безопасности Polkadot.
Кроме того, проблема доступности данных в ZK rollup также усугубит его недостатки. Чтобы гарантировать, что любой может проверить транзакции, необходимо предоставить полные данные о транзакциях. Это обычно зависит от дополнительных решений по доступности данных, что еще больше увеличивает затраты и сборы для пользователей.
Заключение
Конец масштабируемости не должен быть компромиссом.
В отличие от других публичных цепочек, Polkadot не выбрала путь централизации в обмен на производительность и заранее заданного доверия в обмен на эффективность, а достигла многомерного баланса между безопасностью, децентрализацией и высокой производительностью через гибкое масштабирование, протоколы без разрешений, единую систему безопасности и гибкие механизмы управления ресурсами.
В условиях стремления к более широкому применению сегодня, "нулевая доверительная масштабируемость", которую придерживается Polkadot, возможно, является действительно решением, способным поддерживать долгосрочное развитие Web3.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
13 Лайков
Награда
13
6
Поделиться
комментарий
0/400
FlashLoanKing
· 12ч назад
Можно выиграть за счет скорости? Перекладываем ответственность на пользователей.
Посмотреть ОригиналОтветить0
LiquidityWizard
· 12ч назад
Теоретически говоря, масштабируемость dot = 73.8% компромисс безопасности... не оптимально, если честно.
Посмотреть ОригиналОтветить0
0xOverleveraged
· 12ч назад
Все по-старому, на что ни посмотри, все сводится к rollup.
Посмотреть ОригиналОтветить0
OneBlockAtATime
· 12ч назад
Dot является основой, все остальное - иллюзия.
Посмотреть ОригиналОтветить0
WalletDoomsDay
· 12ч назад
Развлекайся, сначала дай мне. Что тут такого запутанного в Блокчейне?
Посмотреть ОригиналОтветить0
ContractSurrender
· 12ч назад
Жертвовать безопасностью и тому подобным, ладно, лучше сдаться пораньше.
Гибкое масштабирование Polkadot: компромисс между масштабируемостью и безопасностью в экосистеме Web3
Масштабируемость и компромиссы: Технический выбор между Polkadot и экосистемой Web3
В эпоху постоянного стремления технологий блокчейн к более высокой эффективности возникает ключевой вопрос: как обеспечить безопасность и устойчивость системы одновременно с расширением производительности? Это не только вызов на техническом уровне, но и глубокий выбор в архитектурном дизайне. Для экосистемы Web3 просто стремиться к более быстрым системам в ущерб доверию и безопасности невозможно для поддержания действительно устойчивых инноваций.
Как важный движущая сила масштабируемости Web3, жертвовал ли Polkadot чем-то в стремлении достичь высокой пропускной способности и низкой задержки? Не идет ли его модель rollup на компромисс в области децентрализации, безопасности или сетевой интероперабельности? В этой статье мы сосредоточимся на этих вопросах, глубоко проанализируем компромиссы и баланс, которые Polkadot делает в своем дизайне масштабируемости, и сравним их с решениями других основных публичных блокчейнов, исследуя различные пути выбора между производительностью, безопасностью и децентрализацией.
Проблемы, с которыми сталкивается дизайн расширения Polkadot
Баланс между гибкостью и децентрализацией
Архитектура Polkadot зависит от сети валидаторов и релейной цепи, может ли это в некоторых аспектах привести к централизованным рискам? Возможно ли возникновение единой точки отказа или контроля, что повлияет на его децентрализованные характеристики?
Работа Rollup зависит от сортировщика, подключенного к релейной цепи, а его связь использует механизм протокола collator. Этот протокол полностью не требует разрешений и доверия; любой, кто имеет подключение к сети, может использовать его, подключив небольшое количество узлов релейной цепи и отправив запросы на изменение состояния rollup. Эти запросы будут проверены через определённый ядро релейной цепи, при этом необходимо соблюсти одно условие: они должны быть действительными изменениями состояния, в противном случае состояние этого rollup не будет продвинуто.
Торговля вертикальным расширением
Rollup может достичь вертикального масштабирования, используя многопроцессорную архитектуру Polkadot. Эта новая возможность была внедрена с функцией "гибкого масштабирования". В процессе проектирования было обнаружено, что поскольку валидация rollup блоков не фиксируется на каком-либо одном ядре, это может повлиять на его гибкость.
Поскольку протокол подачи блоков в промежуточную цепь не требует разрешения и доверия, любой может представить блок для проверки на любом ядре, назначенном для rollup. Злоумышленники могут использовать это, чтобы многократно отправлять ранее проверенные легитимные блоки на разные ядра, злоупотребляя ресурсами и тем самым снижая общую пропускную способность и эффективность rollup.
Цель Polkadot состоит в том, чтобы поддерживать гибкость rollup и эффективное использование ресурсов релейной цепи без ущерба для ключевых характеристик системы.
Проблема доверия к Sequencer
Одно простое решение состоит в том, чтобы установить протокол как "с разрешением": например, использовать механизм белого списка или по умолчанию доверять сортировщику, который не будет вести себя злоумышленно, тем самым обеспечивая активность rollup.
Однако в концепции дизайна Polkadot мы не можем делать никаких доверительных предположений о sequencer, поскольку необходимо поддерживать характеристики системы "без доверия" и "без разрешений". Любой должен иметь возможность использовать протокол collator для подачи запросов на изменение состояния rollup.
Polkadot: Неумолимое решение
В конечном итоге выбранное решение для Polkadot заключается в том, что все проблемы будут решаться функцией преобразования состояния rollup (Runtime). Runtime является единственным доверенным источником всей информации о консенсусе, поэтому необходимо четко указать, на каком ядре Polkadot должна выполняться проверка.
Этот дизайн обеспечивает двойную защиту эластичности и безопасности. Polkadot будет повторно выполнять преобразования состояния rollup в процессе доступности и обеспечивать правильность распределения core с помощью экономического протокола ELVES.
Перед тем как данные о rollup-блоке будут записаны в слой доступности данных (DA) Polkadot, группа из примерно 5 валидаторов сначала проверяет их законность. Они получают от сортировщика поданные кандидаты на квитанции и доказательства их действительности, которые содержат rollup-блок и соответствующее доказательство хранения. Эта информация будет обработана функцией проверки параллельной цепи и повторно выполнена валидаторами на релейной цепи.
В результате проверки содержится селектор core, который указывает, на каком core следует валидировать блок. Валидатор будет сравнивать этот индекс с тем, за который он отвечает; если они не совпадают, блок будет отброшен.
Этот механизм гарантирует, что система всегда сохраняет свойства без доверия и без разрешений, избегая манипуляций со стороны злонамеренных участников, таких как сортировщики, и обеспечивает устойчивость даже при использовании нескольких ядер в rollup.
безопасность
В процессе стремления к масштабируемости Polkadot не пошел на компромисс в области безопасности. Безопасность rollup обеспечивается релейной цепью, и для поддержания жизнеспособности требуется всего лишь один честный сортировщик.
С помощью протокола ELVES Polkadot полностью расширяет свою безопасность на все rollup, проверяя все вычисления на core, без необходимости ограничивать или делать предположения о количестве используемых core.
Таким образом, rollup Polkadot может обеспечить реальное масштабирование без ущерба для безопасности.
Универсальность
Эластичное масштабирование не ограничивает программируемость роллапов. Модель роллапов Polkadot поддерживает выполнение вычислений с полным числом Тьюринга в среде WebAssembly, при условии, что одно выполнение завершается в течение 2 секунд. Благодаря эластичному масштабированию общее количество вычислений, выполняемых за 6-секундный цикл, увеличивается, но типы вычислений не изменяются.
Комплексность
Более высокая пропускная способность и более низкая задержка неизбежно вводят сложность, что является единственным приемлемым компромиссом в проектировании систем.
Rollup может динамически настраивать ресурсы через интерфейс Agile Coretime для поддержания согласованного уровня безопасности. Они также должны реализовать некоторые требования RFC103, чтобы адаптироваться к различным сценариям использования.
Конкретная сложность зависит от стратегии управления ресурсами rollup, которые могут зависеть от переменных на цепи или вне цепи. Например:
Хотя автоматизированные методы более эффективны, затраты на их реализацию и тестирование также значительно возросли.
Интероперабельность
Polkadot поддерживает интероперабельность между различными rollup, а эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Связь сообщений между кросс-роллапами реализуется на уровне нижнего транспортного слоя, при этом пространство для коммуникационных блоков каждого роллапа фиксировано и не зависит от количества выделенных ядёр.
В будущем Polkadot также будет поддерживать передачу сообщений вне цепи, используя релейную цепь в качестве управляющей плоскости, а не плоскости данных. Это обновление повысит возможности связи между rollup и одновременно улучшит эластичное масштабирование, что дополнительно усилит вертикальные возможности масштабирования системы.
Балансы других протоколов
Как известно, повышение производительности часто требует жертвы в виде децентрализации и безопасности. Однако с точки зрения коэффициента Накамото, даже если у некоторых конкурентов Polkadot уровень децентрализации ниже, их производительность также оставляет желать лучшего.
Некоторый публичный блокчейн A
Некоторый блокчейн A не использует архитектуру шардирования Polkadot или Ethereum, а реализует масштабируемость с помощью одноуровневой архитектуры с высокой пропускной способностью, полагаясь на историческое доказательство, параллельную обработку ЦП и механизм согласования на основе лидера, теоретически достигая TPS до 65,000.
Ключевым дизайном является его заранее опубликованная и проверяемая механика распределения лидеров:
История показывает, что параллельная обработка требует крайне высоких аппаратных ресурсов, что приводит к централизации узлов валидации. Чем больше узлов ставится, тем выше вероятность их участия в создании блоков, в то время как у малых узлов почти нет слотов, что усугубляет централизацию и увеличивает риск паралича системы после атаки.
Некоторый блокчейн A в погоне за TPS пожертвовал децентрализацией и устойчивостью к атакам, его коэффициент Накамото составляет всего 20, что значительно ниже, чем у Polkadot, равного 172.
Некоторый публичный блокчейн B
Некоторый публичный блокчейн B заявляет, что его TPS может достигать 104,715, но эта цифра была достигнута в частной тестовой сети, с 256 узлами, в идеальных условиях сети и оборудования. В то же время Polkadot уже достиг 128K TPS в децентрализованной публичной сети.
У механизма консенсуса определенной публичной цепочки B существуют проблемы с безопасностью: идентичность узлов проверки фрагментов будет заранее раскрыта. В белой книге данной публичной цепочки B также четко указано, что хотя это и может оптимизировать пропускную способность, это также может быть использовано злонамеренно. Из-за отсутствия механизма "банкротства игрока" злоумышленник может дождаться, когда определенный фрагмент будет полностью под его контролем, или с помощью DDoS-атаки блокировать честных проверяющих, тем самым изменяя состояние.
В отличие от этого, валидаторы Polkadot распределяются случайным образом и раскрываются с задержкой, атакующие не могут заранее узнать личность валидаторов, для успешной атаки необходимо контролировать все, и если хотя бы один честный валидатор инициирует спор, атака потерпит неудачу и приведет к убыткам атакующего от залога.
Некоторая публичная цепочка C
Некоторый публичный блокчейн C использует архитектуру основной сети + подсетей для масштабирования, при этом основная сеть состоит из X-Chain (переводы, ~4,500 TPS), C-Chain (умные контракты, ~100-200 TPS) и P-Chain (управление валидаторами и подсетями).
Теоретическая TPS для каждой подсети может достигать ~5,000, аналогично подходу Polkadot: снижение нагрузки на отдельные шардов для достижения масштабируемости. Однако в некотором публичном блокчейне C разрешается валидаторам свободно выбирать участие в подсетях, и подсети могут устанавливать дополнительные требования, такие как географические и KYC, что жертвует децентрализацией и безопасностью.
В Polkadot все rollup делят единое обеспечение безопасности; однако у подсети некоторой публичной цепи C нет стандартной гарантии безопасности, и некоторые из них могут быть полностью централизованными. Если вы хотите повысить безопасность, вам все равно придется пойти на компромисс в производительности, и трудно предоставить определенные обязательства по безопасности.
Некоторая публичная цепочка D
Стратегия масштабирования определённой публичной цепочки D заключается в ставках на масштабируемость уровня rollup, а не в прямом решении проблем на базовом уровне. Этот подход по сути не решает проблему, а передаёт её на уровень выше в стеке.
Оптимистичный Роллап
В настоящее время большинство оптимистичных роллапов централизованы (некоторые из них имеют только один секвенсер), что приводит к недостаточной безопасности, изоляции друг от друга и высокой задержке (необходимость ожидания периода мошеннического доказательства, обычно несколько дней).
ZK Rollup
Реализация ZK rollup ограничена объемом данных, которые могут быть обработаны за одну транзакцию. Вычислительные требования для генерации нулевых доказательств очень высоки, и механизм "победитель получает все" может привести к централизации системы. Чтобы обеспечить TPS, ZK rollup часто ограничивает объем транзакций в каждой партии, что в условиях высокого спроса может вызвать перегрузку сети, рост газа и негативно сказаться на пользовательском опыте.
В сравнении, стоимость ZK rollup с полной вычислительной мощностью Тьюринга примерно в 2x10^6 раз превышает стоимость основного криптоэкономического протокола безопасности Polkadot.
Кроме того, проблема доступности данных в ZK rollup также усугубит его недостатки. Чтобы гарантировать, что любой может проверить транзакции, необходимо предоставить полные данные о транзакциях. Это обычно зависит от дополнительных решений по доступности данных, что еще больше увеличивает затраты и сборы для пользователей.
Заключение
Конец масштабируемости не должен быть компромиссом.
В отличие от других публичных цепочек, Polkadot не выбрала путь централизации в обмен на производительность и заранее заданного доверия в обмен на эффективность, а достигла многомерного баланса между безопасностью, децентрализацией и высокой производительностью через гибкое масштабирование, протоколы без разрешений, единую систему безопасности и гибкие механизмы управления ресурсами.
В условиях стремления к более широкому применению сегодня, "нулевая доверительная масштабируемость", которую придерживается Polkadot, возможно, является действительно решением, способным поддерживать долгосрочное развитие Web3.