Баланс расширяемости Блокчейна: Полкадот и путь к Web3

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

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

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

Баланс между эластичностью и децентрализацией

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

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

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

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

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

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

Доверен ли Sequencer?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сложность

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

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

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

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

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

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

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

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

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

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

Эфириум

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

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

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

ZK Rollup

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

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

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

Заключение

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

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

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