1. Вступ

В останній день 2023 року Віталік поділився дорожньою картою Ethereum на 2023 рік на Twitter, узагальнюючи прогрес Ethereum протягом року. Розділ дорожньої карти «The Verge» описав, як технологія Ethereum може перевіряти стани блокчейну більш просто й ефективно. Однією з основних концепцій, згаданих там, є дерева Веркле. Так от, що таке дерева Веркле, для чого потрібен Ethereum та як дерева Веркле вирішують проблеми? Метою цієї статті є відповідь на ці питання для читачів, які не глибоко вникають у криптографію та математику, допомагаючи тим, хто має уявлення про Ethereum, швидко зрозуміти концепцію дерев Веркле.

2. Перевірене запитання

Технологія перевірки запитів широко досліджується в галузі традиційних баз даних, в основному використовується для вирішення проблем довіри до зовнішніх баз даних. У багатьох випадках власники даних можуть вибрати не зберігати дані самостійно, а замість цього довірити свої потреби в базі даних третій стороні для надання послуг баз даних (таких як хмарні бази даних). Однак, через те що треті сторони не завжди є надійними, важко забезпечити достовірність результатів запитів, які вони повертають користувачам. Поточні рішення для перевірки запитів для традиційних баз даних в основному поділяються на дві категорії: ті, що базуються на ADS (аутентифіковані структури даних), та ті, що базуються на перевірці обчислень.

ADS - це перевірний метод запиту, який широко використовується в традиційних базах даних, які, в основному, ґрунтуються на структурах, таких як Дерева Меркла або схожі накопичувальні структури. З розвитком криптографічних інструментів багато дослідників почали поступово досліджувати використання методів перевірки обчислень для вирішення проблем з ненадійними запитами. Деякі схеми перевірки обчислень, засновані на протоколах доказу у нульовому знанні, таких як SNARKs, можуть опосередковано підтримувати перевірні запити для зовнішніх баз даних. Ці схеми підтримують велику кількість типів запитів та генерують менше інформації для перевірки, але мають вищі обчислювальні витрати.

На даний момент Ethereum використовує дерева Меркла для реалізації перевірки запитів, а технологія Verkle Tree також ґрунтується на технології дерева Меркла. Тому давайте спочатку познайомимо читачів з деревами Меркла, щоб допомогти їм зрозуміти роль перевірки запитів, використовуючи їх як приклад.

3. Дерева Меркла

3.1. Визначення та характеристики дерев Меркля

Дерева Меркла - це структура, схожа на дерево, яку часто використовують в криптографії, підходить для вирішення проблем цілісності даних. Нижче наведено типову структуру дерева Меркла: листові вузли представляють оригінальні дані або їх хеш-значення, а кожен нелистовий (внутрішній) вузол містить поєднаний хеш своїх дочірніх вузлів.

Merkle Trees мають дві важливі характеристики:

1. Стійкість до втручання: Дерева Меркля зазвичай конструюються за допомогою функцій хешування, що стійкі до зіткнень, що робить обчислювально неможливим знайти два різні повідомлення, які виробляють одне й той же значення хешу. Зі структури Дерева Меркля зрозуміло, що будь-яка модифікація даних транзакції в листковому вузлі призведе до зміни кореневого хешу дерева.
2. Ефективне підтвердження цілісності великих наборів даних: Перевірники повинні зберігати лише кореневий хеш дерева Меркла, щоб перевірити цілісність будь-яких даних. Це досягається без передачі повного набору даних, а за допомогою сусідніх вузлів вздовж шляху від листка до кореня, відомих як Мерклівський шлях. Ці сусідні вузли можуть бути використані для відновлення кореневого хешу для цілей верифікації.

3.2. Як скласти доказ Меркла?

У звичайному сценарії перевірки запитів існує доказувач та перевіряючий. Доказувач повинен згенерувати доказ та відправити його перевіряючому. Відповідно до мережі Ethereum, типовий сценарій застосування полягає в тому, що легкий вузол (клієнт, який зберігає лише заголовки блоків) запитує дані транзакцій у повного вузла або архівного вузла (клієнти з усіма даними) та отримує доказ Merkle для локальної перевірки правильності результату запиту.

Доказ Меркля складається з наступних трьох частин:

1. Кореневий хеш дерева Меркла для повного набору даних.
2. Блок даних, цілісність якого потрібно довести.
3. Шлях Меркла, який включає значення всіх сусідніх вузлів на шляху від листового вузла до кореневого вузла.

