Выбор масштабируемости Блокчейна: инновационный путь Polkadot

В эпоху постоянного стремления технологий Блокчейн к более высокой эффективности постепенно начинает проявляться ключевая проблема: как повысить производительность, не жертвуя безопасностью и гибкостью системы? Это не только технологический вызов, но и глубокий выбор архитектурного дизайна. Для экосистемы Web3 более быстрая система, если она построена на основе жертвы доверия и безопасности, как правило, не может поддерживать по-настоящему устойчивые инновации.

Как важный движущая сила масштабируемости Web3, делает ли Polkadot какие-либо компромиссы в стремлении к высокой пропускной способности и низкой задержке? Делает ли его модель rollup уступки в децентрализации, безопасности или сетевой интероперабельности? Эта статья углубится в компромиссы и взвешивания, которые Polkadot принимает в дизайне масштабируемости, и сравнит их с решениями других основных публичных цепей, исследуя различные выборы путей между производительностью, безопасностью и децентрализацией.

Проблемы, с которыми сталкивается дизайн расширения Polkadot

Баланс между гибкостью и децентрализацией

Архитектура Polkadot зависит от сети валидаторов и релейной цепи (Relay Chain), может ли это в некоторых аспектах привести к рискам централизации? Возможно ли образование единой точки сбоя или контроля, что повлияет на его децентрализованные характеристики?

Работа Rollup зависит от сортировщика, соединенного с промежуточной цепью (sequencer), его связь использует механизм, называемый протоколом collator. Этот протокол полностью без разрешений и без доверия, любой человек с сетевым подключением может его использовать, подключив небольшое количество узлов промежуточной цепи и подав запросы на изменение состояния rollup. Эти запросы будут проверяться каким-либо core промежуточной цепи, при условии, что это должно быть действительное изменение состояния, в противном случае состояние rollup не будет продвигаться.

Торговля вертикальным расширением

Rollup может реализовать вертикальное масштабирование, используя многопроцессорную архитектуру Polkadot. Эта новая возможность была введена функцией "弹性扩展"(Elastic Scaling). В процессе проектирования было установлено, что поскольку проверка блоков rollup не фиксируется на каком-либо одном ядре, это может повлиять на его эластичность.

Поскольку протокол подачи блоков в релейную цепь является безразрешительным и не требует доверия, любой может подавать блоки на любую ядро, назначенное rollup для проверки. Злоумышленники могут воспользоваться этим, многократно отправляя ранее проверенные легитимные блоки на разные ядра, злоумышленно расходуя ресурсы и тем самым снижая общую пропускную способность и эффективность rollup.

Цель Polkadot состоит в том, чтобы поддерживать гибкость rollup и эффективное использование ресурсов релейной цепи без ущерба для ключевых характеристик системы.

Проблема доверия к Секвенсеру

Одним из простых решений является установка протокола в режим "с лицензией": например, использование механизма белого списка или предположение, что сортировщик по умолчанию не будет вести себя злонамеренно, что обеспечивает активность rollup.

Однако в концепции дизайна Polkadot мы не можем делать никаких предположений о доверии к секвенсору, поскольку необходимо поддерживать характеристики системы "без доверия" и "без разрешения". Любой должен иметь возможность использовать протокол коллатора для подачи запросов на изменение состояния роллапа.

Polkadot: Непреклонное решение

Выбранное решение для Polkadot: полностью передать проблему функции преобразования состояния rollup (Runtime). Runtime является единственным надежным источником всей информации о консенсусе, поэтому необходимо четко указать, на каком ядре Polkadot должно выполняться подтверждение.

Этот дизайн обеспечивает двойную защиту гибкости и безопасности. Polkadot будет повторно выполнять преобразование состояния rollup в процессе доступности и обеспечивать правильность распределения core через экономический криптопротокол ELVES.

Перед записью данных в доступности Polkadot в любом rollup Блоке (DA), группа из примерно 5 валидаторов сначала проверит его законность. Они принимают кандидатные квитанции (candidate receipt) и доказательства действительности (PoV), содержащие rollup Блок и соответствующее доказательство хранения. Эта информация будет обработана функцией проверки параллельной цепи и повторно выполнена валидаторами на релейной цепи.

Результаты проверки содержат селектор core, который используется для указания, на каком core должен проверяться Блок. Проверяющий сравнит этот индекс с тем, за который он отвечает; если они не совпадают, Блок будет отброшен.

