Verkle tree — это криптографическая структура данных для коммитмента состояния, которая сочетает идею префиксного дерева (trie) с векторными коммитментами. В экосистеме Ethereum Verkle-дерево рассматривается как замена текущей структуры состояния Merkle Patricia Trie (MPT), чтобы:
- сильно уменьшить размер свидетельств состояния (witness);
- сделать практичной валидацию блоков без локального хранения полного state (режим stateless-клиентов);
- снизить требования к оборудованию узлов и повысить децентрализацию сети;
- упростить интеграцию с доказательствами для zk-EVM и rollups.
В Ethereum Verkle строится на базе KZG-коммитментов и векторных коммитментов (vector commitments), что позволяет делать компактные пруфы состояния, почти не зависящие от ширины узла.
Зачем Ethereum переходит на Verkle-дерево
Текущая структура состояния Ethereum — Merkle Patricia Trie — надёжна, но создаёт проблемы:
- Большой размер пруфов.
Для доказательства включения ключа в MPT нужны хеши на каждом уровне дерева. При глубоком дереве и большом состоянии witness получается тяжёлым.
- Сложность stateless-валидации.
Полноценный stateless-клиент должен получать вместе с блоком весь пруф по каждому чтению/записи в состояние. С MPT суммарный объём данных часто выходит за рамки комфортного p2p-распространения.
- Рост требований к узлам.
Чем больше state, тем дороже хранить полную БД и обслуживать запросы, что повышает барьер входа для валидаторов и узлов.
Verkle-дерево решает эту связку проблем:
- Пруфы становятся на порядок компактнее.
- Блок + witness остаются достаточно лёгкими, чтобы их могли обрабатывать stateless-клиенты.
- Появляется возможность повышать лимит газа и развивать сеть, не резко повышая требования к железу.
Интуиция: чем Verkle отличается от Merkle/MPT
В классическом Merkle-дереве или MPT:
- каждый узел хранит хеши детей;
- доказательство включения ключа — это «ветка» всех соседних хешей по пути от листа к корню;
- размер пруфа растёт с глубиной дерева: чем глубже состояние, тем больше хешей.
В Verkle:
- каждый внутренний узел содержит векторный коммитмент к массиву детей (например, 256 значений по индексам 0..255);
- вместо перечисления всех соседних хешей даётся короткий пруф для конкретного индекса в этом массиве;
- размер пруфа почти не зависит от числа детей, поэтому можно делать широкие узлы (ветвление 256 и больше), уменьшая глубину дерева.
Идея:
Векторный коммитмент позволяет «зафиксировать» целый массив значений одним компактным отпечатком и затем доказывать корректность каждого элемента по индексу без большого объёма дополнительных данных.
В Ethereum векторные коммитменты реализуются через KZG-полиномиальные коммитменты.
Базовые понятия
- Коммитмент — криптографический «отпечаток» набора данных: публикуется короткое значение (commitment), которое однозначно связанно с массивом, и позже можно доказать, что определённый элемент входил в этот массив.
- Векторный коммитмент (vector commitment) — коммитмент к упорядоченному списку значений с возможностью:
- доказать корректность элемента по индексу;
- не раскрывать весь список.
- KZG-коммитмент — полиномиальный коммитмент, позволяющий делать пруфы постоянного размера. Список значений кодируется в многочлен, для него публикуется коммитмент, а доказательство корректности элемента сводится к проверке значения многочлена в точке.
- Witness (свидетель) — набор данных, который прикладывается к блоку и позволяет узлу, не хранящему состояние, проверить все чтения/записи в state.
Подробнее см. KZG-коммитменты и Векторные коммитменты.
Структура Verkle-дерева в Ethereum
По смыслу Verkle-дерево — это префиксное дерево (trie) с широкими узлами и специальной схемой коммитментов и доказательств.
Ключи состояния: stem и suffix
В спеке Ethereum ключи состояния для Verkle представляют в виде 32 байт, разделённых на:
- 31 байт — stem («ствол»): общая часть пути для группы связанных значений;
- 1 байт — suffix («хвост»): индекс ячейки внутри этого stem (0..255).
Идея:
- все значения, относящиеся к одному аккаунту/слоту стореджа, часто делят один и тот же stem и отличаются только суффиксом;
- это позволяет батчить пруфы по многим значениям одного stem и сильно экономить на witness.
Подробнее о раскладке ключей см. Размётка ключей состояния в Ethereum.
Типы узлов
Обобщённо в Verkle-дереве выделяют:
- Внутренние узлы (inner nodes)
Хранят векторный коммитмент к массиву из N детей (обычно N = 256):
- каждый индекс 0..255 — либо коммитмент следующего узла, либо ссылка на листовые данные;
- узел публикует только один KZG-коммитмент ко всему массиву.
- Листовые/extension-узлы
Привязаны к конкретному stem и содержат до 256 значений по всем возможным suffix (0..255):
- для отсутствующих ячеек хранится «пустое» значение;
- над массивом значений строится KZG-коммитмент.
При глубине в несколько уровней (обычно 2–3) такое дерево покрывает всё состояние Ethereum, оставаясь значительно мельче, чем MPT.
Как работает доказательство (witness) в Verkle
Чтобы валидатор без локального state проверил чтение V = state[key], ему нужен witness, в который входят:
- путь ключа (stem + suffix) и информация, где именно в дереве лежит значение;
- доказательство для листового узла:
- массив значений для данного stem (или его кодированное представление);
- KZG-пруф, что значение на позиции suffix соответствует коммитменту листа;
- пруфы по внутренним уровням:
- для каждого уровня — KZG-пруф, что «коммитмент ребёнка» действительно является элементом массива детей родителя в позиции i;
- цепочка таких пруфов от листа до корня.
Поскольку:
- пруфы KZG имеют постоянный размер;
- глубина дерева мала (широкие узлы);
суммарный witness на одно чтение получается компактным. А при батчинге множества чтений (особенно по одним и тем же stems) общий witness для блока остаётся достаточно небольшим для p2p-сети.
Подробнее см. Stateless-клиенты в Ethereum.
Сравнение: Merkle Patricia Trie vs Verkle
| Критерий | Merkle Patricia Trie (сегодня) | Verkle tree (переход) |
|---|---|---|
| Тип узлов | Хеши детей, ниббл-ветвление | Векторные коммитменты, байтовое ветвление (256) |
| Глубина дерева | Значительная, особенно при большом состоянии | Меньше уровней за счёт широких узлов |
| Размер пруфа на ключ | Логарифмически растёт с глубиной, много хешей | Небольшое число KZG-пруфов, почти не зависит от ветвления |
| Батчинг чтений | Частично помогает, но ветки часто дублируются | Лучший эффект: много общих частей witness для одного stem |
| Stateless-валидация | Теоретически возможна, но witness слишком велик | Практически достижима, witness укладывается в p2p-ограничения |
| Удобство для zk | Большие Merkle-ветки в публичных входах | Меньше данных, проще zk-пруфы поверх state |
См. Merkle Patricia Trie для деталей текущей структуры.
Verkle и stateless-клиенты
Цель перехода на Verkle — сделать реалистичным сценарий, в котором узел:
- не хранит полный state (или хранит только кэш популярных частей);
- получает вместе с блоком witness по всем чтениям/записям;
- проверяет корректность состояния и перехода от старого корня к новому;
- после проверки может выбросить witness.
Варианты:
- weak statelessness — узел кэширует часто используемые узлы Verkle-дерева, снижая объём необходимых данных;
- full statelessness — узел почти не хранит состояние и зависит от внешних источников witness.
Verkle-дерево делает оба варианта реалистичными: witness по блоку укладывается в разумные размеры, что позволяет:
- запускать валидатор на более дешёвом оборудовании;
- легче синхронизировать новые узлы;
- интегрировать Ethereum с лёгкими клиентов на основе Portal Network.
Подробнее: Stateless-клиенты.
Влияние на газовую модель и дизайн контрактов
С Verkle возникает возможность лучше связать стоимость газа с реальной ценой доступа к состоянию:
- чтения, которые «разбросаны» по многим stems, создают больше нагрузки на witness;
- компактные, «локальные» по ключам структуры данных используют меньше места в witness.
Ожидаемые последствия:
- возможна корректировка газовых констант для операций чтения/записи в state;
- разработчики контрактов будут мотивированы:
- группировать связанные данные по одним stem;
- минимизировать хаотичный доступ к state.
Практические советы:
- проектируйте ключи так, чтобы у одного аккаунта/контракта как можно больше слотов попадало в один stem (разные suffix);
- батчируйте операции чтения/записи, ориентируясь на «локальность» по ключам;
- профилируйте, какие ключи и в каком порядке читает ваш протокол.
Миграция Ethereum с MPT на Verkle
Переход к новой структуре состояния в публичном блокчейне — сложный многошаговый процесс. Для Ethereum дорожная карта включает:
- Фазу подготовки.
- Реализации Verkle в нескольких клиентах.
- Параллельный расчёт MPT- и Verkle-корней на тестовых сетях.
- Инструменты для преобразования существующего состояния в новый формат (stems/suffixes).
- Фазу валидации.
- Проверка, что состояние, хранимое в Verkle, соответствует MPT.
- Тестовые сети, где Verkle-корень уже используется как основной.
- Хардфорк.
- Активация блока, начиная с которого узлы:
- используют только Verkle-корень состояния в заголовке;
- строят и проверяют witness по правилам Verkle.
- Узлы, оставшиеся на MPT, перестают быть совместимыми с основной сетью.
После миграции:
- архивные узлы продолжают хранить историю в прежнем формате, но актуальное состояние коммитится уже через Verkle;
- инструменты и RPC постепенно адаптируются к новой структуре.
Verkle, danksharding и L2
Verkle-дерево — часть более широкой картины масштабирования Ethereum:
- Данктшардинг и блобы данных (EIP-4844 и далее) масштабируют доступность данных для L2-роллапов.
- PeerDAS и EIP-7251 помогают:
- эффективнее распределять блоб-данные по узлам;
- упростить консенсусный слой за счёт укрупнения валидаторов.
- Verkle уменьшает размер state-witness и делает возможной stateless-валидацию.
Совместно эти направления позволяют:
- удерживать запуск узла Ethereum в «домашних» рамках, даже при росте экосистемы;
- давать L2-роллапам дешёвое и масштабируемое место для данных;
- облегчать интеграцию с zk-пруфами и zk-EVM (меньше данных для включения в доказательства).
Частые вопросы
Verkle — это просто «улучшенный Merkle»? И да, и нет. Схема «дерево → корневой коммитмент» похожа, но вместо хеш-цепочек используются векторные коммитменты, что радикально меняет размер пруфов и дизайн узлов.
Нужна ли доверительная установка (trusted setup)? Для KZG-коммитментов требуется trusted setup. Ethereum уже прошёл общесетевую церемонию установки для блоб-данных (EIP-4844), и те же артефакты могут повторно использоваться для Verkle. Альтернативы без trusted setup существуют, но хуже по параметрам.
Решит ли Verkle все проблемы масштабирования? Нет. Verkle — это «кирпич» в масштабировании слоя состояния. Вопросы доступности данных, MEV, дизайна L2 и экономики газа остаются отдельными направлениями, которые решаются параллельно.
Что поменяется для разработчиков смарт-контрактов? Код на Solidity не нужно переписывать, но:
- изменится «настоящая» цена разных паттернов доступа к state;
- выгоднее станет хранить данные более локально и аккуратно, меньше «скакать» по ключам.