Серед них корінний хеш дерева Меркла потрібно надіслати верифікатору наперед через надійний засіб, і верифікатор повинен довіряти цій ​​значенню. У Ethereum надійність даних блоку забезпечується алгоритмом консенсусу, і корінний хеш дерева Меркла міститься в заголовку блоку.

Нижче подано конкретний приклад: коли доведеться довести переконателю, що «4» є блоком даних, що існує в наборі даних, а переконувач має довірчий кореневий хеш «1d25» повного дерева Меркла набору даних, то доводнику потрібно лише надати всі дані, позначені синім кольором. Припускаючи, що в наборі є n шматків даних, для перевірки правильності будь-якого блоку даних потрібно не більше, ніж 𝘭𝘰𝘨₂(𝘯) обчислень хешу.

Легкі вузли Ethereum синхронізують лише заголовки блоків, які містять корені дерев Меркля для різних наборів даних (дерево стану, дерево транзакцій, дерево квитанцій). Коли легкий вузол запитує повний вузол про дані певного листового вузла в дереві, повний вузол повертає початкові дані разом із відповідним шляхом доказу Меркля. Це дозволяє легкому вузлу довіряти правильності результату запиту.

3.3. Варіанти дерев Меркла

На основі дерев Меркля їх можна поєднувати та модифікувати з іншими структурами даних для досягнення нових характеристик на основі різних цілей. Для задоволення різноманітних сценаріїв перевірки, дерева Меркля можуть бути розширені до різних індексованих структур даних, таких як дерева Меркля-В (MBT). Для ефективного виконання операцій, таких як вставка, вилучення та запитування, команда Ethereum запропонувала Дерево Меркля Патріції (MPT).

3.3.1. Дерево Меркла-Б

Merkle-B дерево (MBT) використовується головним чином для обробки перевірних запитів на діапазони. Нехай 𝑓 буде вентилем MBT (кількість дочірніх вузлів для кожного вузла). На основі структури B+ дерева, кожен внутрішній вузол MBT, крім зберігання 𝑓 — 1 індексних ключів та вказівників на 𝑓 дочірніх вузлів, також підтримує значення хешів всіх своїх дочірніх вузлів у підсумованій формі. Нижче наведено представлення структури листових вузлів та внутрішніх вузлів у MBT.

Коли потрібно довести, що дані, що повертаються з певного діапазону запитів, відповідають вказаному діапазону, сервер, який обчислює об'єкт перевірки (VO), спочатку повинен виконати дві операції пошуку зверху-вниз, щоб знайти ліві та праві межі. Він також повинен повернути всі дані в цьому діапазоні, а також хеші всіх гілок, необхідних для побудови шляху до кореневого хешу.

Недолік цієї структури даних полягає в тому, що повернутий VO може лише довести, що результати запиту знаходяться в межах запитаного діапазону, але він не може довести, що повернуті результати є повними.

3.3.2. Дерево Меркла Патрісії

Якщо для надання перевірки запитів використовується наївне дерево Меркла, процес відтворення кореня дерева Меркла після кожного вставлення або видалення даних може стати значним. Крім того, це потребує підтримки додаткових дерев пошуку даних для зберігання. Дерево Меркла Патріції (MPT) поєднує властивості дерева Радікс (компактне префіксне дерево) та дерева Меркла, що дозволяє виконувати вставки, видалення та запити за час O (log (N)). Для повного розуміння MPT читачі можуть звертатися до детальних технічних статей з цієї теми. Ця стаття лише введе деякі базові визначення та надасть приклади, щоб допомогти читачам швидко зрозуміти MPT.

Базова структура Ethereum використовує базу даних ключ-значення для зберігання, що означає, що дані зберігаються у формі пар ключ-значення. MPT також розкладений на пари ключ-значення для зберігання. Ми визначаємо логічну структуру вузлів MPT наступним чином:

• індекс
• шлях
• дані

У контексті дерева Меркла-Патріції (MPT) "індекс" вказує на ключ пари ключ-значення, тоді як "шлях", разом з "даними", становить значення пари ключ-значення. Індекс фактично зберігає хеш вузла дерева Меркла, а шлях відповідає рядку шляху, використаному в префіксному дереві для знаходження цільового вузла. Ethereum використовує шістнадцяткові рядки як рядки шляху, тому ширина MPT становить 16. Дані - це цільові дані, що відповідають шляху.

