Дисклеймер: Эта публикация является переводом, выполненным участником сообщества Fuel. Была проведена вычитка, но возможны некоторые ошибки. Fuel Labs не несет ответственности за точность, актуальность или последовательность переведенной информации.
Оригинальная публикация: Mastering the Final Boss in Blockchain Scalability: State Growth
Это репост из блога Ника Додсона от 30 января 2024 года.
Представляем вам Native State Rehydration, техники минимизации состояний и модель транзакций с минимизацией состояний.
В последнее время я несколько раз выступал с докладами о росте состояний, и, видя, что на X все больше обсуждений на эту тему, я решил расширить свои выступления и подход, который мы используем в Fuel.
Так что давайте сразу перейдем к делу. Одним из самых серьезных препятствий, с которыми сталкиваются блокчейны, является проблема "роста состояния" - проблема, которая, если ее не решать, может разрушить масштабируемость и эффективность блокчейн-сетей. Давайте разберемся, что такое "рост состояния", почему это проблема, и какие решения предлагаются для того, чтобы блокчейн оставался экономичным и функциональным при масштабировании.
Прежде чем погрузиться в сложности роста состояния, давайте разберем три основных компонента блокчейна, которые обычно являются узкими местами при масштабировании использования сети:
Исполнение. Работа, которую выполняет центральный процессор для обеспечения правильной синхронизации, проверки и создания будущих блоков. ✅ Решено: Существует множество вариантов решения этой проблемы, например, более эффективные виртуальные машины (FuelVM, Stylus, SVM, MoveVM) и параллельное выполнение транзакций (использование всех ядер вашего процессора), а также лучшие прекомпиляции (предустановленные функции в виртуальной машине).
Данные (как хранение, так и доступность). Фактические данные транзакций, которые управляют переходами состояний и позволяют другим узлам синхронизироваться с сетью блокчейна, а также позволяют подтвердить мошенничество или достоверность ролловеров. ✅ Решение: Есть несколько вариантов решения этой проблемы, например EIP-4844, шардинги и внешние уровни доступности данных, такие как Celestia, EigenDA и Avail.
Состояние. Это активная информация, хранящаяся в локальной базе данных, которая обеспечивает правильную проверку цепочек и переходы состояний. Как правило, она находится на "горячем пути" обработки блокчейна, требует много случайного доступа к диску и выполняет много операций ввода-вывода, что обычно является самой медленной областью обработки, не считая подписей и хеширования. ❌ Не решено.
Каждый из этих компонентов играет важную роль в работе блокчейна, но именно "состояние" особенно интересует нас при обсуждении вопросов роста.
Под ростом состояния понимается постоянно увеличивающееся накопление данных, которые должны полностью храниться и управляться узлами в сети блокчейн. Поскольку состояние - это то, что растет со временем, его часто рассматривают как "проблему будущего". Однако по мере того, как рост состояния достигает своего порога, работа узлов резко усложняется, и это становится узким местом для масштабируемости, что оказывается фатальным, когда препятствует более широкому внедрению и замедляет инновации.
https://x.com/peter_szilagyi/status/1706563595264295411?s=20
Рост штата приводит к раздуванию блокчейна, когда медленное время транзакций и более высокие затраты на хранение становятся нормой, что, в свою очередь, может ограничить масштабируемость и доступность сети. Звучит знакомо? Это потому, что решение проблемы роста штатов станет следующим катализатором, который приведет к росту экономики блокчейна, как и ее предшественница, проблема пропускной способности, которая спровоцировала революцию в блокчейне.
Аппроксимации размеров состояний для популярных цепочек EVM.
Роллапы позволяют Ethereum открыть дверь к "чему-то новому". Существующие решения касаются уровня исполнения, а некоторые модульные решения идут дальше и решают проблему доступности данных. Но если эти новые решения не решают основную проблему состояния, то вы снова оказываетесь в игре с нулевой суммой. Любой блокчейн, разработанный сегодня, рулонный или нет, не имеющий стратегии борьбы с ростом состояния, в конечном итоге будет ограничен раздуванием состояния, независимо от среды исполнения или данных.
Чтобы проиллюстрировать проблему, давайте сравним управление состоянием в Bitcoin и Ethereum:
Состояние биткойна: Использует набор UTXO (Unspent Transaction Output), который проще и традиционно легче в управлении, но имеет ограниченные возможности программирования.
Состояние Ethereum: Включает остатки на счетах, код смарт-контракта и состояние смарт-контракта, включающее остатки токенов, одобрения и многое другое.
Модель управления состоянием биткоина оптимизирована, но ограничена. Управление состоянием биткойна осуществляется через отдельные транзакции, которые могут быть либо потрачены, либо не потрачены. Модель UTXO (Unspent Transaction Output) поддерживает четкое состояние через выходы транзакций, которые либо не потрачены и готовы для будущих транзакций, либо потрачены и таким образом занесены в историю блокчейна. Это делает модель UTXO относительно более управляемой и гарантирует, что состояние не будет бесконтрольно расти с каждой транзакцией. Однако за эту простоту приходится расплачиваться ограниченной программируемостью Биткойна по сравнению с Тьюринг-полной системой Ethereum.
Напротив, модель состояний Ethereum представляет собой богатую экосистему балансов счетов, кодов смарт-контрактов и множества состояний контрактов - каждое взаимодействие является нитью в постоянно растущем гобелене данных. Эта постоянная эволюция состояний, хотя и является свидетельством универсальности Ethereum, создает значительные проблемы с масштабируемостью. Поскольку состояние раздувается с каждым выполнением смарт-контракта и транзакцией, это приводит к раздуванию сети с повышенными требованиями к хранению данных и замедлению времени обработки, что, в свою очередь, сдерживает инновации и внедрение пользователей.
Контраст между подходами Bitcoin и Ethereum к управлению состоянием подчеркивает фундаментальный компромисс в разработке блокчейна: простота и эффективность управления состоянием против сложности и потенциала операций на цепочке.
Для управления ростом штата было предложено несколько стратегий:
Позволить штату расти
Принятие роста состояния в обмен на увеличение пропускной способности. Это не лучший вариант, поскольку он предъявляет повышенные требования к полным узлам, что сдерживает децентрализацию сети.
https://x.com/aeyakovenko/status/1699460999697555512?s=20
Аренда состояния
Взимание платы за хранение данных о состоянии, что влечет за собой потенциальные проблемы, такие как "гниение дерева" (если все элементы состояния в Ethereum находятся в одном дереве и вы забываете некоторые листья, вы повреждаете некоторые пути ветвления), а также другие проблемы.
Безгражданство
Полноценным узлам не нужно хранить состояние, они полагаются на доказательства состояния, включенные в транзакции и блоки. По сути, состояние переходит от цепочки первого уровня к роллапам. Именно в этом направлении движется Ethereum, но есть много вопросов, на которые нет ответов, насколько это будет эффективно и поддерживаемо.
https://vitalik.eth.limo/general/2021/06/18/verkle.html
Технический подход к управлению данными состояния. Эффективно было бы использовать полные узлы для проверки всего или пробные версии с легкими клиентами и полностью забыть о дереве состояний.
https://x.com/TrustlessState/status/1699457615615402147?s=20
Использование техники call-data для сжатия данных о состоянии. По сути, вы обмениваете состояние на пропускную способность. Более высокие требования к пропускной способности приводят к ограничению сетей, при этом последствия взвешиваются в пользу устойчивости инфраструктуры и эффективности.
Пример 1: стакер Uniswap V3 (изображение слева). Состояние должно быть регидратировано по полосе пропускания. Это позволяет минимизировать состояние, а calldata намного дешевле, чем хранение на Ethereum. Пример 2: Сжатые NFT (правое изображение). Мерклиз данных о владении NFT и хранение корня в состоянии.
А теперь... "Родное государство".
Используя модель UTXO, вы получаете несколько "бесплатных" преимуществ:
Локализованные деревья состояний: Нет глобального дерева состояний, только локальные деревья состояний для каждого смарт-контракта.
Родные активы: Все передачи активов касаются только одного элемента состояния. Нативные активы могут использоваться для представления нестоимостного состояния (например, NFT для представления права собственности). Их не нужно меркализировать, что упрощает состояние.
Нет состояния утверждения: Устранение ненужных изменений состояния от функций approve и transferFrom.
Модель UTXO позволяет сделать все это, сохраняя богатые криптографические легкие клиенты и верифицируемость - создавая "быстрый режим" для настоящей совместимости (подробнее об этом в следующем посте). Основная философия подхода Fuel заключается в том, чтобы использовать больше пропускной способности и выполнения, используя при этом меньше состояния. Но как?
Регидратация нативного состояния описывает методы, которые разработчики Fuel могут использовать для дегидратации или компартментализации состояния. Вещи регидратируются по полосе пропускания, что позволяет повторно получить доступ к состоянию, когда это необходимо. Это противоположно традиционному подходу Ethereum ("использовать смарт-контракты для всего"), использующему поиск состояния контракта.
Новый подход:
Храните только корневые хэши / изменения состояния
Представлять данные по полосе пропускания для "регидратации" состояния
Предоставьте разработчику технику минимизации состояния, чтобы он мог использовать ее.
Фокус на пропускной способности и исполнении, а не на хранении состояния. Fuel дает разработчику множество возможностей, помимо хранения смарт-контрактов:
Скрипты: Эфемерная логика включается в транзакции, а не хранится в состоянии. В отличие от транзакций EVM, которые могут вызывать контракт напрямую (но могут вызывать только один контракт), транзакции Fuel выполняют сценарий, который может вызывать ноль или более контрактов.
Предикаты: Облегченные контракты без состояния. Предикат - это новый, чистый механизм авторизации транзакций. Предикат может получить доступ только к данным в транзакции, он не может просматривать текущее состояние цепочки. Предикаты могут использоваться, в частности, для обеспечения нативной (без статических данных) абстракции счетов.
Узнайте больше о предикатах из этого поста Райана Спроула: предикат не является смарт-контрактом, но при этом позволяет использовать пользовательскую логику аутентификации для траты монет. Это означает, что предикаты могут быть потрачены без необходимости в приватном ключе, в отличие от любой транзакции EVM. На практике это означает, что пользователи могут создавать предикаты, которые можно тратить без каких-либо разрешений. В сочетании с Fuel концепцией скриптов пользовательский опыт взаимодействия со смарт-контрактами становится более совершенным.
Сочетание методов минимизации состояния с моделью UTXO позволяет нам создать новую гибкую модель транзакций. Это дает больше возможностей для формирования многосторонних сложных транзакций, которые не требуют смарт-контрактов для доступа к состоянию.
Кошельки смарт-контрактов (с одним элементом состояния размером 32 байта)
Состояние контракта хранится в едином корневом хэше в UTXO
Состояние восстанавливается по пропускной способности, когда это необходимо
UTXO обеспечивают легкую верифицируемость клиента без глобального дерева Меркла
Требуется только одно чтение IO
Состояние может быть изменено при расходовании UTXO состояния
Без потери функциональности кошелька смарт-контракта VS Ethereum
Пропускная способность и исполнение приоритетнее состояния
Все делается на собственном уровне (предикаты)
Архитектура Fuel разработана таким образом, чтобы включить в себя все эти функции, а также минимизировать выполнение состояний, чтобы создать пакет, специально предназначенный для роллапов Ethereum. Fuel привносит новые возможности в экосистему Ethereum, сохраняя при этом безопасность за счет окончательного расчета на Ethereum.
Пока борьба с ростом штатов продолжается, инструменты и стратегии, такие как Fuel, дают надежду на масштабируемое и эффективное будущее. Как гласит пословица, "Необходимость - мать изобретения", и в мире блокчейна необходимость победить рост государства действительно привела к появлению некоторых решений "ноль в один".