Отказ от ответственности
Эта статья была переведена с ее оригинального языка для вашего удобства. Несмотря на стремление к точности, могут быть небольшие ошибки или различия в толковании. Для наиболее точного и достоверного представления, пожалуйста, обратитесь к оригинальной публикации, доступной по ссылке. Мы ценим ваше понимание и рекомендуем обращаться к оригинальному источнику за подробной информацией.
Это перепост из блога Ника Додсона от 30 января 2024 года.
Представляем Нативное Восстановление Состояния, Техники Минимизации Состояния и Модель Транзакции для Минимизации Состояния.
Недавно я провел несколько выступлений о росте состояния, и, видя всё больше обсуждений на тему X, я подумал, что стоит расширить мои презентации и подход, который мы используем в Fuel.
Так что давайте сразу перейдем к делу. Одной из наиболее значительных проблем, с которыми сталкиваются блокчейны, является проблема "роста состояния" — проблема, которая, если ее не контролировать, может уничтожить масштабируемость и эффективность блокчейн-сетей. Давайте рассмотрим, что такое рост состояния, почему это проблема и предложенные решения, чтобы сохранить блокчейны стройными и функциональными по мере их масштабирования.
Понимание узких мест в обработке блокчейна
Прежде чем погружаться в сложности роста состояния, давайте разберем три основных компонента блокчейна, которые обычно являются узкими местами для масштабирования использования сети:
-
Исполнение. Работа, которую выполняет процессор для обеспечения правильной синхронизации, проверки и создания будущих блоков. ✅ Решение: Существует множество вариантов, которые решают эту проблему, такие как более эффективные виртуальные машины (FuelVM, Stylus, SVM, MoveVM) и параллельное выполнение транзакций (использование всех ядер вашего процессора), а также улучшенные предварительные компиляции (предустановленные функции в виртуальной машине).
-
Данные (как хранение, так и доступность). Фактические данные транзакций, которые обеспечивают переходы состояний и позволяют другим узлам синхронизироваться с сетью блокчейна, а также обеспечивают возможность доказательства мошенничества или подтверждения валидности для роллапов. ✅ Решение: Существует несколько вариантов, которые решают эту проблему, такие как EIP-4844, дизайны шардинга и внешние слои доступности данных, такие как Celestia, EigenDA и Avail.
-
Состояние. Это активная сохраненная информация в локальной базе данных, которая обеспечивает правильную проверку цепочки и переходы состояний. Обычно это находится в "горячем пути" обработки блокчейна, требует много случайного доступа к диску и вызывает много операций ввода-вывода, которые обычно являются самыми медленными областями обработки, помимо подписей и хеширования. ❌ Не решено.
Каждый из этих компонентов играет ключевую роль в работе блокчейна, но именно "состояние" нас особенно интересует, когда речь идет о проблемах роста.
Вызов роста состояния
Рост состояния относится к постоянному увеличению накопления данных, которые должны быть полностью сохранены и управляемы узлами в сети блокчейна. Поскольку состояние — это нечто, что растет со временем, его часто пренебрегают как "проблему будущего". Однако по мере того, как рост состояния нарастает и достигает своего предела, работа узла значительно затрудняется, и это становится узким местом для масштабируемости — что может оказаться фатальным, когда это затрудняет более широкое принятие и замедляет инновации.
Рост состояния приводит к раздутым блокчейнам, где медленные времена транзакций и более высокие затраты на хранение становятся нормой, что в свою очередь может ограничить масштабируемость и доступность сети. Звучит знакомо? Это потому, что борьба с ростом состояния станет следующим катализатором для ускорения экономики роллапов, подобно ее предшественнику — проблеме пропускной способности, которая спровоцировала революцию роллапов.
Приблизительные размеры состояния популярных цепочек EVM.
…но Роллапы не решают проблему роста состояния?
Роллапы позволяют Ethereum открыть дверь к "чему-то новому". Существующие решения решают проблему исполнительного слоя, при этом некоторые модульные решения идут дальше и решают проблему доступности данных. Но если эти новые решения не решают основной вопрос состояния, то вы возвращаетесь к борьбе в нулевой сумме. Любой блокчейн, созданный сегодня, с роллапом или без него, который не имеет стратегии по решению проблемы роста состояния, в конечном итоге будет ограничен разрастанием состояния, независимо от его среды исполнения или данных.
Сравнение дизайнов состояния
Чтобы проиллюстрировать проблему, давайте сравним управление состоянием в Bitcoin и Ethereum:
-
Bitcoin State: Использует набор UTXO (Unspent Transaction Output), который является более простым и традиционно был легче управляемым, но с ограниченной программированием.
-
Ethereum State: Включает в себя балансы счетов, код смарт-контрактов и состояние смарт-контрактов — включая балансы токенов, разрешения на токены и многое другое.
Модель управления состоянием в Bitcoin упрощена, но ограничена в своем объеме. Состояние Bitcoin управляется через отдельные выходы транзакций, которые могут быть либо потрачены, либо непотрачены. Его модель UTXO (Unspent Transaction Output) поддерживает четкое состояние через выходы транзакций, которые либо непотрачены и готовы для будущих транзакций, либо потрачены и, следовательно, архивированы в истории блокчейна. Это делает модель UTXO относительно более управляемой и обеспечивает, чтобы состояние не росло неконтролируемо с каждой транзакцией. Однако эта простота приносит компромисс в виде ограниченной программности Bitcoin по сравнению с системой Ethereum, обладающей полным набором инструкций.
По сравнению с этим Ethereum предлагает модель состояния, богатую экосистему балансов счетов, кодов смарт-контрактов и многообразие состояний контрактов — каждое взаимодействие — это нить в постоянно растущем полотне данных. Это постоянное развитие состояния, хотя и является демонстрацией гибкости Ethereum, представляет собой значительные проблемы масштабируемости. Поскольку состояние набухает с каждым выполнением смарт-контракта и транзакцией, это приводит к раздутой сети с увеличенными требованиями к хранению и медленными временами обработки, что, в свою очередь, сдерживает инновации и принятие пользователей.
Контраст между подходами Bitcoin и Ethereum к управлению состоянием подчеркивает фундаментальный компромисс в проектировании блокчейна: простоту и эффективность управления состоянием против сложности и потенциала операций на цепочке.
Предложенные решения для роста состояния
Было предложено несколько стратегий для управления ростом состояния:
Разрешение роста состояния
Принятие роста состояния в обмен на более высокое использование пропускной способности. Это не очень хороший вариант, так как это увеличивает требования к полным узлам, что ограничивает децентрализацию сети.
Аренда состояния
Взимание платы за хранение данных состояния с возможным компромиссом, таким как 'распад дерева' (если все элементы состояния в Ethereum находятся в одном дереве и вы забываете некоторые из листьев, вы портите некоторые из ветвящихся путей), среди других проблем.
Безсостоятельность
Полные узлы не должны будут хранить состояние, полагаясь на доказательства состояния, включенные в транзакции и блоки. По сути, перенос состояния с цепочки уровня 1 на роллапы. Это направление, в котором движется Ethereum, но есть много неотвеченных вопросов о том, насколько это будет эффективно и поддерживаемо.
https://vitalik.eth.limo/general/2021/06/18/verkle.html
Разметка состояния без использования Меркловского дерева
Технический подход к управлению данными состояния по-другому. Фактически, вы бы использовали полные узлы для проверки всего или выборочно с легкими клиентами и вообще забыли бы о дереве состояния.
Сжатие состояния на уровне приложения
Использование методов обработки вызовов для сжатия данных состояния. По сути, вы обмениваете состояние на пропускную способность. Увеличение требований к пропускной способности приводит к ограничениям в сети, что имеет серьезные последствия для надежности инфраструктуры и компромиссов в эффективности.
Пример 1: Стейкер Uniswap V3 (изображение слева). Состояние должно быть восстановлено по пропускной способности. Это позволяет создать очень сжатый дизайн состояния, и данные вызовов значительно дешевле, чем хранение на Ethereum. Пример 2: Сжатые NFT (изображение справа). Преобразуйте владение NFT в мерклизованные данные и сохраните корень в состоянии.
И теперь... Нативная регидратация состояния.
Философия состояния Fuel
Используя модель UTXO, вы получаете несколько «бонусов»:
-
Локализованные деревья состояния: Нет глобального дерева состояния, только локальные деревья состояния для каждого смарт-контракта.
-
Встроенные активы: Все передачи активов касаются только одного элемента состояния. Встроенные активы могут использоваться для представления нефинансового состояния (например, NFT для представления владения). Они не требуют мерклизации, что упрощает состояние.
-
Отсутствие состояния одобрения: Исключение избыточных изменений состояния из функций approve и transferFrom.
Модель UTXO позволяет всему этому при сохранении богатых криптографических легких клиентов и возможности верификации — создание "быстрого режима" для истинной интероперабельности (об этом будет подробнее в будущем сообщении). Основная философия подхода Fuel заключается в использовании большего объема пропускной способности и исполнения при использовании меньшего объема состояния. Но как?
Нативная регидратация состояния
Нативная регидратация состояния описывает методы, которые могут использовать разработчики Fuel для дегидратации или компартментализации состояния. Вещи регидратируются через пропускную способность, что позволяет повторно получать доступ к состоянию при необходимости. Это противоположно традиционному подходу Ethereum ("использование смарт-контрактов для всего"), который использует поиск состояния контракта.
Новый подход:
-
Хранение только корневых хэшей / изменений состояния.
-
Предоставление данных через пропускную способность для "регидратации" состояния.
-
Предоставление разработчикам техник минимизации состояния для использования.
Техники минимизации состояния
Фокус на пропускной способности и исполнении перед хранением состояния. Fuel предоставляет разработчику множество способов выполнения действий помимо простого хранения смарт-контрактов:
-
Сценарии: Временная логика включается в транзакции, а не хранится в состоянии. В отличие от транзакций EVM, которые могут вызывать контракт напрямую (но только один), транзакции Fuel выполняют сценарий, который может вызывать от нуля до нескольких контрактов.
-
Предикаты: Легкие, бессостоятельные контракты. Предикат представляет собой новый, чистый механизм авторизации транзакций. Предикат может обращаться только к данным в транзакции, но не может просматривать текущее состояние цепи. Предикаты могут использоваться, среди прочего, для включения нативной (бессостоятельной) абстракции учетных записей.
Узнайте больше о Предикатах в этом посте от Райана Спрула: Предикат не является смарт-контрактом, но всё же позволяет использовать пользовательскую логику аутентификации для расходования монет. Это означает, что предикаты могут быть расходованы без необходимости закрытого ключа, в отличие от любой транзакции EVM. На практике это означает, что пользователи могут создавать предикаты, которые могут быть полностью использованы без разрешения. В сочетании с концепцией скриптов Fuel это значительно улучшает пользовательский опыт взаимодействия со смарт-контрактами.
Модель транзакции с минимизацией состояния
Сочетание техник минимизации состояния с моделью UTXO позволяет создать новую Гибкую Модель Транзакции. Это открывает больше возможностей для формирования многосторонних сложных транзакций, которые не требуют смарт-контрактов для доступа к состоянию.
В практике это будет выглядеть следующим образом:
Пример: Смарт-контрактные кошельки (с единственным состоянием размером 32 байта)
-
Состояние контракта хранится в единственном корневом хэше в UTXO.
-
Состояние регидрируется по требованию через пропускную способность.
-
UTXO обеспечивают верифицируемость легких клиентов без глобального дерева Меркла.
-
Требуется только одно чтение ввода-вывода.
-
Состояние может быть изменено, когда UTXO состояния расходуется.
-
Нет потери функциональности кошельков смарт-контрактов по сравнению с Ethereum.
-
Пропускная способность и исполнение имеют приоритет перед состоянием.
-
Все это выполняется на нативном уровне (предикаты).
Архитектура Fuel разработана таким образом, чтобы включать все эти особенности вместе с минимизацией состояния для создания специально разработанного пакета для Ethereum rollups. Fuel вносит новые возможности в экосистему Ethereum, сохраняя безопасность путем окончательной установки на Ethereum.
Пока продолжается борьба с ростом состояния, инструменты и стратегии, такие как те, которые предлагает Fuel, предоставляют надежду на масштабируемое и эффективное будущее. Как гласит поговорка: "Необходимость - мать изобретательности", и в мире блокчейна необходимость победить рост состояния действительно привела к некоторым значимым решениям.
评论 (0)