Нижче наведено приклад MPT, який був оптимізований за допомогою стиснутих префіксів, що зберігають наступні дані ключ-значення:

{

'cab8': 'собака',

‘cabe’: ‘кіт’,

‘39’: ‘курка’,

'395': 'качка',

‘56f0’: ‘кінь’

}

Щоб знайти дані «duck» за допомогою шляху «395», ви почнете з кореневого хешу і продовжите через хешА, хешС та хешD, щоб урешті досягти цільових даних. Ось посібник крок за кроком:

1. Кореневий хеш: Це точка входу у дерево Меркла-Патріції (MPT), і ви будете використовувати його, щоб знайти перший вузол.
2. hashA: На основі кореневого хеша ви отримаєте вузол або вміст, ідентифікований за допомогою hashA. Оскільки шлях - "395", ви шукаєте частину дерева, яка приведе вас до "3".
3. hashC: Після доступу до вмісту hashA ви продовжуєте слідувати шляхом. Наступний сегмент, "9", приводить вас до hashC.
4. hashD: Нарешті, продовжуючи шлях, останній сегмент "5" вказує вам на hashD, який містить значення "duck".

На кожному кроці в шляху MPT використовує властивості як дерева Radix для знаходження правильного шляху на основі ключа, так і дерева Merkle для забезпечення цілісності даних за допомогою хеш-посилань. "Шляхи" в дереві зазвичай представлені шістнадцятковим кодуванням, яке відповідає гілковому фактору дерева 16. Кожен вузол в шляху містить достатньо вказівників хеша (до дочірніх вузлів) та значень для перевірки цілісності даних і навігації через дерево.

Зверніть увагу, що в реальному MPT шляхи та дані будуть закодовані та збережені у певному форматі, а додаткові типи вузлів (такі як розширюючі вузли та листові вузли) допомагають оптимізувати структуру для ефективності в різних сценаріях.

4. Векторний зобов'язання

Схеми зобов'язань[1] - це криптографічні примітиви, які забезпечують конфіденційність та цілісність даних. Вони широко використовуються в сценаріях, таких як докази знань та безпечне обчислення між багатьма сторонами. Основна схема зобов'язань поділяється на дві фази: фазу зобов'язання та фазу розкриття (або відкриття).

1. Фаза фіксації: На цій фазі фіксатор використовує криптографічний алгоритм для зв'язування повідомлення зі значенням зобов'язання та надсилає це значення зобов'язання одержувачеві. На цьому етапі зобов'язання має дві властивості: приховування і зв'язування. Приховування забезпечує, що зміст зобов'язаного повідомлення невідомий всім, крім фіксатора. Зв'язування гарантує, що як тільки зобов'язання було зроблено, його не можна змінити ніким, включаючи фіксатора.
2. Фаза розкриття (відкриття): Протягом цієї фази комітер може довести отримувачеві, що отримане ними значення зобов'язання - це дійсне зобов'язання до початкового повідомлення. Зобов'язання має властивість правильності, означаючи, що якщо як комітер, так і отримувач правильно дотримуються протоколу, отримувач буде переконаний, що отримане ними значення зобов'язання під час фази зобов'язання є дійсним зобов'язанням до початкового повідомлення.

Векторний зобов'язання - це особливий тип схеми зобов'язань, запропонований Каталано та ін. [2], який дозволяє зобов'язувачу зобов'язатися до упорядкованого набору повідомлень 𝑚 = ⟨𝑚1, 𝑚2, …, 𝑚𝑞 ⟩ та розкривати (відкривати) у будь-якій вказаній позиції, щоб довести, що повідомлення 𝑚𝑖 - це 𝑖-е зобов'язане повідомлення. У векторних зобов'язаннях прив'язка означає, що ніхто не може відкрити ту ж саму позицію, щоб розкрити різні повідомлення.

Зазвичай схема зобов'язання вектора складається з наступних алгоритмів:

5. Дерева Verkle

5.1. Визначення та характеристики дерев Verkle

Визначення: Дерева Веркле = Векторні Зобов'язання + Дерева Меркле.

Зверніть увагу: Віталік Бутерін, співзасновник Ethereum, має блогповідомлення, присвячене конкретно введенню дерев Verkle. Ця глава додає деяке тло та математичні знання на підставі його блогу. Деякі дані та ілюстрації в наступному тексті походять з його блогу.