Этот механизм гарантирует, что система всегда сохраняет свойства, не требующие доверия и разрешения, предотвращая манипуляции злоумышленников, таких как сортировщики, с местами верификации, обеспечивая устойчивость даже при использовании нескольких core в rollup.

безопасность

В процессе достижения масштабируемости Polkadot не пошел на компромисс в вопросах безопасности. Безопасность роллапов обеспечивается релейной цепочкой, для поддержания жизнеспособности достаточно одного честного сортировщика.

С помощью протокола ELVES Polkadot полностью расширяет свою безопасность на все rollup, проверяя все вычисления на core, без каких-либо ограничений или предположений по количеству используемых core.

Таким образом, роллапы Polkadot могут обеспечить настоящую масштабируемость без ущерба для безопасности.

Универсальность

Эластичное масштабирование не будет ограничивать программируемость rollup. Модель rollup в Polkadot поддерживает выполнение вычислений с полным набором команд в среде WebAssembly, при условии, что одно выполнение завершается в течение 2 секунд. Благодаря эластичному масштабированию общее количество вычислений, выполняемых за 6-секундный цикл, увеличивается, но тип вычислений не затрагивается.

Сложность

Более высокая пропускная способность и более низкая задержка неизбежно вводят сложность, что является единственным приемлемым компромиссом в системном проектировании.

Rollup может динамически настраивать ресурсы через интерфейс Agile Coretime для поддержания постоянного уровня безопасности. Они также должны выполнить часть требований RFC103, чтобы адаптироваться к различным сценариям использования.

Конкретная сложность зависит от стратегии управления ресурсами rollup, которые могут зависеть от переменных на цепочке или вне цепочки. Например:

• Простая стратегия: всегда используйте фиксированное количество core, или вручную корректируйте вне цепи;
• Легкая стратегия: мониторинг конкретной нагрузки транзакций в мемпуле узла;
• Автоматизированная стратегия: предварительно вызывайте службу 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, что значительно ниже 172 у Polkadot.

ТОН

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 все роллапы разделяют единую безопасность; в то время как подсети Avalanche не имеют гарантии безопасности по умолчанию, некоторые из них могут быть полностью централизованными. Если вы хотите повысить безопасность, вам все равно придется пойти на компромисс в производительности, и сложно предоставить гарантии безопасности.

Эфириум

Стратегия масштабирования Ethereum заключается в том, чтобы делать ставку на масштабируемость уровня rollup, а не решать проблемы напрямую на базовом уровне. Этот подход по сути не решает проблему, а передает ее на уровень выше в стеке.

Оптимистичный роллап

В настоящее время большинство Optimistic rollup являются централизованными (, некоторые из них имеют только один sequencer ), что приводит к недостаточной безопасности, изоляции друг от друга, высокой задержке ( и необходимости ожидания периода проверки мошенничества, который обычно составляет несколько дней ) и т.д.

ZK Rollup

Реализация ZK rollup ограничена объемом данных, которые могут обрабатываться в одной транзакции. Запросы на вычисление нулевых доказательств требуют огромных ресурсов, а механизм "победитель получает все" легко приводит к централизации системы. Чтобы гарантировать TPS, ZK rollup часто ограничивает объем транзакций в каждой партии, что в условиях высокого спроса может привести к перегрузке сети, росту gas и ухудшению пользовательского опыта.

В сравнении с этим, стоимость ZK rollup с полной Turing-совместимостью примерно в 2x10^6 раз больше, чем стоимость основной криптоэкономической безопасности протокола Polkadot.

Кроме того, проблема доступности данных ZK rollup также усугубит его недостатки. Для того чтобы любой мог проверить транзакцию, необходимо предоставить полные данные о транзакции. Это обычно зависит от дополнительных решений по доступности данных, что дополнительно повышает затраты и сборы для пользователей.

Заключение

Конец масштабируемости не должен быть компромиссом.

В отличие от других публичных цепей, Polkadot не пошел по пути централизации ради производительности и предустановленного доверия ради эффективности, а достиг многомерного баланса безопасности, децентрализации и высокой производительности через эластичное расширение, дизайн без разрешений, унифицированный уровень безопасности и гибкий механизм управления ресурсами.

В эпоху стремления к более широкому внедрению Polkadot, придерживающийся "нулевой доверительной масштабируемости", возможно, является тем самым решением, которое действительно сможет поддерживать долгосрочное развитие Web3.