KZG-коммитменты — полиномиальные коммитменты для Ethereum (EIP-4844 и Verkle)

KZG-коммитменты (Kate–Zaverucha–Goldberg commitments) — это схема полиномиальных коммитментов, которая позволяет:

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

В экосистеме Ethereum (ETH) KZG-коммитменты стали базовым строительным блоком для:

За счёт KZG сеть получает возможность масштабировать доступность данных (Data Availability) для L2-роллапов и готовиться к stateless-клиентам.

KZG-коммитменты — полиномиальные коммитменты для Ethereum (EIP-4844 и Verkle)

Зачем Ethereum понадобились KZG-коммитменты

Исторически Ethereum опирался на:

  • Merkle-структуры (Merkle Patricia Trie) для состояния и деревьев блоков;
  • обычные хеши и Merkle-доказательства, размер которых растёт с глубиной дерева.

Для rollup-centric roadmap возникли новые требования:

  • дешёвые, но проверяемые блоб-данные для L2 — в EIP-4844 блобы кодируются как полиномы и коммитятся через KZG;
  • компактные пруфы состояния для Verkle-дерева и stateless-валидации;
  • возможность использовать Data Availability Sampling (DAS) без скачивания всех данных каждым узлом.

KZG-коммитменты дают:

  • короткий корневой коммитмент к полиному (а значит и к блобу данных);
  • небольшой пруф корректности значения в точке;
  • хорошую совместимость с DAS и векторными коммитментами.

Базовая идея полиномиальных KZG-коммитментов

Идея схемы Kate–Zaverucha–Goldberg:

  • есть многочлен \(f(x)\) степени ≤ d над конечным полем;
  • в ходе trusted setup выбирается секретное значение τ, и публикуются элементы вида

\(g, g^{\tau}, g^{\tau^2}, …, g^{\tau^d}\), после чего τ уничтожается;

  • коммитмент к многочлену — это по сути \(g^{f(\tau)}\), вычисляемый из коэффициентов и параметров;
  • чтобы доказать, что \(f(u) = v\), доказывающий строит вспомогательный многочлен \(q(x)\), такой что

\(f(x) − v = (x−u)·q(x)\), и публикует пруф \(π = g^{q(\tau)}\);

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

Ключевые свойства:

  • размер коммитмента и пруфа — константа, не зависящая от степени полинома;
  • поддерживаются батч-открытия (одно доказательство сразу для нескольких точек);
  • схема естественно работает как векторный коммитмент: массив значений кодируется полиномом, а пруф подтверждает значение по индексу.

KZG в proto-danksharding (EIP-4844)

В EIP-4844 введён новый тип транзакций с блоб-данными:

  • блоб — это крупный блок данных (фиксированный набор полевых элементов);
  • данные блоба интерпретируются как значения полинома в заранее определённых точках;
  • к каждому блобу строится KZG-коммитмент, который включается в блок L1.

Механика:

  • L2-роллап формирует пакет транзакций и кодирует данные в блоб;
  • к блобу вычисляется KZG-коммитмент и записывается в блок;
  • сами блобы узлы хранят ограниченное время; затем они могут быть удалены — в цепи остаются только коммитменты и метаданные;
  • любой участник может запросить фрагменты блоба и проверить их корректность с помощью KZG-пруфов.

Это даёт:

  • дешёвое, но криптографически привязанное к Ethereum хранилище данных для L2;
  • совместимость с будущим PeerDAS и DAS, где узлы будут выборочно проверять только часть фрагментов блобов.

KZG в Verkle-дереве состояния

В Verkle-дереве KZG используются как векторные коммитменты:

  • внутренний узел хранит коммитмент к массиву из N дочерних элементов (например, 256 ссылок на детей);
  • листовой/extension-узел коммитит массив значений для одного stem (группы ключей состояния);
  • пруф по пути от листа к корню состоит из небольшого числа KZG-доказательств.

Преимущества по сравнению с Merkle Patricia Trie:

  • размер witness для одного ключа на порядок меньше;
  • общий witness по блоку становится достаточно лёгким для p2p-сети;
  • меньше данных нужно включать в zk-доказательства для zk-EVM и rollups.

Это делает реалистичными stateless-клиенты и упрощает дальнейшее масштабирование слоя состояния.

Trusted setup и допущения безопасности

Особенность KZG — необходимость trusted setup:

  • в ходе многосторонней церемонии («Powers of Tau») участники совместно генерируют параметры схемы;
  • каждый добавляет свою долю энтропии и обязан уничтожить свой секрет;
  • безопасность опирается на предположение, что хотя бы один участник действовал честно, а итоговое τ никому не известно.

Последствия для Ethereum:

  • KZG-коммитменты дают отличные параметры (короткие пруфы, быстрые проверки), но требуют доверия к результатам церемонии;
  • те же артефакты trusted setup, использованные для EIP-4844, могут переиспользоваться в Verkle-дереве и других компонентах.

Альтернативы без trusted setup существуют (например, схемы на базе FRI), но они хуже по размеру пруфов и нагрузке на вычисления, поэтому для базового слоя Ethereum выбран компромисс в пользу KZG.

Плюсы и минусы KZG относительно Merkle и других схем

Плюсы:

  • O(1) размер пруфа для проверки значения в точке;
  • батч-открытия позволяют одним пруфом покрывать несколько значений;
  • эффективная проверка за счёт парных эллиптических кривых;
  • удобство как для блоб-данных EIP-4844, так и для векторных коммитментов в Verkle.

Минусы и trade-off’ы:

  • необходимость доверенной церемонии (trusted setup);
  • зависимость от криптографии на билинейных спариваниях;
  • более сложная реализация и аудит по сравнению с классическими Merkle-деревьями.

Для задач Ethereum (масштабируемое DA для L2 и компактные state-пруфы) этот компромисс считается приемлемым: усложнив криптографию, сеть выигрывает в UX и параметрах протокола.

Что это означает для пользователей и разработчиков

Для рядового пользователя:

  • KZG-коммитменты — «невидимый» низкоуровневый механизм;
  • благодаря им дешевеют транзакции в L2, потому что публикация данных в блобах становится дешевле и масштабируемее;
  • запуск полноценного узла Ethereum остаётся доступным, даже при росте объёма данных.

Для разработчика протоколов и инфраструктуры:

  • важно понимать модель блоб-данных и DA в контексте L2;
  • при работе с Verkle и stateless-валидацией нужно учитывать структуру witness и влияние на сетевую нагрузку;
  • zk-проекты и rollups могут использовать KZG как стандартный «кирпич» для компактных доказательств.

См. также

Task Runner