Дерева Веркле (VTs) характеризуються тим, що надають менші докази порівняно з деревами Меркла. Для даних в розмірі мільярдів записів дерево Меркла може генерувати докази розміром приблизно 1 КБ, тоді як докази дерева Веркле можуть бути менше 150 байтів. Цей компактний розмір доказів є перевагою для впровадженняклієнти без стану”.

Структура дерева Verkle трохи схожа зі структурою дерева Меркла-Патріції (MPT). Ось приклад його структури. Вузли дерева Verkle можуть бути: (i) Порожні, (ii) Листові вузли, що містять ключ і його відповідне значення, або (iii) Внутрішні вузли з фіксованою кількістю дочірніх вузлів. Ця кількість дітей також називається «шириною» дерева.

Відмінність між VT (Verkle Trees) та MPT (Merkle Patricia Trees) полягає в першу чергу в тому, як ширина дерева (або фактор розгалуження, що вказує на кількість дочірніх вузлів, яким володіє вузол у дереві) впливає на їх ефективність. У випадку MPT, якщо ширина більша, ефективність зменшується, оскільки більша ширина означає більше сусідніх вузлів, що може призвести до більшого часу оновлення для MPT та більших розмірів доказів. Навпаки, для VT ширше дерево призводить до менших доказів. Єдине обмеження полягає в тому, що якщо ширина занадто велика, час, необхідний для генерації доказу, може стати довшим.

У Ethereum’s @vbuterin/verkle_tree_eip">у проектах дизайну для ВТ рекомендується ширина 256, що значно більше, ніж поточні 16 для MPT. Така велика ширина є доцільною в ВТ через використання передових криптографічних технік, таких як векторні зобов'язання, які дозволяють компактні докази, незалежно від ширини дерева. Ця техніка стиснення дозволяє деревам Verkle масштабуватися більш ефективно щодо розміру доказів. Наступний текст розкриє вищезазначені особливості більш детально.

5.2. Зобов'язання та доказ дерев Verkle

Давайте подивимось, як генеруються докази в MPT: Доказ повинен включати хеш-значення всіх бічних вузлів (або сестринських вузлів) на шляху від кореневого вузла до цільового листового вузла. Взявши «4ce» як приклад, частини, позначені червоним кольором на діаграмі нижче, є вузли, які повинні бути включені у повернутий доказ.

У деревах Веркле вам не потрібно надавати вузли-сусіди; замість цього вам потрібно надати лише шлях разом з деякими додатковими даними як доказ.

Так як згенерувати зобов'язання для VT? Функція хешу, яка використовується для обчислення, не є звичайним хешем, але використовує зобов'язання вектора.

Після заміни хеш-функції алгоритмом генерації зобов'язань від векторних зобов'язань так званий кореневий хеш тепер є кореневим зобов'язанням. Якщо дані будь-якого вузла піддадуться втручанню, це врешті-решт призведе до впливу на кореневе зобов'язання.

Як згенерувати доказ? Як показано на діаграмі нижче, вам потрібно лише надати три піддокази, кожен з яких може підтвердити, що вузол на шляху існує на певній позиції всередині свого батьківського вузла. Чим ширший ширина, тим менше шари, і, відповідно, менше піддоказів потрібно.

