Дерево состояния

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

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

В блокчейнах, построенных по модели Ethereum, дерево состояния сопоставляет адреса аккаунтов с данными аккаунтов, такими как балансы, nonce, корни хранилища смарт-контрактов и хеши кода.

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

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

Дерево состояния не совпадает со списком исторических транзакций.

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

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

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

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

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

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

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

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

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

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

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

Дерево состояния предоставляет клиентам детерминированную структуру для хранения и проверки этих значений.

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

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

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

Дерево состояния и корень состояния

Корень состояния — это корневой хеш дерева состояния после обработки всех транзакций блока.

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

Документация Ethereum по Merkle Patricia Trie поясняет, что заголовки блоков уровня исполнения Ethereum содержат корни дерева состояния, дерева транзакций и дерева квитанций.

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

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

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

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

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

Таким образом, корень состояния является отпечатком полного состояния блокчейна в конкретном блоке.

Он помогает представить огромную базу данных состояния в виде единого проверяемого значения.

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

Дерево состояния Ethereum использует модифицированное Merkle Patricia Trie.

Merkle Patricia Trie объединяет идеи деревьев Меркла, radix trie и Patricia trie.

Trie — это древовидная структура «ключ—значение», в которой путь по дереву определяется ключом.

Patricia trie сжимает пути, чтобы дерево не расходовало место на длинные цепочки пустых нод.

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

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

В дереве состояния Ethereum путь основан на хеше Keccak-256 адреса аккаунта.

По этому пути хранится объект аккаунта, закодированный с помощью RLP.

Согласно официальной документации Ethereum, объект аккаунта Ethereum представляет собой массив из четырех элементов: nonce, balance, storageRoot и codeHash.

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

Какие данные хранятся в дереве состояния?

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

Каждый объект аккаунта Ethereum содержит nonce.

Каждый объект аккаунта Ethereum содержит balance.

Каждый объект аккаунта Ethereum содержит storageRoot.

Каждый объект аккаунта Ethereum содержит codeHash.

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

Balance фиксирует объем нативной валюты, принадлежащей аккаунту.

StorageRoot указывает на другое дерево, в котором хранится хранилище смарт-контракта данного аккаунта.

CodeHash фиксирует байткод смарт-контракта, связанный с аккаунтом контракта.

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

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

Дерево состояния и дерево хранилища

Дерево состояния и дерево хранилища связаны, но различаются.

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

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

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

Объект аккаунта в дереве состояния хранит storageRoot — корень дерева хранилища этого аккаунта.

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

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

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

Глобальное дерево состояния хранит объект аккаунта токен-контракта, а этот объект указывает на корень хранилища токен-контракта.

Такая многоуровневая структура помогает отделить состояние на уровне аккаунта от хранилища на уровне контракта.

Дерево состояния и дерево транзакций

Дерево состояния отличается от дерева транзакций.

Дерево состояния хранит итоговое состояние аккаунтов после исполнения транзакций.

Дерево транзакций хранит транзакции, включенные в конкретный блок.

Каждый блок имеет собственное дерево транзакций.

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

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

Транзакцию можно рассматривать как инструкцию.

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

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

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

Дерево состояния и дерево квитанций

Дерево состояния также отличается от дерева квитанций.

Дерево квитанций хранит квитанции транзакций для блока.

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

Дерево состояния фиксирует итоговое состояние аккаунтов после исполнения.

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

Дерево состояния помогает клиентам проверить, каким стало состояние блокчейна после исполнения.

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

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

Обе структуры важны, но отвечают на разные вопросы.

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

Ноды Merkle Patricia Trie

Модифицированное Merkle Patricia Trie Ethereum использует несколько типов нод.

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

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

Листовая нода хранит конечный закодированный путь и значение.

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

Эта структура полезна, поскольку ключи Ethereum длинные и разреженные.

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

Используя ноды расширения и листовые ноды, Ethereum делает trie более компактным по сравнению с базовым radix trie.

Используя хеши, Ethereum делает trie криптографически проверяемым.

Именно поэтому эта структура называется модифицированным Merkle Patricia Trie.

Кодирование RLP и хеширование

Ethereum использует кодирование Recursive Length Prefix, часто называемое RLP, для сериализации многих структур данных на уровне исполнения.

В дереве состояния объекты аккаунтов кодируются RLP перед размещением в качестве значений.

Ноды trie также кодируются перед хешированием или хранением.

Документация Ethereum по Merkle Patricia Trie объясняет, что, когда одна нода ссылается на другую, ссылка может быть хешем Keccak-256 RLP-кодированной ноды в зависимости от длины кодирования.

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

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

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

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

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

Это криптографическая основа доказательств состояния.

Доказательства состояния

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

В предложении EIP-1186 eth_getProof объясняется, что основанное на дереве Меркла состояние Ethereum позволяет проверять значения аккаунтов и хранилища с помощью доказательств Меркла.

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

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

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

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

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

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

Дерево состояния делает такие доказательства возможными.

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

eth_getProof

