Компромисс масштабируемости: выбор между Polkadot и Web3

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

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

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

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

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

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

Торговля вертикальной экспансией

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

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

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

Доверять Sequencer?

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

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

Polkadot: Непреклонное решение

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

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

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

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

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

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

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

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

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

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

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

Сложность

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

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

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

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

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

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

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

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

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

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

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

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

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

Солана

Solana не использует архитектуру шarding от 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 для каждой подсети может достигать ~5000, аналогично подходу Polkadot: уменьшение нагрузки на отдельный шард для достижения масштабируемости. Однако 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 решением.