У практичних реалізаціях використовуються зобов'язання поліномів (які можуть бути реалізовані просто й ефективно для зобов'язань векторів), що дозволяє зобов'язати поліном. Два найбільш користувацькі схеми зобов'язання поліномів –KZG зобов'язання” та “зобов'язання поліномів у стилі бронежилета(перше має розмір зобов'язання 48 байтів, тоді як останнє - 32 байти).

Якщо ви використовуєте зобов'язання та докази KZG, доказ для кожного проміжного вузла складає всього 96 байтів, що представляє економію місця майже втричі порівняно з базовим деревом Меркля (з урахуванням ширини 256).

Теоретична складність за часом для операцій над деревами Merkle та Verkle така:

Досі введена схема доведення Verkle досить базова; насправді існують ще більш розвинуті стратегії оптимізації.

5.3. Оптимізація: Об'єднання доказів

5.3.1. ідея

У порівнянні з генерацією доказу для кожного рівня зобов'язань на шляху, характеристика поліноміальних зобов'язань може бути використана для досягнення «доведення батьківсько-дитячого відношення між усіма зобов'язаннями на шляху з доказом фіксованого розміру, який може включати необмежену кількість елементів». Для розуміння конкретно того, як це досягається, необхідно ввести деякі математичні знання для пояснення. Ця стаття буде включати деякі математичні формули, але в принципі не буде охоплювати криптографічну частину доказу. Щодо конкретного методу, будь ласка, звертайтесь до схема, яка реалізує багатопідписи через випадкову оцінку.

5.3.2. Математичне походження

Спочатку давайте представимо деякі основні концепції поліномів у математиці: як ми виконуємо зведення полінома, відоме також як зведення степеня полінома?

Припускаючи, що ми знаємо поліном 𝑃(𝑥) та його значення 𝑦₁ при 𝑥₁, тобто 𝑃(𝑥₁) = 𝑦₁ .

Тепер розгляньте новий поліном 𝑃(𝑥) - 𝑦₁, який має значення нуль при (𝑥 = 𝑥₁), оскільки 𝑃(𝑥₁) - 𝑦₁ = 𝑦₁ - 𝑦₁ = 0.

Отже, поліном 𝑃(𝑥) - 𝑦₁ має корінь при 𝑥 = 𝑥₁, що означає, що (𝑥 - 𝑥₁) є множником полінома 𝑃(𝑥) - 𝑦₁.

Іншими словами, ми можем виразити це у наступній формі: [ 𝑃(𝑥) - 𝑦₁ = (𝑥 - 𝑥₁ )𝑄(𝑥)]

𝑄(𝑥) - це інший поліном, чий ступінь на один менший, ніж у 𝑃(𝑥). Це тому, що (𝑥 -𝑥₁ ) є фактором першого ступеня, який зменшує загальний степінь полінома.

Як використовувати KZG, щоб довести одне значення в векторі?

Візьмемо зобов'язання KZG10 як приклад, для полінома 𝑃(𝑥) , припустимо, що його поліноміальне зобов'язання - [ 𝑃(𝑠) ]₁ .

Як вже пояснено, для полінома 𝑃(𝑥), якщо 𝑃(𝑧) = 𝑦, тоді маємо 𝑄(𝑥) = (𝑃(𝑥) - 𝑦)/(𝑥 - 𝑧)

Тепер доказувач може згенерувати доказ того, що поліном 𝑃(𝑥) задовольняє 𝑃(𝑧) = 𝑦: обчисліть [ 𝑄(𝑠) ]₁ та надішліть його перевіряючому.

Верифікатор повинен перевірити 𝑒( [ 𝑄(𝑠) ]₁, [ 𝑠 - 𝑧]₂ ) = 𝑒( [ 𝑃(𝑠) ]₁- [𝑦]₁, [1]₂) .

Як використовувати KZG для доведення кількох значень у векторі?

Ми можемо скласти доказ, щоб продемонструвати кілька значень у векторі наступним чином:

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

Тепер давайте розглянемо схему дерева Verkle без оптимізації з точки зору алгоритму зобов'язання KZG.

Використовуючи метод побудови з розділу «Як використовувати KZG для підтвердження одного значення в векторі», верифікатор може побудувати зобов'язання для початкових та часткових поліномів для кожного полінома 𝑓ᵢ(𝑥) , що призводить до загальної кількості 𝟐﹡𝑚 зобов'язань KZG. Верифікатор надсилає всі ці зобов'язання як доказ для перевірки.

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

Злиття доказів

Доказувач надсилає доказ [ 𝑞( 𝑠 )]₁ верифікатору для перевірки.

Докази, отримані цією схемою, складаються з одного зобов'язання, двох доказів та однієї вартості, з постійним розміром даних. У кінцевому підсумку, після оптимізації об'єднання доказів у дереві Веркле, перевірочний об'єкт даних, відправлений перевіряючому, містить наступне:

1. Постійний розмір доказів
2. Дані листів, які потрібно довести (ключ-значення)
3. Значення зобов'язань всіх вузлів на шляху від листка до кореня (з урахуванням ширини дерева 256 з 2³² вузлами, то середня глибина становить 4, потрібні тільки 3 значення зобов'язання)

Зверніть увагу, що 𝑥ᵢ та 𝑦ᵢ не потрібно надавати явно; їх можна обчислити всі.

5.3.3. продуктивність

Щодо схеми об'єднання доказів для дерев Verkle, конкретний розмір згенерованого доказу наступний (одиниця рядка - мільярд).

