Шардинг состояния

Что такое шардинг состояния в криптовалюте?

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

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

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

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

Шардинг состояния применяет эту идею непосредственно к состоянию блокчейна.

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

Это может повысить пропускную способность, поскольку несколько шардов способны одновременно обрабатывать транзакции.

Также это может снизить требования к оборудованию, поскольку каждому узлу может не требоваться хранить все активное состояние.

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

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

Почему шардинг состояния важен

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

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

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

Это может ослабить децентрализацию, поскольку запуск полных узлов смогут позволить себе только крупные операторы.

Шардинг состояния стремится решить эту проблему, позволяя сети масштабироваться горизонтально.

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

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

Этот подход привлекателен, поскольку способен увеличивать емкость без необходимости обработки каждой транзакции всеми узлами.

Следовательно, шардинг состояния — это не только ускорение работы.

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

Как работает шардинг состояния

Блокчейн с шардингом состояния делит глобальное состояние на несколько шардов.

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

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

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

Транзакции, затрагивающие несколько шардов, требуют межшардовой коммуникации.

Координатор, beacon chain, основная цепь, глобальный уровень консенсуса или протокол связи между шардами могут помогать поддерживать согласованность системы.

Сеть должна гарантировать, что ни один шард не принимает недействительные транзакции.

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

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

Настоящая цепь с шардингом состояния должна обеспечивать работу множества шардов как единой согласованной блокчейн-системы.

Шардинг состояния и шардинг транзакций

Шардинг транзакций разделяет обработку транзакций между разными группами.

Шардинг состояния разделяет фактическое состояние блокчейна между разными группами.

Система может шардировать транзакции без полного шардинга состояния, если всем валидаторам все еще необходимо знать все состояние.

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

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

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

Для платежа из одного шарда в другой требуется безопасная система межшардовых сообщений или квитанций.

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

Шардинг транзакций повышает пропускную способность, разделяя работу.

Шардинг состояния повышает как пропускную способность, так и масштабируемость хранения, разделяя данные, от которых зависит эта работа.

Шардинг состояния и шардинг данных

Шардинг состояния отличается от шардинга данных.

Шардинг состояния разделяет актуальное состояние исполнения блокчейна.

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

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

В официальной документации Ethereum по danksharding указано, что ни danksharding, ни proto-danksharding не следуют традиционной модели шардинга, разделяющей блокчейн на несколько частей.

В документации объясняется, что danksharding построен вокруг крупных блобов данных для роллапов, а не вокруг разделения Ethereum Mainnet на традиционные шарды исполнения.

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

Старые обсуждения дорожной карты Ethereum включали идеи шардинга исполнения и состояния.

Современное масштабирование Ethereum использует роллапы, блобы, исследования выборки доступности данных и концепции danksharding вместо традиционной модели исполнения с множеством шардов.

Шардинг состояния и шардинг данных — это идеи масштабирования, но они решают разные узкие места.

Шардинг состояния и роллапы

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

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

Роллапы могут быть проще для добавления в существующую цепь, поскольку не требуют от базового уровня разделять собственное состояние исполнения.

Шардинг состояния — это более глубокое изменение архитектуры базового уровня.

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

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

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

Именно поэтому текущая дорожная карта Ethereum поддерживает масштабирование роллапов с помощью данных в блобах, а не традиционного шардинга состояния.

Шардинг состояния все еще может использоваться в других дизайнах Layer 1.

Ключевое различие состоит в том, что роллапы выносят исполнение в системы Layer 2, тогда как шардинг состояния разделяет исполнение и состояние внутри самого Layer 1.

Почему шардинг состояния сложен

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

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

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

Если межшардовые сообщения медленные, приложения могут ощущаться фрагментированными.

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

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

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

В академическом обзоре Building Blocks of Sharding Blockchain Systems выделяются ключевые компоненты шардинга: выбор узлов, случайность, назначение узлов, внутрешардовый консенсус, обработка межшардовых транзакций, реконфигурация шардов и механизмы стимулов.

