Баланс расширяемости: выбор между Polkadot и Web3

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

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

Проблемы проектирования расширения Polkadot

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

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

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

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

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

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

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

Достоверен ли Sequencer?

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

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

Polkadot: Непосредственное решение

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

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

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

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

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

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

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

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

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

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

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

Сложность

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

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

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

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

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

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

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

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

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

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

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

Какие компромиссы были сделаны другими протоколами?

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

Солана

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

Ключевым элементом дизайна является заранее открытый и проверяемый механизм назначения лидеров:

• В начале каждого эпохи (примерно каждые два дня или 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 каждого подсети может достигать ~5000, подобно концепции Polkadot: уменьшение нагрузки на отдельный шард для достижения масштабируемости. Однако Avalanche позволяет валидаторам свободно выбирать участие в подсети, и подсети могут устанавливать дополнительные требования, такие как географические и KYC, что жертвует децентрализацией и безопасностью.

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

Эфириум

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

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

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

ZK Rollup

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

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

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

Заключение

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

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

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