Вищевказані дані передбачають використання дерева шириною 256, застосування схеми зобов'язання KZG (з розміром зобов'язання 48 байтів) та максимізацію використання дерева. На практиці для повністю випадкових розподілів інформації глибина дерева збільшувалася б приблизно на 60%, а розмір кожного елемента збільшувався б на 30 байтів. Якщо використовується схема bulletproof, то розмір зобов'язання становив би 32 байти.

5.4. Навантаження обчислень для доведення та перевірки

1. Генерація доказів: Вартість генерації доказів від доказувальника пов'язана з шириною дерева, але кожна атомарна операція вимагає відносно низьких обчислювальних витрат, тому дерева Веркле з шириною від 256 до 1024 працюють добре з точки зору алгоритмів.
2. Підтвердження доказів: Віталік вказав, що алгоритм верифікації є дуже швидким і зазвичай може бути завершений протягом 100 мс, навіть коли потрібно перевірити кілька тисяч значень.
3. При оновленні дерев Веркле: оновлення дерева потребує перерахування всіх проміжних значень зобов'язання вздовж шляху через зміни в значеннях або структурі. Однак Віталік зазначив, що завдяки деяким властивостям алгоритму зобов'язання поліномів, можливо розробити метод, який попередньо обчислює альтернативні значення зобов'язання та зберігає їх, тим самим зменшуючи обчислювальний час під час оновлень, що в сутності обмінює простір на час.

6. Висновки

Наступне - оригінальні слова блогу Віталіка, ми додали абзац в кінці як доповнення.

Дерева Verkle - це потужне оновлення доказів Merkle, які дозволяють отримувати набагато менші розміри доказів. Замість того щоб надавати всі «сестринські вузли» на кожному рівні, доводувачу потрібно лише надати один доказ, який підтверджує всі батьківсько-дитячі відносини між усіма зобов'язаннями вздовж шляхів від кожного листового вузла до кореня. Це дозволяє зменшити розміри доказів в ~6–8 разів порівняно з ідеальними деревами Merkle, і в ~20–30 разів порівняно з шістними деревами Патріці, які використовує сьогодні Ethereum (!!).

Вони потребують більш складної криптографії для впровадження, але вони надають можливість отримати значні прирости в масштабованості. На середній термін, SNARKs можуть покращити речі ще більше: ми можемо або SNARK вже ефективний перевіряльник довідок Verkle, щоб зменшити розмір свідчення до майже нуля, або повернутися до SNARKed довідок Меркла, якщо/коли SNARKs стануть набагато кращими (наприклад, через GKR, або дуже SNARK-friendly хеш-функції, або ASICs). Далі, з появою квантових обчислень змусить змінити STARKed довідки Меркла з хешами, оскільки вони роблять лінійні гомоморфізми, від яких залежать дерева Веркле, небезпечними. Проте наразі вони дають нам ті ж самі прирости в масштабованості, які ми отримуємо з таких більш розвинених технологій, і у нас вже є всі інструменти, які нам потрібні для їх ефективної реалізації.

В даний час багато клієнтів Ethereum забезпечили реалізацію дерева Веркла і пов'язаних з ним тестових мереж. Спільнота все ще обговорює час, коли Verkle Trees буде запущено в основній мережі. Ймовірно, він буде реалізований в оновленні хардфорка в 2024 або 2025 році. Детальну інформацію про дерева Веркла на Ethereum дивіться https://verkle.info/.

7. Посилання

[1]. BRASSARD G, CHAUM D, CRÉPEAU C. Мінімальні докази відомостей про знання[J]. Журнал комп'ютерних і системних наук, 1988, 37(2): 156–189.

[2]. CATALANO D, FIORE D. Векторні зобов'язання та їх застосування [C]//Public-KeyCryptography–PKC 2013: 16th Міжнародна конференція з практики та теорії в криптографії з відкритим ключем, Нара, Японія, 26 лютого – 1 березня 2013 року. Процедури 16. Springer, 2013: 55–72.

Disclaimer：

1. Ця стаття була перепечатана з [ZAN], Усі авторські права належать оригінальному автору [AntChain Open Labs та ZAN]. Якщо є зауваження до цього перепринту, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно з ним впораються.
2. Відповідальність за відмову: погляди та думки, висловлені в цій статті, є виключно авторськими та не становлять жодної інвестиційної поради.
3. Переклад статті на інші мови виконує команда Gate Learn. Якщо не вказано інше, копіювання, поширення або плагіатування перекладених статей заборонено.