Это показывает, что шардинг состояния — не одна функция.

Это полноценная системная архитектура со множеством взаимосвязанных компонентов.

Шарды

Шард — это один раздел состояния блокчейна и среды исполнения.

Каждый шард может содержать подмножество аккаунтов, контрактов, объектов, хранилища или транзакций.

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

В более продвинутом дизайне границы шардов могут меняться со временем посредством решардинга.

Шард должен обрабатывать локальные транзакции без необходимости запрашивать одобрение каждого другого шарда.

Такая параллельная обработка — основное преимущество масштабирования.

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

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

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

Следовательно, шард — это одновременно единица масштабирования и задача координации.

Валидаторы шардов

Валидаторы шардов — это валидаторы, назначенные проверять, производить или одобрять активность в конкретном шарде.

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

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

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

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

Поэтому случайность важна для многих систем шардинга.

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

Шардинг состояния не устраняет необходимость консенсуса.

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

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

Межшардовые транзакции

Межшардовая транзакция — это транзакция, затрагивающая состояние более чем одного шарда.

Межшардовые транзакции — одна из наиболее сложных частей шардинга состояния.

Простой перевод внутри одного шарда можно обработать локально.

Перевод с аккаунта в одном шарде на аккаунт в другом должен координироваться между шардами.

Вызов смарт-контракта с участием нескольких шардов может быть еще сложнее.

Система должна гарантировать, что исходный и целевой шарды согласны с произошедшим.

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

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

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

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

Асинхронное исполнение

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

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

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

Однако асинхронное исполнение меняет подход разработчиков к созданию приложений.

Контракт может не иметь возможности вызвать другой шард и получить результат сразу в рамках одной транзакции.

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

Это может усложнять межшардовые DeFi, игры, маркетплейсы и компонуемые приложения.

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

Компромисс заключается между скоростью и параллелизмом, с одной стороны, и простотой синхронных приложений — с другой.

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

Атомарная компонуемость

Атомарная компонуемость означает, что несколько действий смарт-контрактов могут произойти совместно как одна неделимая транзакция.

Если не удается любая часть, не выполняется вся транзакция.

Системы смарт-контрактов с одним шардом часто упрощают атомарную компонуемость, поскольку все релевантное состояние доступно в одной среде исполнения.

Шардинг состояния может усложнить атомарную компонуемость, когда контракты расположены в разных шардах.

Сделке DeFi может потребоваться обратиться к протоколу кредитования, пулу ликвидности, оракулу и хранилищу в одной транзакции.

Если эти контракты находятся в разных шардах, синхронное исполнение может быть сложным или дорогостоящим.

Это одна из причин, по которым шардинг состояния создает сложности для проектирования DeFi.

Некоторые шардированные системы могут поощрять размещение связанных контрактов в одном шарде.

Другие системы могут предоставлять специальные инструменты межшардовой коммуникации.

Атомарная компонуемость — один из основных компромиссов, которые пользователям и разработчикам следует понимать при изучении шардинга состояния.

Шардинг состояния и смарт-контракты

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

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

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

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

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

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

Шардинг состояния проще для простых переводов между аккаунтами, чем для высококомпонуемых систем DeFi.

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

Например, игра или среда, подобная appchain, может сохранять большую часть активности внутри одного шарда.

Сильно взаимосвязанные финансовые приложения могут нуждаться в более сложном межшардовом дизайне.

Шардинг состояния и NEAR

NEAR — один из наиболее известных примеров блокчейна, спроектированного вокруг шардинга.

В официальной документации NEAR говорится, что шардинг Nightshade обеспечивает линейное масштабирование пропускной способности по мере роста числа валидаторов.

Nightshade — это дизайн шардинга NEAR.

На официальной странице материалов NEAR Nightshade описывается как дизайн, в актуальной версии которого и состояние, и обработка разделены между шардами.

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

NEAR также работал над безсостоянной валидацией, меняющей способ участия валидаторов в проверке шардов.

