Выбор масштабируемости: Полкадот и путь к Web3

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

Как важный движущий фактор масштабируемости Web3, сделал ли Polkadot некоторые жертвы в достижении целей высокой пропускной способности и низкой задержки? Сделала ли его модель rollup уступки в децентрализации, безопасности или сетевой интероперабельности?

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

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

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

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

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

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

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

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

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

Проблема доверия Sequencer

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

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

Polkadot: безкомпромиссное решение

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

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

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

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

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

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

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

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

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

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

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

Сложность

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

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

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

• Простая стратегия: всегда используйте фиксированное количество core, или вручную регулируйте его вне цепи;
• Легкая стратегия: мониторинг конкретной нагрузки транзакций в узле mempool;
• Автоматизированная стратегия: заранее вызывайте службу coretime для настройки ресурсов с помощью исторических данных и интерфейса XCM.

Хотя автоматизированные методы более эффективны, затраты на их реализацию и тестирование также значительно возрастают.

Интероперабельность

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

Сообщения между кросс-роллапами реализуются на уровне нижнего транспортного слоя, и пространство блока связи для каждого роллапа фиксировано и не зависит от количества выделенных ему ядер.

В будущем Polkadot будет поддерживать передачу сообщений вне цепи, при этом релейная цепь будет выступать в качестве контрольного уровня, а не уровня данных. Это обновление повысит возможности связи между 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( для переводов, ~4500 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 часто ограничивает объем транзакций в каждой партии, что в условиях высокого спроса может вызвать перегрузку сети, повышение стоимости газа и негативно сказаться на пользовательском опыте.

В сравнении, стоимость ZK rollup с полным поддержкой Тьюринга примерно в 2×10^6 раз больше, чем стоимость основного протокола безопасности криптоэкономики Polkadot.

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

Заключение

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

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

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