Баланс между масштабируемостью, безопасностью и Децентрализацией: технический выбор Polkadot

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

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

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

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

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

Баланс гибкости и Децентрализации

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

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

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

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

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

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

Sequencer стоит доверять?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комплексность

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

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

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

• Простая стратегия: всегда использовать фиксированное количество core, или вручную корректировать вне цепи;

• Легкая стратегия: мониторинг конкретной нагрузки транзакций в узле mempool;

• Автоматизированная стратегия: заранее настраивайте ресурсы с помощью исторических данных и интерфейса XCM, вызывая сервис coretime.

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

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

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 (переводы, ~4,500 TPS), C-Chain (умные контракты, ~100-200 TPS) и P-Chain (управление валидаторами и подсетями).

Теоретическая TPS каждой подсети может достигать ~5 000, что похоже на идею Polkadot: снижение нагрузки на отдельный shard для достижения масштабируемости. Но Avalanche позволяет валидаторам свободно выбирать участие в подсетях, и подсети могут устанавливать географические, KYC и другие дополнительные требования, жертвуя Децентрализацией и безопасностью.

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

Эфириум

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

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

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

ZK Rollup

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

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

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

Заключение

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

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

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