В официальной публикации NEAR о запуске Nightshade 2.0 говорится, что Nightshade 2.0 внедрил безсостоянную валидацию в NEAR Mainnet в августе 2024 года.

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

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

Шардинг состояния и Ethereum

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

Однако текущая дорожная карта Ethereum не сосредоточена на традиционном шардинге исполнения или состояния для Mainnet.

На официальной странице Ethereum о danksharding указано, что ни proto-danksharding, ни danksharding не следуют традиционной модели шардинга.

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

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

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

Текущее направление масштабирования Ethereum ориентировано на роллапы.

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

Шардинг состояния остается важной концепцией блокчейна, но его не следует описывать как текущий план исполнения Ethereum Mainnet.

Для точного обучения криптовалютам Ethereum следует использовать как пример эволюции исследований шардинга, а не как текущую реализацию шардинга состояния.

Шардинг состояния и безсостоянная валидация

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

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

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

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

Nightshade 2.0 от NEAR — практический пример добавления безсостоянной валидации к архитектуре шардинга.

Исследования Ethereum также рассматривали безсостоянных клиентов и меньших свидетелей через изменения обязательств состояния.

Безсостоянная валидация не идентична шардингу состояния.

Шардинг состояния разделяет состояние между шардами.

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

Вместе они могут снизить требования к оборудованию узлов, сохраняя возможность проверки.

Шардинг состояния и доступность данных

Доступность данных — это гарантия того, что данные, необходимые для проверки или восстановления переходов состояния, доступны сети.

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

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

Именно поэтому доступность данных является ключевой проблемой в шардированных системах.

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

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

Эта концепция широко применима к системам масштабирования, включая роллапы и шардированные цепи.

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

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

Сильный дизайн шардинга состояния должен решать как задачу разделения исполнения, так и задачу доступности данных.

Шардинг состояния и безопасность

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

Один шард не должен становиться легкой целью для компрометации лишь потому, что к нему назначено меньше валидаторов.

Иногда это называют проблемой захвата одного шарда.

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

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

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

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

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

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

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

Шардинг состояния и децентрализация

Шардинг состояния может поддерживать децентрализацию, снижая нагрузку на ресурсы отдельных узлов.

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

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

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

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

Если мосты или межшардовые маршрутизаторы становятся узкими местами, экономическая активность может сосредоточиться вокруг этих сервисов.

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

Хороший шардинг состояния должен снизить нагрузку на отдельные узлы, не создавая новых централизованных зависимостей в других местах.

Децентрализацию следует оценивать применительно к валидаторам, полным узлам, клиентам, поставщикам RPC, мостам, кошелькам и инфраструктуре приложений.

Шардинг состояния помогает лишь в том случае, если вся система остается открытой и проверяемой.

Шардинг состояния и пользовательский опыт

В идеале шардинг состояния должен быть незаметен пользователям.

Пользователю не нужно знать, какой шард хранит его аккаунт или смарт-контракт.

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

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

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

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

Межшардовые взаимодействия смарт-контрактов также могут требовать больше подтверждений или асинхронных обратных вызовов.

Хорошие пользовательские интерфейсы могут скрыть значительную часть этой сложности.

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

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

Шардинг состояния и разработчики

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

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

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

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

Если ликвидность распределена между шардами, DeFi-приложениям могут потребоваться специальная маршрутизация или агрегация.

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

Мониторинг может быть сложнее, поскольку активность приложения может происходить в нескольких шардах.

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

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

Лучшие платформы для разработчиков предлагают абстракции, делающие программирование с учетом шардов безопаснее и проще.

Шардинг состояния и DeFi

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

Своп может зависеть от пула ликвидности.

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

Стратегия доходности может зависеть от взаимодействия нескольких контрактов в одной транзакции.

Если эти контракты находятся в разных шардах, исполнение может стать асинхронным или более дорогим.

Это может снизить атомарную компонуемость.

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

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

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

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

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

