Loading...
Серія: Zcash from First Principles . Стаття 6 . Shielded Protocol (фінал) Для кого: новачки, які прочитали статті 0–5. Саме тут усе з'єднується. Що ви винесете: повну, коректну ментальну модель shielded-транзакції Zcash, де кожне поняття із серії займає своє належне місце, а всі незавершені петлі зі Статті 0 замкнуться.
Ми почали у Статті 0 з парадоксу та історії про запечатані конверти на публічній дошці. Потім ми витратили п'ять статей, вибудовуючи складові: скінченні поля, еліптичні криві, commitments, дерева Меркла та докази з нульовим розголошенням. Тепер ми складемо їх разом і подивимося, як працює справжній приватний платіж — від початку до кінця.
Окремо кожна частина, яку ви вивчили, є дотепною. Але магія Zcash полягає в тому, як вони зчіплюються між собою. Nullifier сам по собі не дає приватності. Commitment сам по собі не запобігає підробці. Доказ сам по собі не доводить нічого корисного. Саме збирання перетворює п'ять компонентів на гроші, які одночасно є приватними й надійними.
Ця стаття і є таким збиранням. До кінця фраза «мережа перевіряє транзакцію, яку не може побачити» відчуватиметься не як парадокс, а як очевидний наслідок частин, які ви вже розумієте.
Ось уся серія на одній сторінці, зіставлена від елементів історії зі Статті 0 до реального механізму.
| Елемент історії зі Статті 0 | Реальний компонент | Побудований з |
|---|---|---|
| Гроші всередині конверта | Note (значення, одержувач, випадковість) | кодується як елементи поля (Ст. 1) |
| Запечатаний непрозорий конверт | Note commitment | commitment Pedersen / Sinsemilla (Ст. 2, 3) |
| Публічна дошка | Note commitment tree (anchor = його корінь) | інкрементне дерево Меркла (Ст. 4) |
| Порожній жетон | Nullifier | ZK-дружній геш note + секретного ключа (Ст. 2, 3) |
| «Гроші на вході дорівнюють грошам на виході» | Value commitments + balance check | гомоморфні commitments Pedersen (Ст. 2, 3) |
| Магія за завісою | Zero-knowledge proof | zk-SNARK над арифметичною схемою (Ст. 5) |
| «Лише ти можеш прочитати свій конверт» | Зашифрована note + viewing keys | шифрування + ієрархія ключів (ця стаття) |
Усе, що може робити користувач, походить від одного секрету — spending key — через односторонню ієрархію (кожна стрілка — це незворотне виведення завдяки trapdoor'ам зі Статей 2 і 3):
Варто звернути увагу на дві речі, обидві є наслідками попередніх статей:
Щоб приватно витратити note, ви повинні одночасно переконати мережу в чотирьох речах без розкриття самої note, її значення, її позиції або вашої особи. Кожне твердження задовольняється компонентом, який ви вже знаєте.
Доказ не розкриває жодного з базових фактів (яка саме note, чий ключ, яке значення). Він розкриває лише те, що всі чотири твердження істинні. У цьому і полягає весь трюк shielded Zcash, виражений в одній діаграмі.
Ще у Статтях 2 і 3 ми зазначили, що commitments Pedersen додаються: commitment до v_1 плюс commitment до v_2 є commitment до v_1 + v_2. Саме тут це дає результат.
Кожна вхідна і вихідна note містить value commitment: commitment Pedersen v.G + r.H, який приховує її суму v. Оскільки вони додаються, мережа може обчислити:
(сума value commitments входів) − (сума value commitments виходів)
Якщо транзакція збалансована (гроші не створено і не знищено), частини v точно взаємно скасовуються, лишаючи лише commitment до нульового значення, засліплений залишковою випадковістю. Відправник доводить, що знає цю залишкову випадковість, створюючи невеликий підпис, який називається binding signature. Дійсний binding signature можливий лише тоді, коли значення справді збалансовані, і водночас жодна сума не була розкрита.
Це найчистіша ілюстрація у всій серії того, чому нам були потрібні гомоморфні commitments на основі кривих. Правило «гроші на вході дорівнюють грошам на виході» забезпечується шляхом додавання запечатаних конвертів і перевірки, що результат запечатується в нуль.
Давайте зберемо платіж Alice до Bob. Як навчальну модель ми використаємо чітку структуру Sapling «сторона витрати / сторона виходу».
Shielded-транзакція поєднує два типи описів:
| Опис витрати (споживає note) | Опис виходу (створює note) |
|---|---|
| value commitment входу | value commitment виходу |
| anchor, відносно якого вона доводиться (корінь дерева) | новий note commitment (новий лист) |
| nullifier витраченої note | ephemeral key для шифрування |
| повторно рандомізований публічний ключ + підпис авторизації витрати | зашифрована note (ciphertext для одержувача) |
| zk-SNARK, що доводить чотири твердження | zk-SNARK, що доводить коректність формування виходу |
Плюс один binding signature на весь набір, який забезпечує баланс значень (Розділ 5).
Простежте приватність: мережа перевірила anchor, перевірила, що nullifier є новим, перевірила доказ і перевірила баланс. Вона прийняла коректний платіж, не дізнавшись ні суми, ні адреси, ні того, яку саме note було витрачено. Тим часом nullifier витраченої note (її смерть) і новий commitment Bob (народження його note) лежать у двох різних публічних структурах без видимого зв'язку між ними — той самий розірваний зв'язок зі Статті 0.
Стаття 0 навмисно відкрила запитання. Ось вони всі — закриті.
| Петля, відкрита у Статті 0 | Чим закривається |
|---|---|
| Як можливий запечатаний, але такий, що не підробляється, конверт? | Commitments: приховування завдяки випадковості, прив'язування завдяки стійкості до колізій / trapdoor кривої (Ст. 3) |
| Звідки беруться ключі й секретні рецепти? | Арифметика полів і множення скалярів на еліптичній кривій (Ст. 1, 2) |
| Що саме являє собою «дошка»? | Інкрементне дерево Меркла з note commitments; його корінь — це anchor (Ст. 4) |
| Чому порожній жетон не можна пов'язати з його конвертом? | Nullifier — це keyed hash, який зберігається в окремому наборі від commitments (Ст. 2, 3, 4) |
| Як довести коректність, нічого не розкриваючи? | zk-SNARK над арифметичною схемою, яка кодує всі чотири твердження (Ст. 5) |
| Як одержувач дізнається, що йому заплатили? | Note зашифровується на його адресу; він виконує trial decryption за допомогою viewing key (ця стаття) |
| Як приватно забезпечується «гроші на вході = гроші на виході»? | Гомоморфні value commitments + binding signature (Розд. 5) |
Парадокс із першої сторінки — перевірити те, чого не можна побачити — тепер повністю розчинено. Мережа перевіряє твердження про приховані дані, а не самі дані.
Ми навчали на структурі Sapling, бо її поділ є найнаочнішим. Поточний дизайн, Orchard, радше вдосконалює ці ідеї, ніж замінює їх:
| Sapling | Orchard | |
|---|---|---|
| Одиниця транзакції | окремі описи Spend і Output | уніфіковані Actions (кожна робить одну витрату + один вихід) |
| Система доказів | Groth16 (trusted setup) | Halo 2 (без trusted setup) |
| Криві | BLS12-381 + Jubjub | Pallas / Vesta (Pasta) |
| Commitment hash | Pedersen | Sinsemilla |
Кожне поняття з цієї статті безпосередньо переноситься сюди; Orchard головно об'єднує витрату й вихід разом і замінює систему доказів на таку, що не потребує церемонії. Усі п'ять стовпів залишаються незмінними.
Це найповніша картина в серії, але все ще модель. Ми стиснули точні кодування note в полях, точні формули виведення ключів, повторну рандомізацію ключів витрати, диверсифіковані адреси, поля memo, обробку комісій, різницю між value commitments і note commitments у всіх деталях, а також точну роль кожного підпису. Ми також показали один канонічний потік; реальні транзакції можуть нести багато витрат і виходів одночасно та можуть змішувати transparent і shielded частини. Авторитетним джерелом є Zcash Protocol Specification. Те, що ви тепер маєте, — це правильна форма; специфікація заповнює кожний вимір.
nullifier коректний, і що значення збалансовані — у zero knowledge, не розкриваючи жодного з базових фактів.| Термін | Значення простою англійською |
|---|---|
| Spending key | Єдиний кореневий секрет, з якого виводяться всі ключі користувача |
| Viewing Key | Відкриває ваші транзакції їхньому власнику, не даючи змоги їх витрачати |
| Spend description | Частина tx, яка споживає note (nullifier, anchor, доказ) |
| Output description | Частина tx, яка створює note (commitment, ciphertext, доказ) |
| Action (Orchard) | Уніфікована одиниця, що разом виконує одну витрату й один вихід |
| Value commitment | Гомоморфний commitment Pedersen до суми |
| Binding signature | Підпис, який доводить баланс значень, не розкриваючи їх |
| Anchor | Корінь дерева, відносно якого витрата доводить належність |
| Trial decryption | Перевірка одержувачем нових commitments, щоб знайти note, призначені для нього |
Чи бачить мережа коли-небудь суму або те, хто кому заплатив?
Ні. Вона перевіряє доказ, новизну nullifier, anchor і binding signature. Усі приватні значення залишаються прихованими.
Що заважає мені витратити одну й ту саму note двічі?
Nullifier. Під час витрати він публікується; мережа відхиляє будь-який nullifier, який уже є в наборі nullifier. Та сама note завжди породжує той самий nullifier.
Як можна перевірити баланс, якщо суми приховані?
Value commitments додаються гомоморфно; commitments збалансованої транзакції скорочуються до commitment до нуля, що й доводить binding signature.
Чи можу я довести свої транзакції аудитору, не втрачаючи контролю? Так. Передайте viewing key. Він відкриє вашу shielded-активність, але не зможе авторизувати витрати завдяки односторонній ієрархії ключів.
Чи Sapling уже застарів, раз існує Orchard? Обидва існували в мережі; Orchard є поточним дизайном. Поняття спільні, тож розуміння одного дає вам і друге.
Друг каже: «Оскільки доказ приховує суму, злодій може просто заявити, що його виходи коштують більше, ніж входи, і надрукувати собі безплатні гроші». Використовуючи Розділ 5, поясніть у двох реченнях, чому це не спрацює. (Відповідь нижче.)
Суми приховані, але кожна з них загорнута в гомоморфний value commitment, і мережа додає всі commitments входів та віднімає всі commitments виходів; якби приховані значення не збалансовувалися, результат не запечатувався б у нуль і жоден коректний binding signature неможливо було б створити. Злодій може приховати скільки саме, але не може змусити незбалансовані значення пройти перевірку балансу, тож надрукувати собі безплатні гроші неможливо — нічого не розкриваючи, але все одно будучи спійманим арифметикою.
Тепер ви пройшли шлях від одного парадоксу до повноцінного приватного платежу:
Звідси природна наступна дуга йде глибше: внутрішня будова Groth16 і Halo 2, церемонії trusted setup, деталі схем Sapling і Orchard, виведення ключів і диверсифіковані адреси, а також еволюція протоколу через мережеві оновлення. Але фундамент уже закладено, і кожна з цих тем тепер має до чого прикріпитися.
Частина серії Zcash from First Principles для ZecHub. Ліцензія CC BY-SA 4.0.