eth_getProof — это метод Ethereum JSON-RPC, предназначенный для возврата значений аккаунтов и хранилища вместе с их доказательствами Меркла.

EIP-1186 определяет eth_getProof как метод, возвращающий значения аккаунта и хранилища указанного аккаунта вместе с данными доказательства.

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

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

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

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

Простой запрос баланса лишь сообщает значение.

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

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

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

Дерево состояния и полные ноды

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

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

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

Полные ноды обычно не хранят все исторические состояния вечно.

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

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

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

Текущее состояние необходимо для работы сети.

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

Таким образом, дерево состояния влияет на аппаратные требования нод, синхронизацию, хранилище и децентрализацию.

Дерево состояния и архивные ноды

Архивная нода хранит исторические состояния, а не только текущее и недавние состояния.

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

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

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

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

Архивная нода часто может получить доступ к историческому состоянию непосредственно с диска.

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

Поэтому история дерева состояния ценна, но требует больших затрат.

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

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

Дерево состояния и смарт-контракты

Смарт-контракты в значительной степени зависят от дерева состояния и деревьев хранилища.

Объект аккаунта контракта находится в глобальном дереве состояния.

Код контракта фиксируется через codeHash.

Постоянное хранилище контракта фиксируется через storageRoot.

При исполнении смарт-контракт может читать и записывать ячейки хранилища.

Такие изменения хранилища обновляют дерево хранилища контракта.

Новый storageRoot контракта обновляет объект аккаунта в глобальном дереве состояния.

Обновленный объект аккаунта изменяет глобальный корень состояния.

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

Таким образом, дерево состояния участвует в том, как результаты работы смарт-контрактов становятся видимыми для консенсуса.

Дерево состояния и балансы токенов

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

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

Это сопоставление находится в дереве хранилища токен-контракта.

Глобальное дерево состояния хранит объект аккаунта токен-контракта, включая storageRoot этого контракта.

Это означает, что нативный баланс монеты и баланс токена хранятся по-разному.

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

Баланс токена обычно представляет собой значение хранилища в дереве хранилища конкретного токен-контракта.

Это различие важно для доказательств и аудитов.

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

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

Дерево состояния и легкие клиенты

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

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

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

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

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

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

Дерево состояния предоставляет аутентифицированную структуру, необходимую для таких сценариев.

Однако размер доказательств и затраты на их создание все еще могут быть значительными.

Это одна из причин, по которой исследователи Ethereum изучали альтернативы, такие как деревья Verkle.

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

Дерево состояния и stateless-клиенты

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

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

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

Большие свидетели могут делать stateless-верификацию неэффективной.

В статье Ethereum Foundation о структуре дерева Verkle объясняется, что деревья Verkle работают подобно деревьям Меркла, но могут создавать значительно меньшие свидетели благодаря векторным обязательствам.

Именно поэтому деревья Verkle исследуются в качестве возможной замены текущей структуры фиксации состояния Ethereum.

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

Исследования stateless-подхода частично направлены на снижение нагрузки, которую дерево состояния создает для нод.

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

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

Дерево состояния и деревья Verkle

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

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

Деревья Verkle предназначены для создания доказательств меньшего размера по сравнению с доказательствами Merkle Patricia Trie.

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

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

Модель состояния на основе Verkle могла бы сделать stateless-клиентов более практичными.

Однако миграция от давно работающего дерева состояния к новой структуре фиксации сложна.

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

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

Понимание дерева состояния помогает понять, почему исследования Verkle имеют значение.

Дерево состояния и разрастание состояния

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

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

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

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

Это может ослабить децентрализацию.

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

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

Текущее состояние должно быть доступно для валидации.

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

Дерево состояния — это структура данных, в которой этот рост становится заметен клиентам.

Дерево состояния и стоимость газа

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

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

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

Когда смарт-контракт создает новое хранилище, могут потребоваться обновления дерева хранилища и глобального корня состояния.

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

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

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

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

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

Дерево состояния находится в центре этого экономического компромисса.

Дерево состояния и RPC-провайдеры

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

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

Официальная документация Ethereum JSON-RPC описывает методы состояния как методы, сообщающие текущие хранимые данные, такие как балансы аккаунтов, данные контрактов и оценки газа.

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

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

Пользователи часто полагаются на RPC-провайдеров, не задумываясь о дереве состояния, стоящем за ответом.

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

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

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

Это важно для мостов, аудитов, инструментов комплаенса и кроссчейн-систем.

Дерево состояния и обозреватели блокчейна

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

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

Индексация ускоряет поиск и упрощает создание пользовательских интерфейсов.

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

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

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

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

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

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

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

Дерево состояния и мосты

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

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

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

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

Именно поэтому EIP-1186 отмечает важность доказательств Меркла для технологий Layer 2.

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

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

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

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

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

Дерево состояния и сети Layer 2

Сети Layer 2 часто используют корни состояния, доказательства и структуры фиксации для обобщения офчейн-исполнения или исполнения в отдельной цепочке.

Layer 2 может публиковать корни состояния в цепочке Layer 1.

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