Шардинг состояния и NFT

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

Шардинг может распределять это состояние между несколькими шардами.

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

Однако NFT также создают межшардовые сложности.

NFT в одном шарде может потребоваться продать покупателю из другого шарда.

Игровой предмет может взаимодействовать с контрактами или маркетплейсами в разных шардах.

Кошельку может потребоваться отображать балансы NFT из многих шардов.

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

Шардинг состояния может упростить масштабирование NFT, но также усложнить поиск, ликвидность и переводы.

Для плавного опыта работы с шардированными NFT необходима качественная инфраструктура кошельков и маркетплейсов.

Шардинг состояния и мосты

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

Сообщение должно перейти из одной среды состояния в другую.

Принимающая среда должна знать, что сообщение действительно.

Отправляющая среда должна предотвращать двойное использование или повторное воспроизведение.

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

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

Однако плохо спроектированные межшардовые системы все равно могут создавать риски, подобные рискам мостов.

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

Нативный межшардовый обмен сообщениями обычно сильнее интегрирован с правилами консенсуса цепи.

Мосты уровня приложений могут добавлять дополнительный риск смарт-контрактов, валидаторов, ретрансляторов или ликвидности.

Шардинг состояния и решардинг

Решардинг — это процесс изменения структуры шардов с течением времени.

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

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

Динамический решардинг пытается скорректировать границы или количество шардов в зависимости от спроса.

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

Перемещение состояния между шардами должно быть безопасным и согласованным.

Приложения должны продолжать работать при изменении назначений шардов.

Валидаторы и индексаторы должны правильно отслеживать новую структуру.

Кошельки и dApp не должны нарушать работу при решардинге.

Решардинг показывает, что шардинг состояния — это не только однократное разделение состояния, но и управление состоянием на протяжении жизненного цикла сети.

Преимущества шардинга состояния

Первое преимущество шардинга состояния — более высокая пропускная способность.

Несколько шардов могут параллельно обрабатывать транзакции вместо проведения всей активности через один конвейер исполнения.

Второе преимущество — лучшая масштабируемость хранения.

Узлам может не требоваться хранить каждую часть глобального состояния.

Третье преимущество — улучшенное горизонтальное масштабирование.

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

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

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

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

Именно эти преимущества делают шардинг состояния важной концепцией масштабирования.

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

Риски и ограничения шардинга состояния

Первый риск — межшардовая сложность.

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

Второй риск — фрагментация безопасности.

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

Третий риск — фрагментация ликвидности.

Активы и рынки могут разделяться между шардами, снижая эффективность цен и исполнения.

Четвертый риск — более слабая атомарная компонуемость.

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

Пятый риск — путаница для пользователей.

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

Шестой риск — сложность инфраструктуры.

Поставщики RPC, индексаторы, кошельки, обозреватели блокчейна и мосты должны правильно отслеживать множество шардов.

Седьмой риск — неравномерная нагрузка.

Некоторые шарды могут быть перегружены, тогда как другие имеют свободную емкость.

Шардинг состояния — мощное решение, но не бесплатный способ масштабирования.

Распространенные заблуждения о шардинге состояния

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

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

Другое заблуждение — считать шардинг состояния тем же самым, что роллапы.

Роллапы переносят исполнение в системы Layer 2, тогда как шардинг состояния разделяет состояние и исполнение самого базового уровня.

Третье заблуждение — считать текущую дорожную карту Ethereum традиционным шардингом состояния.

Текущая дорожная карта Ethereum сосредоточена на роллапах, блобах и доступности данных в стиле danksharding, а не на традиционных шард-цепочках исполнения и состояния.

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

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

Пятое заблуждение — считать шардированную цепь просто множеством отдельных цепей.

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

Как оценивать блокчейн с шардингом состояния

Начните с проверки, действительно ли цепь шардирует состояние или только данные либо транзакции.

Затем проверьте, как валидаторы назначаются в шарды.

Изучите, использует ли назначение валидаторов надежную случайность.

