Балансировка и вызовы масштабируемости Блокчейн: Решение Polkadot

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

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

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

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

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

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

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

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

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

Решение Polkadot

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

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

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

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

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

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

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

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

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

Сложность

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

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

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

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

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

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

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

Торговля другими протоколами

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

Солана

Solana использует одноуровневую архитектуру с высокой пропускной способностью для достижения масштабируемости, полагаясь на доказательство истории (PoH), параллельную обработку ЦП и механизм согласования на основе лидера, теоретически достигая 65 000 TPS. Ключевым дизайном является заранее опубликованный и проверяемый механизм планирования лидеров.

Однако PoH и параллельная обработка имеют очень высокие требования к оборудованию, что приводит к централизации узлов проверки. Чем больше узлов ставит, тем выше шансы на создание блока, небольшие узлы почти не имеют слотов, что дополнительно усугубляет централизацию и увеличивает риск паралича системы после атаки. Solana, стремясь к TPS, жертвует децентрализацией и устойчивостью к атакам, его коэффициент Накамото составляет всего 20, что значительно ниже 172 у Polkadot.

ТОННА

TON заявляет, что TPS может достигать 104,715, но это число было достигнуто в частной тестовой сети с 256 узлами при идеальных условиях сети и аппаратного обеспечения. А Polkadot уже достиг 128K TPS в децентрализованной публичной сети.

МеханизмConsensusTON имеет проблемы с безопасностью: идентичность узлов валидации шардов может быть заранее раскрыта. Белая книга TON также ясно указывает, что это может оптимизировать пропускную способность, но также может быть использовано во зло. Из-за отсутствия механизма "банкротства игроков" злоумышленник может ждать, пока какой-либо шард окажется полностью под его контролем, или через DDoS-атаку блокировать честных валидаторов, изменяя состояние.

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

Авала́нч

Avalanche использует архитектуру основного сети + подсети для масштабирования. Основная сеть состоит из X-Chain (переводы, ~4500 TPS), C-Chain (умные контракты, ~100-200 TPS) и P-Chain (управление валидаторами и подсетями). Теоретическая TPS каждой подсети может достигать ~5000, что похоже на концепцию Polkadot: снижение нагрузки на отдельный шард для достижения масштабируемости.

Но Avalanche позволяет валидаторам свободно выбирать участие в подсетях, а подсети могут устанавливать дополнительные требования, такие как географические или KYC, жертвуя децентрализацией и безопасностью. В Polkadot все роллапы делят единое обеспечение безопасности; в то время как подсети Avalanche не имеют гарантии безопасности по умолчанию, некоторые из них могут быть полностью централизованными. Если вы хотите повысить безопасность, вам все равно придется пойти на компромисс в производительности, и трудно предоставить определенные гарантии безопасности.

Эфириум

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

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

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

По сравнению с этим, стоимость ZK rollup с полной вычислительной мощностью Тьюринга примерно в 2x10^6 раз выше, чем у основной криптоэкономической безопасности протокола Polkadot. Кроме того, проблемы с доступностью данных в ZK rollup также усугубляют его недостатки. Чтобы обеспечить возможность проверки транзакций любым желающим, необходимо предоставить полные данные о транзакциях. Это обычно зависит от дополнительных решений по доступности данных, что еще больше увеличивает затраты и сборы с пользователей.

Заключение

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

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