Балансировка масштабируемости Блокчейн: Исследование Polkadot и экосистемы Web3
В эпоху, когда Блокчейн стремится к более высокой эффективности, постепенно возникает ключевой вопрос: как достичь масштабируемости, не жертвуя безопасностью и устойчивостью системы?
Это не только технический вызов, но и глубокий выбор архитектурного дизайна. Особенно для экосистемы Web3, если более быстрая система строится за счет жертвы доверием и безопасностью, она часто оказывается неспособной поддерживать действительно устойчивые инновации.
Как важный движущая сила масштабируемости Web3, сделал ли Polkadot некоторые жертвы в целях высокой пропускной способности и низкой задержки? Пожертвовал ли его модель rollup децентрализацией, безопасностью или сетевой интероперабельностью?
Данная статья будет сосредоточена на этих вопросах, глубоко анализируя компромиссы и выборы, сделанные Polkadot в дизайне масштабируемости, а также сравнивая их с решениями других основных публичных цепочек, исследуя различные пути выбора между производительностью, безопасностью и децентрализацией.
Проблемы, с которыми сталкивается дизайн расширения Polkadot
Баланс между гибкостью и децентрализацией
Архитектура Polkadot зависит от сети валидаторов и релейной цепи (Relay Chain). Может ли это в каких-либо аспектах привести к рискам централизации? Возможно ли возникновение единой точки отказа или контроля, что может повлиять на его децентрализованные характеристики?
Работа Rollup зависит от секвенсора (sequencer), подключенного к релейной цепочке, который использует механизм, называемый протоколом коллаторов (collator protocol). Этот протокол полностью без разрешений и без доверия, любой, у кого есть сетевое подключение, может его использовать, подключая небольшое количество узлов релейной цепочки и отправляя запросы на изменение состояния rollup. Эти запросы будут проверены каким-либо ядром релейной цепочки, при этом необходимо выполнить одно условие: они должны быть действительными изменениями состояния, иначе состояние данного rollup не будет продвигаться.
Торговые компромиссы вертикального расширения
Rollup может достичь вертикального масштабирования, используя многопоточную архитектуру Polkadot. Эта новая возможность была введена с помощью функции «Эластичное Масштабирование» (Elastic Scaling). В процессе проектирования мы обнаружили, что поскольку верификация блоков rollup не фиксируется на одном ядре, это может повлиять на его эластичность.
Поскольку протокол подачи блоков в релейную цепь является разрешённым и доверительным, любой может подать блок на любую core, назначенную rollup, для проверки. Злоумышленники могут воспользоваться этим, многократно отправляя ранее проверенные легитимные блоки на разные core, злоумышленно расходуя ресурсы и тем самым снижая общую пропускную способность и эффективность rollup.
Цель Polkadot состоит в том, чтобы поддерживать гибкость rollup и эффективное использование ресурсов релейной цепи, не затрагивая ключевые характеристики системы.
Доверять Sequencer?
Одним из простых решений является установка протокола в режим "с разрешением": например, использование механизма белого списка или предположение, что доверенные сортировщики не будут действовать злонамеренно, что обеспечит активность rollup.
Тем не менее, в концепции дизайна Polkadot мы не можем делать никаких доверительных предположений относительно sequencer, так как необходимо сохранить характеристики системы «без доверия» и «без разрешений». Каждый должен иметь возможность использовать протокол collator для подачи запросов на изменение состояния rollup.
Polkadot: Непримиримое решение
Выбор решения для Polkadot в конечном итоге заключается в следующем: полностью передать решение проблемы функции преобразования состояния rollup (Runtime). Runtime является единственным надежным источником всей информации о консенсусе, поэтому необходимо четко указать, на каком ядре Polkadot должно выполняться верификация.
Этот дизайн обеспечивает двойную гарантию гибкости и безопасности. Polkadot будет повторно выполнять преобразование состояния rollup в процессе доступности и обеспечивать правильность распределения core через экономический протокол ELVES.
Перед записью данных rollup блока в слой доступности данных (DA) Polkadot группа из около 5 валидаторов сначала проверяет их законность. Они получают кандидатные квитанции (candidate receipt) и доказательства действительности (PoV), предоставленные сортировщиком, которые содержат блок rollup и соответствующие доказательства хранения. Эта информация будет обработана функцией проверки параллельной цепи и повторно выполнена валидаторами на релейной цепи.
В результате верификации содержится core selector, который указывает, на каком core следует проверить блок. Верификатор будет сравнивать этот индекс с тем core, за который он отвечает; если они не совпадают, этот блок будет отброшен.
Этот механизм гарантирует, что система всегда сохраняет атрибуты без доверия и без разрешений, предотвращая манипуляции злоумышленников, таких как сортировщики, с местами верификации, обеспечивая устойчивость даже при использовании нескольких core в rollup.
безопасность
В процессе стремления к масштабируемости Polkadot не пошел на компромисс в вопросах безопасности. Безопасность rollup обеспечивается релейной цепью, для поддержания жизнеспособности достаточно одного честного сортировщика.
С помощью протокола ELVES Polkadot полностью расширяет свою безопасность на все rollup, проверяя все вычисления на core, не накладывая никаких ограничений или предположений на количество используемых core.
Таким образом, роллап Polkadot может обеспечить истинное расширение без ущерба для безопасности.
Универсальность
Эластичное масштабирование не будет ограничивать программируемость rollup. Модель rollup в Polkadot поддерживает выполнение тьюринг-полных вычислений в среде WebAssembly, при условии, что одно выполнение завершается в течение 2 секунд. Благодаря эластичному масштабированию общее количество вычислений, которые могут быть выполнены в каждом 6-секундном цикле, увеличивается, но тип вычислений не меняется.
Сложность
Более высокая пропускная способность и более низкая задержка неизбежно вносят сложность, что является единственным приемлемым компромиссом в проектировании систем.
Rollup может динамически настраивать ресурсы через интерфейс Agile Coretime для поддержания согласованного уровня безопасности. Они также должны реализовать часть требований RFC103 для адаптации к различным сценариям использования.
Конкретная сложность зависит от стратегии управления ресурсами rollup, которые могут зависеть от переменных на цепи или вне цепи. Например:
Простая стратегия: всегда использовать фиксированное количество core или вручную регулировать вне цепочки;
Легкая стратегия: мониторинг конкретной нагрузки транзакций в узле mempool;
Автоматизированная стратегия: предварительный вызов службы coretime через исторические данные и интерфейс XCM для настройки ресурсов.
Хотя автоматизированные методы более эффективны, затраты на реализацию и тестирование также значительно возрастают.
Интероперабельность
Polkadot поддерживает интероперабельность между различными rollup, в то время как эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Сообщения между кросс-роллапами передаются через нижний уровень транспортного слоя, и пространство коммуникационных блоков для каждого роллапа фиксировано, независимо от количества выделенных ядер.
В будущем Polkadot также будет поддерживать передачу сообщений вне цепи (off-chain messaging), управляемую релейной цепью как контрольной плоскостью, а не как плоскостью данных. Это обновление повысит способность к коммуникации между 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 около ~5,000, что похоже на подход Polkadot: уменьшение нагрузки на отдельный блок для достижения масштабируемости. Однако Avalanche позволяет валидаторам свободно выбирать участие в подсетях, и подсети могут устанавливать географические, KYC и другие дополнительные требования, жертвуя децентрализацией и безопасностью.
В Polkadot все rollup разделяют единое обеспечение безопасности; в то время как подсети Avalanche не имеют гарантии безопасности по умолчанию, некоторые из них могут быть полностью централизованы. Если вы хотите повысить безопасность, вам все равно придется пойти на компромисс в производительности, и будет сложно предоставить определенные обещания безопасности.
Эфириум
Стратегия масштабирования Ethereum делает ставку на масштабируемость уровня rollup, а не на прямое решение проблем на базовом уровне. По сути, этот подход не решает проблему, а передает её на уровень выше в стеке.
Оптимистичный Роллап
В настоящее время большинство Optimistic rollup централизованы (некоторые из них имеют только один sequencer), что приводит к недостаточной безопасности, изолированности друг от друга, высокой задержке (необходимо ждать периода проверки мошенничества, обычно несколько дней) и другим проблемам.
ZK Rollup
Реализация ZK rollup ограничена объемом данных, которые могут быть обработаны в одной транзакции. Требования к вычислениям для генерации нулевых доказательств очень высоки, и механизм "победитель получает все" может привести к централизации системы. Чтобы обеспечить TPS, ZK rollup часто ограничивает объем транзакций в каждой партии, что в условиях высокого спроса может привести к перегрузке сети, увеличению gas и ухудшению пользовательского опыта.
В сравнении, стоимость Turing-complete ZK rollup примерно в 2x10^6 раз выше, чем у основной криптоэкономической модели безопасности Polkadot.
Кроме того, проблема доступности данных ZK rollup также усугубляет его недостатки. Чтобы обеспечить возможность проверки транзакций любым желающим, необходимо предоставить полные данные о транзакциях. Это обычно зависит от дополнительных решений по доступности данных, что дополнительно увеличивает затраты и расходы пользователей.
Заключение
Конец масштабируемости не должен быть компромиссом.
В отличие от других публичных блокчейнов, Polkadot не выбрала путь централизованности ради производительности и предустановленного доверия ради эффективности, а достигла многомерного баланса между безопасностью, децентрализованностью и высокой производительностью через гибкое масштабирование, проектирование разрешительных протоколов, единственный уровень безопасности и гибкие механизмы управления ресурсами.
В стремлении к более широкому применению сегодня, «нулевая доверительная масштабируемость», на которую настаивает Polkadot, возможно, является действительно решением, способным поддерживать долгосрочное развитие Web3.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
14 Лайков
Награда
14
5
Поделиться
комментарий
0/400
SignatureCollector
· 07-30 01:18
点链冲啊 快рост快рост
Посмотреть ОригиналОтветить0
ForumMiningMaster
· 07-30 01:15
Зарабатывать сто тысяч в месяц можно благодаря этим нескольким блокчейнам.
Гибкое масштабирование Polkadot: путь к высокопроизводительному Web3 без компромиссов
Балансировка масштабируемости Блокчейн: Исследование Polkadot и экосистемы Web3
В эпоху, когда Блокчейн стремится к более высокой эффективности, постепенно возникает ключевой вопрос: как достичь масштабируемости, не жертвуя безопасностью и устойчивостью системы?
Это не только технический вызов, но и глубокий выбор архитектурного дизайна. Особенно для экосистемы Web3, если более быстрая система строится за счет жертвы доверием и безопасностью, она часто оказывается неспособной поддерживать действительно устойчивые инновации.
Как важный движущая сила масштабируемости Web3, сделал ли Polkadot некоторые жертвы в целях высокой пропускной способности и низкой задержки? Пожертвовал ли его модель rollup децентрализацией, безопасностью или сетевой интероперабельностью?
Данная статья будет сосредоточена на этих вопросах, глубоко анализируя компромиссы и выборы, сделанные Polkadot в дизайне масштабируемости, а также сравнивая их с решениями других основных публичных цепочек, исследуя различные пути выбора между производительностью, безопасностью и децентрализацией.
Проблемы, с которыми сталкивается дизайн расширения Polkadot
Баланс между гибкостью и децентрализацией
Архитектура Polkadot зависит от сети валидаторов и релейной цепи (Relay Chain). Может ли это в каких-либо аспектах привести к рискам централизации? Возможно ли возникновение единой точки отказа или контроля, что может повлиять на его децентрализованные характеристики?
Работа Rollup зависит от секвенсора (sequencer), подключенного к релейной цепочке, который использует механизм, называемый протоколом коллаторов (collator protocol). Этот протокол полностью без разрешений и без доверия, любой, у кого есть сетевое подключение, может его использовать, подключая небольшое количество узлов релейной цепочки и отправляя запросы на изменение состояния rollup. Эти запросы будут проверены каким-либо ядром релейной цепочки, при этом необходимо выполнить одно условие: они должны быть действительными изменениями состояния, иначе состояние данного rollup не будет продвигаться.
Торговые компромиссы вертикального расширения
Rollup может достичь вертикального масштабирования, используя многопоточную архитектуру Polkadot. Эта новая возможность была введена с помощью функции «Эластичное Масштабирование» (Elastic Scaling). В процессе проектирования мы обнаружили, что поскольку верификация блоков rollup не фиксируется на одном ядре, это может повлиять на его эластичность.
Поскольку протокол подачи блоков в релейную цепь является разрешённым и доверительным, любой может подать блок на любую core, назначенную rollup, для проверки. Злоумышленники могут воспользоваться этим, многократно отправляя ранее проверенные легитимные блоки на разные core, злоумышленно расходуя ресурсы и тем самым снижая общую пропускную способность и эффективность rollup.
Цель Polkadot состоит в том, чтобы поддерживать гибкость rollup и эффективное использование ресурсов релейной цепи, не затрагивая ключевые характеристики системы.
Доверять Sequencer?
Одним из простых решений является установка протокола в режим "с разрешением": например, использование механизма белого списка или предположение, что доверенные сортировщики не будут действовать злонамеренно, что обеспечит активность rollup.
Тем не менее, в концепции дизайна Polkadot мы не можем делать никаких доверительных предположений относительно sequencer, так как необходимо сохранить характеристики системы «без доверия» и «без разрешений». Каждый должен иметь возможность использовать протокол collator для подачи запросов на изменение состояния rollup.
Polkadot: Непримиримое решение
Выбор решения для Polkadot в конечном итоге заключается в следующем: полностью передать решение проблемы функции преобразования состояния rollup (Runtime). Runtime является единственным надежным источником всей информации о консенсусе, поэтому необходимо четко указать, на каком ядре Polkadot должно выполняться верификация.
Этот дизайн обеспечивает двойную гарантию гибкости и безопасности. Polkadot будет повторно выполнять преобразование состояния rollup в процессе доступности и обеспечивать правильность распределения core через экономический протокол ELVES.
Перед записью данных rollup блока в слой доступности данных (DA) Polkadot группа из около 5 валидаторов сначала проверяет их законность. Они получают кандидатные квитанции (candidate receipt) и доказательства действительности (PoV), предоставленные сортировщиком, которые содержат блок rollup и соответствующие доказательства хранения. Эта информация будет обработана функцией проверки параллельной цепи и повторно выполнена валидаторами на релейной цепи.
В результате верификации содержится core selector, который указывает, на каком core следует проверить блок. Верификатор будет сравнивать этот индекс с тем core, за который он отвечает; если они не совпадают, этот блок будет отброшен.
Этот механизм гарантирует, что система всегда сохраняет атрибуты без доверия и без разрешений, предотвращая манипуляции злоумышленников, таких как сортировщики, с местами верификации, обеспечивая устойчивость даже при использовании нескольких core в rollup.
безопасность
В процессе стремления к масштабируемости Polkadot не пошел на компромисс в вопросах безопасности. Безопасность rollup обеспечивается релейной цепью, для поддержания жизнеспособности достаточно одного честного сортировщика.
С помощью протокола ELVES Polkadot полностью расширяет свою безопасность на все rollup, проверяя все вычисления на core, не накладывая никаких ограничений или предположений на количество используемых core.
Таким образом, роллап Polkadot может обеспечить истинное расширение без ущерба для безопасности.
Универсальность
Эластичное масштабирование не будет ограничивать программируемость rollup. Модель rollup в Polkadot поддерживает выполнение тьюринг-полных вычислений в среде WebAssembly, при условии, что одно выполнение завершается в течение 2 секунд. Благодаря эластичному масштабированию общее количество вычислений, которые могут быть выполнены в каждом 6-секундном цикле, увеличивается, но тип вычислений не меняется.
Сложность
Более высокая пропускная способность и более низкая задержка неизбежно вносят сложность, что является единственным приемлемым компромиссом в проектировании систем.
Rollup может динамически настраивать ресурсы через интерфейс Agile Coretime для поддержания согласованного уровня безопасности. Они также должны реализовать часть требований RFC103 для адаптации к различным сценариям использования.
Конкретная сложность зависит от стратегии управления ресурсами rollup, которые могут зависеть от переменных на цепи или вне цепи. Например:
Простая стратегия: всегда использовать фиксированное количество core или вручную регулировать вне цепочки;
Легкая стратегия: мониторинг конкретной нагрузки транзакций в узле mempool;
Автоматизированная стратегия: предварительный вызов службы coretime через исторические данные и интерфейс XCM для настройки ресурсов.
Хотя автоматизированные методы более эффективны, затраты на реализацию и тестирование также значительно возрастают.
Интероперабельность
Polkadot поддерживает интероперабельность между различными rollup, в то время как эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Сообщения между кросс-роллапами передаются через нижний уровень транспортного слоя, и пространство коммуникационных блоков для каждого роллапа фиксировано, независимо от количества выделенных ядер.
В будущем Polkadot также будет поддерживать передачу сообщений вне цепи (off-chain messaging), управляемую релейной цепью как контрольной плоскостью, а не как плоскостью данных. Это обновление повысит способность к коммуникации между 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 около ~5,000, что похоже на подход Polkadot: уменьшение нагрузки на отдельный блок для достижения масштабируемости. Однако Avalanche позволяет валидаторам свободно выбирать участие в подсетях, и подсети могут устанавливать географические, KYC и другие дополнительные требования, жертвуя децентрализацией и безопасностью.
В Polkadot все rollup разделяют единое обеспечение безопасности; в то время как подсети Avalanche не имеют гарантии безопасности по умолчанию, некоторые из них могут быть полностью централизованы. Если вы хотите повысить безопасность, вам все равно придется пойти на компромисс в производительности, и будет сложно предоставить определенные обещания безопасности.
Эфириум
Стратегия масштабирования Ethereum делает ставку на масштабируемость уровня rollup, а не на прямое решение проблем на базовом уровне. По сути, этот подход не решает проблему, а передает её на уровень выше в стеке.
Оптимистичный Роллап
В настоящее время большинство Optimistic rollup централизованы (некоторые из них имеют только один sequencer), что приводит к недостаточной безопасности, изолированности друг от друга, высокой задержке (необходимо ждать периода проверки мошенничества, обычно несколько дней) и другим проблемам.
ZK Rollup
Реализация ZK rollup ограничена объемом данных, которые могут быть обработаны в одной транзакции. Требования к вычислениям для генерации нулевых доказательств очень высоки, и механизм "победитель получает все" может привести к централизации системы. Чтобы обеспечить TPS, ZK rollup часто ограничивает объем транзакций в каждой партии, что в условиях высокого спроса может привести к перегрузке сети, увеличению gas и ухудшению пользовательского опыта.
В сравнении, стоимость Turing-complete ZK rollup примерно в 2x10^6 раз выше, чем у основной криптоэкономической модели безопасности Polkadot.
Кроме того, проблема доступности данных ZK rollup также усугубляет его недостатки. Чтобы обеспечить возможность проверки транзакций любым желающим, необходимо предоставить полные данные о транзакциях. Это обычно зависит от дополнительных решений по доступности данных, что дополнительно увеличивает затраты и расходы пользователей.
Заключение
Конец масштабируемости не должен быть компромиссом.
В отличие от других публичных блокчейнов, Polkadot не выбрала путь централизованности ради производительности и предустановленного доверия ради эффективности, а достигла многомерного баланса между безопасностью, децентрализованностью и высокой производительностью через гибкое масштабирование, проектирование разрешительных протоколов, единственный уровень безопасности и гибкие механизмы управления ресурсами.
В стремлении к более широкому применению сегодня, «нулевая доверительная масштабируемость», на которую настаивает Polkadot, возможно, является действительно решением, способным поддерживать долгосрочное развитие Web3.