Проверьте, как обрабатываются межшардовые транзакции.

Изучите, является ли межшардовое исполнение синхронным или асинхронным.

Проверьте, могут ли приложения сохранять атомарную компонуемость между шардами.

Изучите, как протокол обеспечивает доступность данных для блоков шардов.

Проверьте, поддерживает ли сеть динамический решардинг или фиксированные шарды.

Оцените пользовательский опыт межшардовых переводов.

Изучите, надежно ли кошельки, обозреватели, поставщики RPC и индексаторы поддерживают все шарды.

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

Рекомендации для пользователей

Узнайте, использует ли сеть, которой вы пользуетесь, адреса для конкретных шардов, балансы газа или задержки переводов.

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

Начинайте с небольших тестовых переводов перед перемещением значительной стоимости между шардами.

Проверьте, работает ли приложение в одном шарде или во многих шардах.

Будьте осторожны при использовании мостов или маршрутизаторов, не являющихся нативными для шардированного протокола.

Учитывайте возможные дополнительные задержки при перемещении средств между шардами.

Не считайте транзакцию финальной во всех шардах, пока протокол или кошелек не подтвердит это.

Изучайте документацию приложения при использовании межшардовых DeFi или NFT-маркетов.

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

Рассматривайте шардинг состояния как инфраструктуру, способную повысить производительность, но не устраняющую риски смарт-контрактов или рынка.

Рекомендации для разработчиков

Проектируйте приложения с учетом местоположения шардов и межшардового поведения.

Избегайте ненужных межшардовых вызовов, когда возможен дизайн внутри одного шарда.

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

Защищайте межшардовые сообщения от повторного воспроизведения, ошибок порядка и сбоев логики обратных вызовов.

Отдельно тестируйте потоки транзакций внутри одного шарда и между шардами.

Отслеживайте фрагментацию ликвидности, если приложение зависит от рынков токенов.

Ясно объясняйте межшардовые задержки в пользовательских интерфейсах.

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

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

Рассматривайте межшардовое исполнение как чувствительную к безопасности часть дизайна приложения.

FAQ

Что означает шардинг состояния?

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

Что такое шард?

Шард — это один раздел состояния блокчейна и нагрузки исполнения.

Зачем блокчейны используют шардинг состояния?

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

Шардинг состояния — это то же самое, что шардинг данных?

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

Шардинг состояния — это то же самое, что роллапы?

Нет, роллапы исполняют транзакции вне базового уровня, тогда как шардинг состояния разделяет собственные состояние и исполнение базового уровня.

Использует ли Ethereum шардинг состояния сейчас?

Нет, текущая дорожная карта Ethereum сосредоточена на роллапах, блобах и доступности данных в стиле danksharding, а не на традиционном шардинге исполнения или состояния.

Какой блокчейн известен шардингом состояния?

NEAR широко известен своим дизайном шардинга Nightshade, который разделяет состояние и обработку между шардами.

Что такое межшардовые транзакции?

Межшардовые транзакции — это транзакции, затрагивающие состояние более чем одного шарда и требующие коммуникации между шардами.

Почему шардинг состояния сложен для DeFi?

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

Делает ли шардинг состояния блокчейн безрисковым?

Нет, шардинг состояния может повысить масштабируемость, но по-прежнему связан с такими рисками, как межшардовые ошибки, фрагментация безопасности, фрагментация ликвидности и сложность инфраструктуры.

Заключение

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

Его главная цель — повысить пропускную способность и снизить нагрузку на отдельных валидаторов или узлы.

Он отличается от шардинга данных, поскольку разделяет фактическое состояние исполнения, а не только улучшает доступность данных.

Он также отличается от роллапов, поскольку изменяет архитектуру базового уровня вместо переноса исполнения в отдельную среду Layer 2.

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

Дизайн Nightshade от NEAR — важный действующий пример превращения исследований шардинга в производственную инфраструктуру.

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

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

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

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

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

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