Точная структура зависит от архитектуры Layer 2.

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

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

Большое состояние исполнения представляется обязательством.

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

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

Они также являются частью масштабирования, проектирования роллапов и кроссчейн-верификации.

Дерево состояния и безопасность

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

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

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

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

Это делает дерево состояния критически важным для консенсуса.

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

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

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

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

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

Дерево состояния и реализации клиентов

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

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

Способ хранения нод trie на диске у клиентов может различаться.

Способ кэширования состояния у клиентов может различаться.

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

Способ обработки исторических запросов у клиентов может различаться.

Это означает, что дерево состояния — одновременно концепция протокола и задача реализации.

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

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

Пользователи обычно замечают эти различия по производительности нод, использованию диска, времени синхронизации и надежности RPC.

Дерево состояния и отладка для разработчиков

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

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

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

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

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

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

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

Оно также помогает не путать историю транзакций с текущим состоянием.

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

Дерево состояния поясняет, где находится каждый элемент данных.

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

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

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

Когда криптокошелек показывает баланс, он считывает состояние.

Когда dApp проверяет, одобрил ли пользователь токен, он считывает состояние хранилища контракта.

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

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

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

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

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

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

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

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

Дерево состояния хранит текущее состояние аккаунтов, а транзакции хранятся отдельно в блоках и деревьях транзакций.

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

Глобальное дерево состояния хранит объекты аккаунтов, а хранилище контрактов находится в отдельных деревьях хранилища, на которые указывают значения storageRoot.

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

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

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

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

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

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

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

Первое преимущество дерева состояния — проверяемость.

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

Второе преимущество — детерминизм.

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

Третье преимущество — эффективный поиск.

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

Четвертое преимущество — выявление подмены.

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

Пятое преимущество — поддержка легких клиентов.

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

Шестое преимущество — четкая структура переходов состояния.

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

Эти преимущества делают дерево состояния основой блокчейнов смарт-контрактов на базе аккаунтов.

Ограничения дерева состояния

Первое ограничение — рост объема хранилища.

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

Второе ограничение — размер доказательств.

Доказательства Merkle Patricia Trie могут быть больше желаемого для stateless-клиентов и высокомасштабной верификации.

Третье ограничение — сложность реализации.

Кодирование trie, хеширование, удаление данных, кэширование и хранение в базе данных сложно реализовать корректно.

Четвертое ограничение — стоимость хранения исторического состояния.

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

Пятое ограничение — путаница среди разработчиков.

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

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

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

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

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

Используйте официальную документацию Ethereum при изучении механики Merkle Patricia Trie.

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

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

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

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

Проектируйте смарт-контракты так, чтобы свести к минимуму ненужное постоянное хранилище.

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

Отслеживайте исследования протокола, такие как деревья Verkle, если ваша система сильно зависит от доказательств состояния.

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

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

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

Проверяйте номера блоков при сравнении балансов или значений контрактов в разных инструментах.

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

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

Не считайте простой ответ RPC эквивалентом криптографического доказательства.

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

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

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

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

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

FAQ

Что означает state trie?

Дерево состояния — это криптографическое дерево «ключ—значение», которое хранит текущее состояние блокчейна и формирует корневой хеш, фиксирующий это состояние.

Что такое дерево состояния Ethereum?

Дерево состояния Ethereum — это глобальное модифицированное Merkle Patricia Trie, сопоставляющее хешированные адреса аккаунтов с объектами аккаунтов, закодированными с помощью RLP.

Что хранится в объекте аккаунта Ethereum?

Объект аккаунта Ethereum содержит nonce, balance, storageRoot и codeHash.

Что такое корень состояния?

Корень состояния — это корневой хеш дерева состояния после исполнения транзакций блока.

Совпадает ли дерево состояния с деревом хранилища?

Нет. Дерево состояния хранит объекты аккаунтов, тогда как деревья хранилища содержат хранилище контрактов отдельных аккаунтов контрактов.

Совпадает ли дерево состояния с историей транзакций?

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

Что такое доказательство Меркла?

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

Что такое eth_getProof?

eth_getProof — это метод Ethereum JSON-RPC, возвращающий значения аккаунтов и хранилища вместе с данными доказательства Меркла.

Почему архивные ноды важны для дерева состояния?

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

Будет ли Ethereum всегда использовать текущее дерево состояния?

В настоящее время Ethereum использует Merkle Patricia Trie на уровне исполнения, однако исследования Ethereum изучают деревья Verkle как будущую структуру фиксации состояния.

Заключение

Дерево состояния — одна из ключевых структур данных блокчейнов смарт-контрактов на базе аккаунтов.

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

В Ethereum глобальное дерево состояния сопоставляет хешированные адреса аккаунтов с объектами аккаунтов, содержащими nonce, balance, storageRoot и codeHash.

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

Корень состояния в заголовке каждого блока фиксирует полное итоговое состояние после обработки всех транзакций этого блока.

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

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

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

Для пользователей дерево состояния в основном скрыто за криптокошельками, обозревателями и dApp.

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

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

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