Баланс масштабируемости Блокчейна: на примере Polkadot
В условиях постоянного стремления к более высокой эффективности технологий Блокчейн, одна ключевая проблема постепенно становится очевидной: как повысить производительность, не жертвуя безопасностью и устойчивостью системы? Это не только технологический вызов, но и глубокий выбор в архитектурном дизайне. Для экосистемы Web3 более быстрая система, если она основана на жертве доверия и безопасности, как правило, не может поддерживать действительно устойчивые инновации.
В данной статье будет глубоко рассмотрены компромиссы и уступки, связанные с дизайном масштабируемости Polkadot, а также проведено сравнение с решениями других основных публичных блокчейнов, анализируя их различные пути выбора между производительностью, безопасностью и децентрализацией.
Проблемы, с которыми сталкивается проектирование расширения Polkadot
Баланс между гибкостью и децентрализацией
Архитектура Polkadot зависит от сети валидаторов и реле цепи (Relay Chain). Работа Rollup зависит от секвенсора (sequencer), подключенного к реле цепи, который использует механизм протокола collator для связи. Этот протокол полностью не требует разрешений и доверия; любой, у кого есть подключение к сети, может его использовать, подключив небольшое количество узлов реле цепи и подав запросы на изменение состояния Rollup. Эти запросы будут проверяться одним из основных узлов реле цепи, при этом необходимо выполнить одно условие: они должны быть допустимыми изменениями состояния, иначе состояние Rollup не будет продвигаться.
Торговля вертикальным масштабированием
Роллап может обеспечить вертикальное масштабирование, используя многопроцессорную архитектуру Polkadot. Эта новая возможность была введена функцией "Эластичное масштабирование" (Elastic Scaling). В процессе проектирования было установлено, что поскольку валидация блоков роллапа не фиксируется на каком-либо конкретном ядре, это может повлиять на его эластичность.
Поскольку протокол подачи блоков в релейную цепь является безразрешительным и бездоверительным, любой может отправить блок на любую из основных цепей, назначенных для валидации rollup. Злоумышленники могут использовать это, чтобы многократно отправлять ранее проверенные законные блоки на разные основные цепи, злоупотребляя ресурсами и тем самым снижая общую пропускную способность и эффективность rollup.
Цель Polkadot заключается в поддержании гибкости rollup и эффективном использовании ресурсов релейной цепи без ущерба для ключевых характеристик системы.
Проблема доверия Sequencer
Одним из простых решений является установка протокола как "с разрешением": например, использование механизма белого списка или предположение, что сортировщик по умолчанию не будет действовать злонамеренно, что обеспечит активность rollup. Однако в концепции дизайна Polkadot мы не можем делать никаких предположений о доверии к sequencer, так как необходимо сохранить характеристики системы "без доверия" и "без разрешения". Любой должен иметь возможность использовать протокол collator для подачи запросов на изменение состояния rollup.
Polkadot: Непреклонное решение
Полкадот в конечном итоге выбрал решение: полностью передать проблему функции преобразования состояния rollup (Runtime). Runtime является единственным надежным источником всей информации о консенсусе, поэтому необходимо явно указать, на каком ядре Polkadot следует выполнять проверку.
Этот дизайн обеспечивает двойную защиту гибкости и безопасности. Polkadot будет повторно выполнять состояние перехода rollup в процессе доступности и гарантировать правильность распределения core через экономический криптопротокол ELVES.
Перед тем как данные rollup блока будут записаны в слой доступности данных (DA) Polkadot, группа из около 5 валидаторов сначала проверит их законность. Они получают кандидатные квитанции (candidate receipt) и доказательства действительности (PoV), которые содержат блок 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;
Автоматизированная стратегия: предварительный вызов сервиса coretime через исторические данные и интерфейс XCM для настройки ресурсов.
Хотя автоматизированные методы более эффективны, затраты на реализацию и тестирование также значительно возросли.
Интероперабельность
Polkadot поддерживает интероперабельность между различными rollup, при этом эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Сообщения между rollup'ами передаются через нижний уровень транспортного слоя, и пространство для коммуникационных блоков каждого rollup фиксировано и не зависит от количества выделенных ядер.
В будущем Polkadot также будет поддерживать передачу сообщений вне цепи (off-chain messaging), где релейная цепь будет выступать в роли контрольного слоя, а не слоя данных. Это обновление позволит улучшить возможности связи между роллапами с одновременным увеличением эластичности, что дополнительно усилит вертикальную масштабируемость системы.
Балансировка других протоколов
Как всем известно, повышение производительности часто достигается за счет жертвования децентрализацией и безопасностью. Однако с точки зрения коэффициента Накамото, даже если у некоторых конкурентов 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.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
9 Лайков
Награда
9
6
Поделиться
комментарий
0/400
GateUser-a5fa8bd0
· 1ч назад
dot нужно хорошо изучить! На старом ремесле не полагаются.
Посмотреть ОригиналОтветить0
AirdropworkerZhang
· 08-01 00:33
Эта эффективность чертовски высокая, а стоимость чертовски низкая, босс, я пошел майнить.
Посмотреть ОригиналОтветить0
MEVHunter
· 07-31 10:51
мэ... релейная цепь dot все еще испытывает узкие места под сильным давлением мемпула, если честно. видел токсичные всплески потока на прошлой неделе
Посмотреть ОригиналОтветить0
Lonely_Validator
· 07-31 10:51
Старый игрок в публичные блокчейны, Dot на протяжении всего времени в фаворе.
Гибкое масштабирование Polkadot: непримиримый баланс производительности и безопасности Web3
Баланс масштабируемости Блокчейна: на примере Polkadot
В условиях постоянного стремления к более высокой эффективности технологий Блокчейн, одна ключевая проблема постепенно становится очевидной: как повысить производительность, не жертвуя безопасностью и устойчивостью системы? Это не только технологический вызов, но и глубокий выбор в архитектурном дизайне. Для экосистемы Web3 более быстрая система, если она основана на жертве доверия и безопасности, как правило, не может поддерживать действительно устойчивые инновации.
В данной статье будет глубоко рассмотрены компромиссы и уступки, связанные с дизайном масштабируемости Polkadot, а также проведено сравнение с решениями других основных публичных блокчейнов, анализируя их различные пути выбора между производительностью, безопасностью и децентрализацией.
Проблемы, с которыми сталкивается проектирование расширения Polkadot
Баланс между гибкостью и децентрализацией
Архитектура Polkadot зависит от сети валидаторов и реле цепи (Relay Chain). Работа Rollup зависит от секвенсора (sequencer), подключенного к реле цепи, который использует механизм протокола collator для связи. Этот протокол полностью не требует разрешений и доверия; любой, у кого есть подключение к сети, может его использовать, подключив небольшое количество узлов реле цепи и подав запросы на изменение состояния Rollup. Эти запросы будут проверяться одним из основных узлов реле цепи, при этом необходимо выполнить одно условие: они должны быть допустимыми изменениями состояния, иначе состояние Rollup не будет продвигаться.
Торговля вертикальным масштабированием
Роллап может обеспечить вертикальное масштабирование, используя многопроцессорную архитектуру Polkadot. Эта новая возможность была введена функцией "Эластичное масштабирование" (Elastic Scaling). В процессе проектирования было установлено, что поскольку валидация блоков роллапа не фиксируется на каком-либо конкретном ядре, это может повлиять на его эластичность.
Поскольку протокол подачи блоков в релейную цепь является безразрешительным и бездоверительным, любой может отправить блок на любую из основных цепей, назначенных для валидации rollup. Злоумышленники могут использовать это, чтобы многократно отправлять ранее проверенные законные блоки на разные основные цепи, злоупотребляя ресурсами и тем самым снижая общую пропускную способность и эффективность rollup.
Цель Polkadot заключается в поддержании гибкости rollup и эффективном использовании ресурсов релейной цепи без ущерба для ключевых характеристик системы.
Проблема доверия Sequencer
Одним из простых решений является установка протокола как "с разрешением": например, использование механизма белого списка или предположение, что сортировщик по умолчанию не будет действовать злонамеренно, что обеспечит активность rollup. Однако в концепции дизайна Polkadot мы не можем делать никаких предположений о доверии к sequencer, так как необходимо сохранить характеристики системы "без доверия" и "без разрешения". Любой должен иметь возможность использовать протокол collator для подачи запросов на изменение состояния rollup.
Polkadot: Непреклонное решение
Полкадот в конечном итоге выбрал решение: полностью передать проблему функции преобразования состояния rollup (Runtime). Runtime является единственным надежным источником всей информации о консенсусе, поэтому необходимо явно указать, на каком ядре Polkadot следует выполнять проверку.
Этот дизайн обеспечивает двойную защиту гибкости и безопасности. Polkadot будет повторно выполнять состояние перехода rollup в процессе доступности и гарантировать правильность распределения core через экономический криптопротокол ELVES.
Перед тем как данные rollup блока будут записаны в слой доступности данных (DA) Polkadot, группа из около 5 валидаторов сначала проверит их законность. Они получают кандидатные квитанции (candidate receipt) и доказательства действительности (PoV), которые содержат блок rollup и соответствующее доказательство хранения. Эта информация будет обработана функцией проверки параллельной цепи и повторно выполнена валидаторами на релейной цепи.
В результате проверки содержится селектор core, который указывает, на каком core следует проверять Блок. Валидация будет сравнивать этот индекс с тем, за который отвечает сам core; если они не совпадают, этот Блок будет отброшен.
Этот механизм гарантирует, что система всегда сохраняет свойства без доверия и без разрешения, предотвращая манипуляции местом верификации со стороны злонамеренных участников, таких как сортировщики, и обеспечивает устойчивость даже при использовании нескольких ядер в rollup.
безопасность
В процессе стремления к масштабируемости Polkadot не пошел на компромисс в вопросах безопасности. Безопасность rollup обеспечивается релейной цепочкой, для поддержания живучести требуется всего лишь один честный сортировщик.
С помощью протокола ELVES, Polkadot полностью расширяет свою безопасность на все rollup, проверяя все вычисления на core, без необходимости ограничивать или предполагать количество используемых core.
Таким образом, rollup Polkadot может обеспечить настоящую масштабируемость без ущерба для безопасности.
Универсальность
Эластичное расширение не будет ограничивать программируемость роллапов. Модель роллапов Polkadot поддерживает выполнение тьюринг-полных вычислений в среде WebAssembly, при условии, что одно выполнение завершается в течение 2 секунд. С помощью эластичного расширения общее количество вычислений, которое можно выполнить за 6-секундный цикл, увеличивается, но типы вычислений остаются неизменными.
Сложность
Более высокая пропускная способность и более низкая задержка неизбежно вводят сложность, что является единственным приемлемым компромиссом в системном дизайне.
Rollup может динамически настраивать ресурсы через интерфейс Agile Coretime для поддержания согласованного уровня безопасности. Им также необходимо реализовать некоторые требования RFC103 для адаптации к различным сценариям использования.
Конкретная сложность зависит от стратегии управления ресурсами rollup, которая может основываться на переменных как на цепочке, так и вне ее. Например:
Хотя автоматизированные методы более эффективны, затраты на реализацию и тестирование также значительно возросли.
Интероперабельность
Polkadot поддерживает интероперабельность между различными rollup, при этом эластичное масштабирование не влияет на пропускную способность передачи сообщений.
Сообщения между rollup'ами передаются через нижний уровень транспортного слоя, и пространство для коммуникационных блоков каждого rollup фиксировано и не зависит от количества выделенных ядер.
В будущем Polkadot также будет поддерживать передачу сообщений вне цепи (off-chain messaging), где релейная цепь будет выступать в роли контрольного слоя, а не слоя данных. Это обновление позволит улучшить возможности связи между роллапами с одновременным увеличением эластичности, что дополнительно усилит вертикальную масштабируемость системы.
Балансировка других протоколов
Как всем известно, повышение производительности часто достигается за счет жертвования децентрализацией и безопасностью. Однако с точки зрения коэффициента Накамото, даже если у некоторых конкурентов Polkadot уровень децентрализации ниже, их производительность тоже оставляет желать лучшего.
Солана
Solana не использует архитектуру шардирования Polkadot или Ethereum, а реализует масштабируемость с помощью одноуровневой высокопроизводительной архитектуры, полагаясь на доказательство истории (PoH), параллельную обработку CPU и консенсусный механизм на основе лидера, теоретическая TPS может достигать 65,000.
Ключевым элементом дизайна является заранее открытый и проверяемый механизм назначения лидеров:
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.