Векторный коммитмент (vector commitment) — это криптографическая примитив, который позволяет:
- зафиксировать упорядоченный массив значений одним коротким коммитментом;
- позже доказать, что на позиции с индексом *i* действительно лежит конкретное значение *v*;
- при этом размер коммитмента и пруфа не зависит от длины массива (или растёт очень слабо).
Если обычный блокчейн часто опирается на Merkle-деревья, где каждый элемент списка имеет свою ветку хешей, то векторный коммитмент позволяет «зажать» целый массив в один отпечаток и работать с отдельными элементами через компактные доказательства.
В экосистеме Ethereum векторные коммитменты реализуются в первую очередь через KZG-коммитменты и используются:
- в Verkle-деревьях состояния;
- в механизме блоб-данных для proto-danksharding (EIP-4844);
- как строительный блок для масштабируемой доступности данных и stateless-клиентов.
Зачем нужны векторные коммитменты
Основные задачи, которые решают vector commitments:
- Компактные доказательства по индексам
Можно хранить один коммитмент к целому массиву и при этом:
- доказывать корректность конкретного элемента value[i];
- не раскрывать весь массив.
- Фиксация порядка
В отличие от многих «множество-ориентированных» схем (set commitments), векторный коммитмент учитывает позиции элементов: важно не только «что», но и «где лежит».
- Масштабирование пруфов
В блокчейнах это позволяет:
- уменьшать размер свидетельств состояния (witness);
- эффективно батчить проверки для многих ключей;
- строить более лёгкие клиенты и zk-доказательства.
Для Ethereum это критично в контексте:
- перехода от Merkle Patricia Trie к Verkle-tree;
- масштабирования L2 через данктшардинг и блобы данных;
- поддержки stateless-клиентов и упрощения работы узлов.
Интуитивно: отличие от Merkle-дерева
Если сравнивать с Merkle-деревом:
- Merkle-дерево:
- каждый элемент массива — отдельный лист;
- для доказательства элемента нужно перечислить хеши «по пути» к корню;
- размер пруфа растёт с глубиной дерева (O(log n)).
- Векторный коммитмент:
- массив коммитится как единое целое;
- для элемента по индексу i даётся короткий пруф, размер которого почти не зависит от длины массива;
- часто есть поддержка батч-доказательств для нескольких индексов.
Упрощённо: Merkle — это «дерево хешей», векторный коммитмент — «умный отпечаток массива», умеющий доказывать корректность отдельных ячеек.
Формальная модель (без формул)
Схема векторного коммитмента обычно определяет три операции:
- Commit(vector) → *C*
Принимает упорядоченный список значений (например, [v₀, v₁, …, vₙ₋₁]) и возвращает короткий коммитмент *C*.
- Open(vector, i) → proof
По индексу *i* генерирует пруф того, что vector[i] = vᵢ и это согласовано с *C*.
- Verify(C, i, vᵢ, proof) → true/false
Проверяет, что:
- *vᵢ* действительно находится на позиции *i*;
- массив, к которому делался commit, согласован с *C*.
В хороших схемах:
- размер *C* и proof — константа (не зависит от длины массива);
- есть возможность батч-пруфов — одним доказательством покрывать несколько индексов;
- нельзя подменить значение на позиции *i*, не изменив коммитмент *C*.
KZG-коммитменты дают такую схему за счёт представления массива значений как многочлена и использования полиномиальных коммитментов.
Подробнее о криптографической части см. KZG-коммитменты.
Векторные коммитменты в Ethereum
В Ethereum векторные коммитменты используются в нескольких ключевых подсистемах.
Verkle-деревья состояния
В Verkle tree:
- каждый внутренний узел хранит векторный коммитмент к массиву детей (например, 256 ссылок на дочерние узлы);
- листовые узлы коммитят массив значений по всем возможным suffix для одного stem (группы ключей состояния);
- пруф по пути от листа к корню — это набор компактных KZG-доказательств, что:
- конкретный элемент массива детей равен нужному коммитменту;
- конкретное значение в листе равно ожидаемому.
Благодаря этому:
- witness для одного ключа в состоянии становится в разы меньше, чем в MPT;
- witness по целому блоку достаточно лёгкий для p2p-сети и stateless-клиентов;
- проще строить zk-доказательства поверх состояния.
Блоб-данные и danksharding
В proto-danksharding (EIP-4844) и дальнейшем данктшардинге:
- данные блоба интерпретируются как вектор значений;
- из них строится полином и KZG-коммитмент;
- узлы могут:
- получать отдельные фрагменты блоба;
- проверять их корректность по KZG-пруфам;
- участвовать в PeerDAS (Data Availability Sampling).
По сути, коммитмент к блобу — это частный случай векторного коммитмента: Ethereum фиксирует весь массив данных одного блоба, а затем выборочно проверяет и раздаёт его части.
Плюсы и минусы векторных коммитментов
Преимущества:
- компактные и проверяемые пруфы для отдельных элементов массива;
- естественная поддержка упорядоченности данных (важна позиция);
- хорошая совместимость с батч-пруфами и zk-доказательствами;
- возможность строить поверх них более сложные структуры (Verkle-деревья, блоб-слой DA).
Компромиссы:
- реальные реализации (как KZG) часто требуют trusted setup;
- криптография сложнее, чем у Merkle-деревьев;
- реализация и аудит схем предъявляют высокие требования к клиентам.
Несмотря на это, для задач Ethereum (масштабируемое DA и компактные state-пруфы) преимущество по размерам и свойствам пруфов перевешивает.
Что это значит для пользователя и разработчика
Для обычного пользователя:
- vector commitments — «подкапотный» механизм;
- их появление означает:
- дешевле и стабильнее комиссии в L2-роллапах;
- более доступный запуск узлов и рост децентрализации;
- основу для более лёгких кошельков и клиентов.
Для разработчика протоколов:
- важно понимать, что Verkle-дерево и блоб-слой используют именно векторные коммитменты, а не традиционные Merkle;
- при проектировании L2, мостов и zk-протоколов:
- имеет смысл ориентироваться на KZG/Verkle как «нативный» стандарт Ethereum;
- учитывать структуру witness и влияние на Data Availability.