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

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

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

Polkadot как важный двигатель масштабируемости Web3, делает ли его модель 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.

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

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

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

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

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

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

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

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

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

Сложность

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторый публичный блокчейн A

Некоторый публичный блокчейн A не использует архитектуру шардирования Polkadot или Ethereum, а реализует масштабируемость с помощью одноуровневой высокопропускной архитектуры, полагаясь на историческое доказательство, параллельную обработку ЦП и механизм согласия, основанный на лидере, с теоретической TPS до 65 000.

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

• В начале каждого эпохи (примерно каждые два дня или 432 000 слотов) слоты распределяются в зависимости от объема стейка;

• Чем больше заложено, тем больше распределение. Например, валидатор, заложивший 1%, получит около 1% шансов на создание блока;

• Все майнеры объявляются заранее, что увеличивает риск целенаправленных DDoS-атак на сеть и частых простоев.

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

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

Некоторый публичный блокчейн B

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

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

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

Некоторый публичный блокчейн C

Некоторый публичный блокчейн C использует архитектуру основной сети + подсети для масштабирования. Основная сеть состоит из X-Chain (переводы, ~4,500 TPS), C-Chain (умные контракты, ~100--200 TPS) и P-Chain (управление валидаторами и подсетями).

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

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

Эфириум

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

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

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

ZK Rollup

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

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

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

Заключение

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

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

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