Холодне підписання захищених транзакцій
Ключова ідея: Супутній гаманець бачить усе необхідне для створення та моніторингу захищеної транзакції. Лише апаратний гаманець має повноваження авторизувати витрату коштів. Саме в цьому полягає суть холодного підписання захищених транзакцій.
Захист у Zcash передбачає переміщення коштів із публічної, прозорої адреси на приватну, захищену адресу, приховуючи деталі транзакції за допомогою функцій конфіденційності Zcash.
Що змінюється, коли ви захищаєте ZEC?
У прозорій транзакції Zcash така інформація, як:
- адреса відправника
- адреса отримувача
- переказана сума
може бути видимою в блокчейні.
Коли ви захищаєте ZEC, ваші кошти переміщуються до приватного пулу (наприклад, Ironwood). Блокчейн може перевірити дійсність транзакції, не розкриваючи її приватних деталей. Після оновлення NU6.3 28 липня 2026 року нові захищені кошти надходять до пулу Ironwood, оскільки старіший пул Orchard більше не приймає нові депозити, але все ще дозволяє виведення коштів.
Компоненти захищеної транзакції
1. Нотатка (запис захищеного балансу)
Нотатка — це приватний криптографічний запис, що представляє невитрачену суму ZEC, яка належить користувачеві.
На відміну від публічного блокчейну, де баланси зазначені у відкритому вигляді, захищена нотатка шифрує дані про вартість і власника, щоб спостерігачі в блокчейні не могли побачити, кому належать кошти.
Під час ініціювання транзакції супутній гаманець сканує реєстр, визначає невитрачені нотатки користувача та обирає, які з них витратити.
2. Нуліфікатор (механізм виявлення подвійного витрачання)
Оскільки деталі нотатки приховані від публічного реєстру, мережі потрібен механізм для виявлення подвійного витрачання без розкриття того, яка саме нотатка витрачається.
Нуліфікатор — це унікальний криптографічний маркер, похідний від конкретної нотатки. Коли нотатка витрачається, її нуліфікатор публікується в блокчейні.
Мережа перевіряє, чи не було нуліфікатор записано раніше. Якщо ні, витрату можна прийняти. Важливо, що зовнішній спостерігач не може використати нуліфікатор, щоб визначити, з якої конкретно нотатки він походить.
Супутній гаманець виводить і створює відповідний нуліфікатор у межах підготовки даних транзакції.
Ключі
Ключі — це криптографічні елементи інформації, що контролюють доступ до ваших коштів і дозволяють вашому гаманцю виконувати такі операції, як отримання, перегляд і витрачання ZEC.
Гаманець зберігає кілька різних ключів, кожен із яких має своє призначення, подібно до того, як один обліковий запис може мати окремі облікові дані для доступу на читання та запис.
Ключі мають центральне значення для взаємодії супутнього гаманця й апаратного гаманця, оскільки різні ключі виконують різні функції, і лише один із них має залишатися надійно ізольованим.
Важливо знати, що кожен захищений пул будує свої ключі як дерево виведення, де стрілки вказують від компонента до того, що з нього можна вивести. Користувачі, які хочуть отримувати захищені платежі, повинні мати захищену платіжну адресу, що генерується з ключа витрачання.
Ієрархія ключів
1. Ключ витрачання
Це ключ, найбільш критичний для безпеки. Він надає криптографічну можливість авторизувати витрачання ZEC.
Саме цей ключ мається на увазі щоразу, коли далі в цьому звіті згадується, що «апаратний гаманець зберігає ключ».
В архітектурі холодного підписання ключ витрачання зберігається всередині апаратного гаманця й ніколи не розкривається супутньому гаманцю. Супутній гаманець узагалі не повинен володіти цим ключем.
Як у Sapling, так і в Orchard ієрархії ключів виводять повноваження на витрачання та можливості перегляду як дві окремі гілки з кореневого ключа витрачання:
- Sapling: Розширений ключ витрачання (𝑎𝑠𝑘,𝑛𝑠𝑘,𝑜𝑣𝑘) виводить ключі авторизації доказів (𝑎𝑘,𝑛𝑠𝑘) і повні ключі перегляду (𝑎𝑘,𝑛𝑘,𝑜𝑣𝑘), які далі утворюють вхідні ключі перегляду (𝑖𝑣𝑘) і диверсифіковані адреси.
- Orchard: Кореневий ключ витрачання (𝑠𝑘) безпосередньо розгалужується на ключ авторизації витрачання (𝑎𝑠𝑘) і повний ключ перегляду (𝑎𝑘,𝑛𝑘,𝑟𝑖𝑣𝑘).
Цей структурний поділ забезпечує формальну криптографічну основу для ізоляції апаратного ключа: гаманець експортує гілку перегляду (UFVK) на головний комп’ютер для синхронізації балансу та створення транзакцій, водночас назавжди зберігаючи гілку авторизації витрачання заблокованою на пристрої.
Виведення ключів є суворо односпрямованим. Це означає, що ключі перегляду неможливо обернути для відновлення повноважень на витрачання. Криптографічна необоротність робить безпечним експорт Unified Full Viewing Key (UFVK), оскільки він надає повну видимість гаманця без розкриття секретів витрачання на пристрої.
2. Ключі перегляду
Zcash відокремлює можливість бачити захищену активність від можливості її витрачати. Ключ перегляду дозволяє гаманцю або іншій уповноваженій стороні переглядати інформацію про захищені транзакції без надання повноважень на витрачання.
- Full Viewing Key (FVK), оформлений як Unified Full Viewing Key (UFVK): навмисно виводиться з ключа витрачання, він дозволяє програмному забезпеченню виявляти та розшифровувати захищену активність гаманця, таким чином ідентифікуючи транзакції. Він також дозволяє обчислювати баланси без можливості авторизувати витрату. Його найкраще описувати як менш приватний похідний ключ витрачання, а не як слабшу копію seed-фрази.
Full Viewing Key (FVK) забезпечує повну видимість лише для читання, зберігаючи суворе розділення безпеки. Розшифровуючи шифротексти як вхідних, так і вихідних нотаток (через свій компонент ключа перегляду вихідних даних), супутній гаманець лише з FVK може відображати повну, позначену історію транзакцій, а не лише поточний баланс.
Кілька невзаємопов’язаних диверсифікованих платіжних адрес використовують той самий FVK і вхідний ключ перегляду (IVK), що дозволяє необмежено генерувати адреси без збільшення накладних витрат на сканування блокчейну.
Це функціональне розділення становить основу робочих процесів холодного підписання. Усе безперервне сканування ланцюга, відстеження історії та керування адресами передається програмному забезпеченню головного пристрою, тоді як повноваження на витрачання залишаються ізольованими на апаратному пристрої.
Критична відмінність: UFVK проти ключа витрачання
UFVK можна передавати. Ключ витрачання повинен залишатися на апаратному гаманці.
Супутній гаманець використовує ключ перегляду для моніторингу гаманця, виявлення вхідних коштів, ідентифікації нотаток і допомоги в підготовці транзакцій. Він не має приватного ключа, необхідного для авторизації витрачання.
Як було зазначено раніше, розділення ключів є основою архітектури холодного підписання.
Супутній гаманець може виконувати більшу частину роботи, необхідної для підготовки транзакції, ніколи не отримуючи контролю над коштами. Апаратному гаманцю потрібно лише отримати підготовлену транзакцію та виконати остаточну операцію підписання.
Виробникам апаратних гаманців не потрібно самостійно винаходити це розділення. Конструкція ключів Zcash уже розділяє можливості перегляду та повноваження на витрачання на рівні протоколу, а виробники просто створюють свої функції підписання й експорту поверх цієї наявної структури. Протокол дозволяє виводити з ключа витрачання інформацію, таку як захищена адреса або повний ключ перегляду, водночас сам ключ витрачання залишається приватним, що дає змогу апаратним гаманцям, таким як Ledger, Keystone і Hito, надавати супутньому програмному забезпеченню необхідну інформацію для перегляду, ніколи не розкриваючи приватний ключ, який може витрачати кошти.
Що насправді робить супутній гаманець з інформацією про ключі
Використовуючи матеріал ключа перегляду, супутній гаманець може:
- ідентифікувати ваші кошти та нотатки
- визначати, які нотатки можна витратити
- виводити або ідентифікувати відповідні адреси
- створювати транзакцію
- генерувати або координувати необхідні докази
- готувати транзакцію до підписання
Важливо знати, що необхідність створити транзакцію не означає необхідності мати приватний ключ витрачання. Це розділення є однією з основних ідей безпеки інтеграції апаратного гаманця.
Створення та авторизація захищеної транзакції
Це процеси, залучені до створення й авторизації транзакції. Простими словами, саме ці процеси визначають, що гаманець фактично робить із цими даними, щоб надіслати гроші:
Створення транзакції (складання захищеної транзакції)
Створення транзакції — це процес складання інформації, необхідної для створення дійсної транзакції Zcash, на основі запланованого платежу користувача.
Процес створення транзакції об’єднує вибрані нотатки, отримувачів, суми, комісії, нуліфікатори та інші необхідні дані транзакції в її структуру. Для захищених транзакцій він також готує інформацію, необхідну для генерування потрібних доказів з нульовим розголошенням і підписів.
Зазвичай цей етап виконує супутній гаманець. Він
- Обирає нотатки для витрачання
- Визначає входи та виходи транзакції
- Обчислює необхідні значення
- Готує дані транзакції, які пізніше буде доведено та підписано.
У налаштуванні холодного підписання отримані дані транзакції можна запакувати в PCZT і передати до апаратного гаманця для критичного з погляду безпеки етапу підписання.
Доведення (демонстрація дійсності протоколу)
Доведення означає генерування доказів з нульовим розголошенням (таких як Halo 2 або Groth16), які демонструють, що транзакція дотримується правил протоколу Zcash.
Доказ допомагає мережі гарантувати:
- Користувач, який витрачає кошти, уповноважений витрачати нотатки
- Нотатки справді існують
- Відповідні нуліфікатори є унікальними
- Сума всіх входів дорівнює сумі всіх виходів плюс комісії.
Усе це відбувається без розкриття будь-яких базових приватних деталей.
Генерування доказів потребує значних обчислювальних ресурсів. Передача цієї відповідальності супутньому пристрою запобігає зависанню апаратного гаманця або нестачі пам’яті.
Підписання (авторизація витрачання)
Підписання принципово відрізняється від доведення. Цифровий підпис діє як явна позначка авторизації, створена власником приватного ключа.
Тоді як доказ з нульовим розголошенням підтверджує дійсність транзакції, цифровий підпис доводить повноваження на витрачання. Підпис засвідчує, що справжній власник схвалює конкретні параметри переказу.
Підписання потребує мінімальної обчислювальної потужності, що робить його ідеальним для апаратного гаманця.
Що таке холодне підписання захищених транзакцій?
Холодне підписання захищених транзакцій — це метод авторизації захищеної транзакції Zcash зі збереженням приватних ключів витрачання ізольованими від підключеного до інтернету супутнього гаманця. Транзакцію можна створити та підготувати на онлайн-комп’ютері, тоді як окремий апаратний гаманець, що зберігається офлайн або іншим чином ізольований, використовує свої захищені ключі для авторизації транзакції.
Процес можна спростити так:
Супутній гаманець надсилає структуровані параметри транзакції на апаратний пристрій, який підписує корисне навантаження внутрішньо, ніколи не передаючи приватний ключ витрачання головній машині.
Супутні та апаратні гаманці
Захищені транзакції можуть використовувати як супутній гаманець, так і апаратний гаманець, кожен із яких виконує окрему функцію.
Супутній гаманець
Що таке супутній гаманець?
Супутній гаманець працює на комп’ютері або мобільному пристрої та виконує більшість завдань, пов’язаних зі створенням транзакції, зокрема:
- Вибір нотаток для витрачання
- Створення транзакції
- Обчислення необхідних даних транзакції
- Координування генерування необхідних доказів з нульовим розголошенням.
Чому супутній гаманець корисний?
Супутній гаманець обробляє процес створення транзакції, але якщо комп’ютер буде заражено шкідливим програмним забезпеченням, зловмисник може:
- бачити, що ви робите,
- змінити непідписану транзакцію,
- спробувати обманом змусити вас щось схвалити.
Супутній гаманець не потребує доступу до приватного ключа, що зберігається на апаратному гаманці, тому він може виконувати створення транзакцій та інші обчислювальні завдання, тоді як апаратний гаманець забезпечує межу безпеки для приватного ключа.
Апаратний гаманець
Апаратний гаманець — це офлайн-фізичний пристрій, який ізолює ваші приватні ключі від підключених телефонів або комп’ютерів, діючи як захищене сховище для ваших криптоактивів.
Чому апаратний гаманець корисний?
Якщо комп’ютер буде заражено шкідливим програмним забезпеченням, зловмисник може:
- бачити, що ви робите,
- змінити непідписану транзакцію,
- спробувати обманом змусити вас щось схвалити.
Приватний ключ не можна просто витягти з апаратного гаманця, тому пристрій може діяти як межа безпеки.
Зображення: можливості супутнього та апаратного гаманців
Розділення між цими двома гаманцями особливо важливе для захищених транзакцій, оскільки вони складніші за прозорі транзакції та включають такі компоненти, як захищені нотатки, нуліфікатори, зобов’язання, докази з нульовим розголошенням і підписи транзакцій.
Апаратному гаманцю було б непрактично виконувати кожну обчислювальну операцію. Натомість супутній гаманець готує транзакцію та надає апаратному гаманцю необхідну інформацію для підписання, тоді як приватний ключ витрачання залишається ізольованим всередині апаратного пристрою.
Ізоляція ключів
Ізоляція ключів означає, що приватні ключі, здатні авторизувати витрату коштів, ніколи не залишають апаратний гаманець. Супутня програма може підготувати транзакцію; підписати її вона не може.
Ізоляція ключів означає зберігання приватних ключів, необхідних для авторизації транзакції, окремо від супутнього гаманця та пристрою, на якому він працює. У конфігурації екранованого холодного підписання супутній гаманець може формувати транзакцію та координувати необхідні докази, тоді як апаратний гаманець зберігає чутливі приватні ключі витрачання ізольованими.
Якщо супутній комп’ютер або телефон скомпрометовано, зловмисник може отримати можливість взаємодіяти з транзакцією до її підписання, але в ідеалі не може вилучити приватний ключ з апаратного гаманця. Отже, ключ залишається в межах безпеки апаратного пристрою.
Це розділення дозволяє супутньому гаманцю виконувати формування транзакцій та обчислювальні завдання, не надаючи йому прямого доступу до матеріалу ключів, потрібного для авторизації транзакції.
Ключова відмінність полягає в тому, що «ключ перегляду» не означає, що застосунок отримує слабшу версію seed-фрази.
У Zcash Full Viewing Key (FVK/UFVK) навмисно виводиться з ключа витрачання та надає власникові можливість виявляти й розшифровувати релевантну екрановану активність, але не авторизувати витрати. FVK є менш секретним похідним ключа витрачання.
Одне важливе застереження щодо приватності:
Отже, слід розуміти, що застосунок не може викрасти кошти, маючи лише UFVK, але він може бачити приватну екрановану активність гаманця.
Саме тому точніше описувати супутній застосунок як такий, що має повноваження перегляду, а не просто казати, що він має «публічну інформацію».
Найпростіше сформулювати всю ідею так: супутній гаманець отримує достатньо матеріалу ключів, щоб знати, що відбувається з гаманцем, але недостатньо матеріалу ключів, щоб авторизувати те, що відбувається з коштами гаманця. Водночас апаратний гаманець зберігає повноваження витрачання ізольованими та використовує їх лише тоді, коли користувач схвалює транзакцію.
Це базова модель ізоляції ключів, що лежить в основі цих екранованих конструкцій апаратних гаманців Zcash, і це та сама модель, яка в різних реалізаціях проявляється в Ledger, Keystone та Hito, які будуть розглянуті незабаром.
PCZT
PCZT означає частково створену транзакцію Zcash. Це пакет, який переносить транзакцію Zcash та інформацію, необхідну для її завершення під час переходу від одного етапу до іншого.
Це стандартизований формат для транзакції Zcash, поки транзакція ще формується. Він дозволяє різним учасникам або пристроям виконувати різні частини процесу створення транзакції та передавати між собою частково завершену транзакцію.
Формування транзакції є значно складнішим за підписання простого публічного переказу в криптовалютних протоколах з нульовим розголошенням, таких як Zcash. Екрановані транзакції потребують обчислювально інтенсивних доказів з нульовим розголошенням, наприклад створених за допомогою Halo 2 або Groth16. Унаслідок цього малопотужні пристрої, такі як апаратні гаманці, можуть не мати пам’яті та обчислювальної потужності для обробки всього процесу транзакції.
Запровадження PCZT вирішує кілька ключових проблем архітектури екранованих криптовалют. PCZT — це стандартизований проміжний формат даних, який розділяє створення транзакції на модульні незалежні ролі. Він дозволяє потужному супутньому комп’ютеру виконувати складання транзакції та генерування доказів, водночас суворо обмежуючи офлайн-апаратний гаманець авторизацією та підписанням.
Обмеження апаратного забезпечення та холодного зберігання
Хоча апаратні гаманці забезпечують безпечне середовище для захисту приватних ключів витрачання, вони зазвичай мають обмежені RAM, обчислювальну потужність і можливості передавання даних порівняно із супутніми комп’ютерами. Ці обмеження роблять непрактичним генерування ними обчислювально інтенсивних доказів з нульовим розголошенням або підтримання повного стану транзакції, потрібного під час процесу її формування.
Унаслідок цього супутній гаманець може виконувати обчислювально складні завдання, тоді як апаратний гаманець зосереджується на критично важливій для безпеки операції авторизації транзакції за допомогою захищених ключів витрачання.
Це змушує замислитися: якщо пристрій настільки обмежений, як він усе ж виконує достатньо перевірок, щоб заслуговувати на довіру?
Простіше кажучи, апаратний гаманець не може прийняти довільне значення від супутнього комп’ютера та підписати його. Йому потрібна достатня інформація, щоб встановити, що значення, яке підписується, відповідає транзакції, яку користувач має намір авторизувати. Це створює складний баланс, оскільки пристрій повинен виконувати достатньо аналізу та перевірок для захисту процесу підписання, працюючи водночас у суворих межах пам’яті, обчислень, розміру прошивки та складності реалізації.
Обробка Orchard PCZT у Ledger є прикладом цієї проблеми: вона свідчить, що спеціалізований аналіз, залежний від схеми, може зробити реалізацію більш керованою на обмежених пристроях, але також може потребувати змін прошивки, коли підтримувані структури транзакцій або схеми еволюціонують.
Дві поточні ініціативи ілюструють різні відповіді на це саме обмеження.
У Grant #423 було висунуто дослідницьку пропозицію щодо повністю константного за часом конвеєра генерування доказів, придатного для архітектур апаратних гаманців з відкритим кодом і звичайних комп’ютерів. Її метою було дослідити криптографічну інфраструктуру, яку можна безпечно реалізувати в середовищах на кшталт C або Rust, водночас зменшуючи складність і тягар підтримки екранованої підтримки Zcash.
Альтернативний підхід представлено запропонованим Zcash SeedSigner — підписувачем з відкритим кодом і повітряним зазором, зібраним із недорогих легкодоступних компонентів. Його запропонований робочий процес тримає супутній комп’ютер окремо від пристрою підписання, передаючи PCZT через повітряний зазор для перевірки та підписання на пристрої.
https://forum.zcashcommunity.com/t/grant-application-research-on-a-fully-constant-time-proving-pipeline-for-open-source-hardware-wallet-architectures-reusable-for-standard-computers/57555
Разом ці підходи ілюструють ширшу інженерну проблему екранованих апаратних гаманців: формування транзакцій і генерування доказів можуть відбуватися поза критично важливим для безпеки пристроєм, але підписувач усе одно повинен мати достатньо інформації та можливостей перевірки, щоб безпечно авторизувати отриману транзакцію.
PCZT уможливлює розділену архітектуру
Стандарт частково створеної транзакції Zcash (PCZT) є формальною структурою даних, яка з’єднує супутній гаманець та апаратний гаманець.
Супутній гаманець може самостійно виконати вибір нот, обчислити nullifier-и та згенерувати доказ з нульовим розголошенням. Це можливо, оскільки інформація, потрібна для цих кроків, включно з ключем, який використовується для виведення nullifier-ів, походить із ключа перегляду, а не з будь-чого, пов’язаного з повноваженнями витрачання. Потім супутній гаманець пакує ці елементи в контейнер PCZT.
PCZT передається апаратному гаманцю, який зчитує контекст транзакції (наприклад суми й адреси отримувачів), застосовує підпис за допомогою своїх захищених ключів витрачання та передає оновлений PCZT назад супутньому пристрою.
Ця конструкція встановлює сувору межу безпеки: потужне апаратне забезпечення хоста може виконувати складну математику нульового розголошення без доступу до ключів витрачання, тоді як малопотужні пристрої холодного зберігання можуть забезпечувати фінансову безпеку без потреби обчислювати важку криптографію.
Компроміси приватності доказувача
Хоча делегування генерування доказів з нульовим розголошенням супутньому гаманцю або іншому доказувачу зберігає ключі витрачання ізольованими, воно все одно вимагає від доказувача доступу до чутливої інформації про транзакцію, такої як значення нот, адреси отримувачів і зобов’язання.
PCZT підтримує архітектурне розділення, гарантуючи, що цю інформацію можна надати для генерування доказу без передавання приватних ключів витрачання, потрібних для авторизації.
Це гарантує, що повноваження генерування доказів відокремлено від повноважень витрачання. Доказувач може виконувати обчислювально інтенсивне генерування доказів, не отримуючи криптографічних повноважень витрачати кошти користувача.
Сумісність PCZT
Оскільки PCZT стає важливою частиною робочих процесів апаратних гаманців, мультипідпису та підписання з повітряним зазором Zcash, сумісність між незалежними реалізаціями набуває дедалі більшого значення.
Пропозиція AngryDavee від червня 2026 року зазначала, що реалізації PCZT вже існували в проєктах, зокрема Ledger, Keystone, Hito, OneKey, а також у еталонній реалізації в librustzcash. Однак пропозиція виявила відсутність спільних тестів для підтвердження того, що ці реалізації однаково інтерпретують PCZT.
Запропонованим рішенням був набір тестів сумісності з відкритим кодом, що містить канонічні тестові вектори PCZT та міжреалізаційні тести, які охоплюють повний процес create → sign → finalize. Також пропонувалося тестувати межі ролей, наприклад Combiner, де частково підписана інформація від різних підписувачів може об’єднуватися до фіналізації транзакції.
Це особливо важливо для апаратних гаманців, оскільки PCZT дозволяє відокремити формування транзакції від підписання: супутній гаманець може сформувати транзакцію та підготувати PCZT, тоді як апаратний пристрій отримує потрібну інформацію для підписання та виконує критично важливу для безпеки операцію підписання.
Пропозицію не було реалізовано, оскільки Zcash Community Grants вирішила не продовжувати грант після розгляду пропозиції та врахування відгуків спільноти. Унаслідок цього запропонований набір міжреалізаційних тестів не було розроблено в межах цього гранту. Отже, це запропонована відповідь на виявлену проблему сумісності PCZT, а не стандарт, який наразі існує для всіх Zcash.
https://forum.zcashcommunity.com/t/pczt-interoperability-test-suite-feedback-before-at-grant-submission/55931
Життєвий цикл PCZT
| # | Етап | Опис |
|---|
| 1 | Creator | Ініціалізує PCZT глобальними метаданими транзакції, включно з версіями транзакцій, ідентифікаторами гілок консенсусу та прапорцями пулів. |
| 2 | Constructor | Наповнює транзакцію запланованими входами та виходами в прозорих, Sapling, Orchard або Ironwood пулах. |
| 3 | IO Finalizer | Оголошує набір входів і виходів завершеним, обчислює ключі підпису прив’язки та підписує фіктивні витрати там, де це потрібно. |
| 4 | Updater | Додає необхідні контекстні дані для наступних учасників, наприклад повні ключі перегляду, якорі та свідчення Merkle. |
| 5 | Prover and Signer | Виконує генерування доказів з нульовим розголошенням і криптографічне підписання. У сучасних версіях PCZT ці два завдання повністю незалежні й можуть виконуватися послідовно або паралельно. |
| 6 | Combiner | Детерміновано об’єднує кілька екземплярів PCZT, якщо різні пристрої одночасно працюють над аспектами однієї транзакції. Правила об’єднання вимагають суворого розв’язання конфліктів, щоб запобігти випадковій втраті даних. |
| 7 | Spend Finalizer & Extractor | Перевіряє всі потрібні криптографічні елементи, вилучає проміжні контекстні метадані та створює фіналізовану транзакцію Zcash, готову до трансляції в мережу. |
Реальні реалізації апаратних гаманців
Коротко
| Пристрій | Що отримує супутня програма | Що залишається на пристрої | Передавання |
|---|
| Ledger | UFVK / Orchard FVK, адреси | Повноваження витрачання | USB / BLE |
| Keystone | UFVK + Unified Address | Seed-фраза / ключі витрачання | QR (повітряний зазор) |
| Hito | UFVK, Unified Address, відбиток seed-фрази | Seed-фраза та приватні ключі витрачання | QR / локально |
Було розроблено кілька реалізацій апаратних гаманців, щоб дослідити, як можна підтримувати екрановані транзакції Zcash, зберігаючи чутливі ключі витрачання ізольованими від супутнього гаманця. Ledger, Keystone та Hito представляють різні підходи до інтеграції апаратного захисту ключів із робочим процесом транзакцій Zcash.
Щоб зрозуміти, як вони захищають екрановані кошти, важливо розрізняти ключі витрачання та ключі перегляду. У всіх трьох розділення має однакову форму:
| Пристрій | Що може отримати супутній застосунок | Що лишається захищеним на пристрої |
|---|
| Ledger | UFVK / Orchard FVK, адреси та публічна інформація | Повноваження витрачання / матеріал приватних ключів |
| Keystone | UFVK + Unified Address | Seed-фраза / ключі витрачання |
| Hito | UFVK, Unified Address, відбиток seed-фрази та інформація про мережу | Seed-фраза та приватні ключі витрачання |
Ledger як апаратне середовище підписання
Ledger — компанія, що виробляє апаратні гаманці. Її пристрої побудовані навколо Secure Element — спеціалізованого чипа, призначеного для зберігання матеріалу приватних ключів і його фізичної ізоляції від решти пристрою та всього, що до нього підключено. Саме Secure Element є головною причиною, чому пристрою Ledger можна довіряти для холодного зберігання. Це означає, що навіть якщо підключений до нього комп’ютер або телефон скомпрометовано, ключі всередині Secure Element неможливо вилучити.
Сам по собі пристрій Ledger не налаштований на жодну конкретну криптовалюту. На ньому має бути встановлений застосунок, який знає, як працювати з особливою криптографією цієї валюти.
Пристрій Ledger не налаштований на жодну конкретну криптовалюту, тому йому потрібен застосунок, який знає криптографію цієї валюти. Для Zcash існувало два покоління:
- Початковий застосунок «Zcash Shielded», створений Zondax, який використовувався із супутніми гаманцями, такими як Zkool, та буде відкликаний 5 листопада 2026 року, і
- новіший застосунок Zcash від Ledger (3.9.4+), який нативно використовується Ledger Wallet Desktop 4.21+ для екранованих ZEC Ironwood.
Описана нижче модель ізоляції ключів застосовується до обох.
Zkool — це супутній гаманець на вашому телефоні або комп’ютері, який взаємодіє з цим застосунком. Він формує транзакцію, надсилає її до Ledger, застосунок Zondax на пристрої підписує її та надсилає підпис назад.
Отже, Zondax — це програмне забезпечення, що працює на апаратному пристрої, а Zkool — це програмне забезпечення, що працює поза ним і використовує застосунок Zondax для взаємодії з пристроєм.
Що залишає Ledger?
Програмне забезпечення Zcash від Ledger включає спеціальну функцію для експорту ключа перегляду гаманця — ключа, який дозволяє програмному забезпеченню бачити баланси й транзакції без можливості щось витрачати.
Ця функція може повертати один із двох об’єктів:
- Unified Full Viewing Key (UFVK), тобто повний ключ перегляду, який одночасно охоплює всі екрановані пули Zcash, або
- Orchard Full Viewing Key (FVK)
У будь-якому разі назовні виходить лише ключ перегляду. Незалежно від того, яку версію ви запитуєте, ця функція не може повернути єдину інформацію, яка фактично дозволила б комусь перемістити кошти, — ключ витрачання.
У цьому й полягає суть її конструкції: вона створена так, щоб єдиним, що вона може експортувати, було щось безпечне для передавання супутньому застосунку.
Ієрархія ключів Zcash структурована так, що для кожного екранованого пулу ключ витрачання виводить дві окремі величини:
- ключ авторизації витрачання, та
- повний ключ перегляду
Потім FVK може виводити власні додаткові можливості, пов’язані з переглядом, але цей шлях виведення ніколи не веде назад до повноважень витрачання. Щойно ключ переходить до гілки перегляду ієрархії, він там і залишається та не може бути використаний для відновлення ключа повноважень витрачання, з якого він походить.
Ironwood дотримується того самого шаблону, оскільки повторно використовує базову конструкцію ключів і нот Orchard. Однак на рівні консенсусу це окремий пул із власним деревом зобов’язань та набором nullifier-ів. Це означає, що UFVK насправді є набором ключів перегляду для кожного пулу (прозорого, Sapling, Orchard, а тепер і Ironwood), а не одним пласким ключем.
UFVK, експортований до активації Ironwood, не міститиме ключа перегляду Ironwood, оскільки цього пулу тоді ще не існувало. Саме тому гаманцям потрібно було оновитися, щоб розпізнавати й виводити UFVK із підтримкою Ironwood після оновлення NU6.3.
Що залишається на Ledger?
Повноваження витрачання залишаються на пристрої.
Signer Ledger отримує транзакцію/PCZT від хоста й створює підпис авторизації витрачання залежно від того, з якого пулу витрачаються кошти в транзакції (пул Ironwood, оскільки поточна інтеграція Ledger підтримує лише Ironwood). Потім підпис створюється на пристрої, а хост отримує лише підпис, а не приватний ключ витрачання.
Це також узгоджується з загальною моделлю безпеки Ledger. Його Secure Element ізолює матеріал приватних ключів, а вимоги безпеки застосунків Ledger прямо забороняють застосункам розкривати ці секрети хосту.
Підписувач Ledger може експортувати FVK/UFVK, водночас незалежно виконуючи підписання транзакцій. Ці дві можливості надаються окремими функціями, а не об’єднані в одну.
Що це означає на практиці?
Припустімо, ваш Ledger містить 10 ZEC.
Супутній гаманець може мати UFVK і тому визначити: «Цей гаманець отримав 10 ZEC». Він може сканувати та відображати транзакції й баланси.
Але якщо хтось скомпрометує супутній гаманець, сам по собі UFVK не надасть йому можливості створити підпис авторизації витрачання.
Призначення окремого підпису авторизації витрачання полягає в тому, щоб дозволити обмеженим пристроям, таким як апаратні гаманці, авторизувати екрановані витрати без потреби самостійно виконувати повний доказ zk-SNARK.
Застосунок Zondax Ledger; сторона апаратного гаманця
Що таке Zondax?
Zondax — це стороння компанія-розробник, яка створила застосунок Ledger Zcash. Це фактичний застосунок прошивки, який працює на обладнанні Ledger і надає пристрою здатність розуміти та обробляти транзакції Zcash.
Zondax — зовнішній розробник. Апаратне забезпечення Ledger не має вбудованої здатності обробляти транзакції Zcash, і ця можливість цілком походить із програмного забезпечення Zondax.
Початкова реалізація Zcash Ledger
Репозиторій застосунку Ledger Zcash від Zondax містить програмне забезпечення, яке працює на пристрої Ledger. Застосунок спочатку був зосереджений на екранованих транзакціях Sapling, до того як Orchard став основним екранованим пулом Zcash, тому підтримка Sapling була повним обсягом того, що пристрій Ledger міг робити з екранованими ZEC.
Його архітектура ілюструє розділення: сторона хоста/супутнього пристрою готує інформацію про транзакцію, тоді як Ledger обробляє чутливі операції з ключами та підписання.
Навіть у цій найпершій версії підтримки апаратного гаманця Zcash базові принципи — формування та генерування доказів на хості, а потім ізольоване підписання на пристрої — уже були закладені в конструкцію.
Еволюція до Orchard
Робота Ledger рухалася в напрямку Orchard + PCZT. Це був суттєвий перехід, а не незначне оновлення, зважаючи на те, що Orchard використовує іншу систему генерування доказів (Halo 2 замість Groth16 у Sapling) та іншу конструкцію нот і ключів, тому розширення прошивки лише для Sapling для обробки підписання Orchard потребувало нового криптографічного підґрунтя на стороні пристрою, а не просто виправлення прошивки.
Однак, коли Zcash рухався в напрямку Ironwood, Zondax та Ledger змістили фокус своєї розробки на безпосередню підтримку Ironwood, а не на завершення реалізації Orchard, яку потім довелося б переробляти для Ironwood. Це являє собою подальший етап еволюції реалізації Ledger, оскільки Ironwood розвиває криптографічну архітектуру Orchard, водночас запроваджуючи окремий екранований пул і додаткові зміни протоколу.
Що відбувається всередині цього застосунку Ledger
Отриманий процес описується так:
- Хост формує PCZT.
- Хост надсилає релевантну інформацію про транзакцію на пристрій Ledger.
- Пристрій створює підписи авторизації витрачання Orchard.
- Хост обробляє все, що йде після цього, включно з підписом прив’язки та фінальним складанням транзакції.
Застосунок, що працює всередині Ledger, ніколи не бачить і не створює нічого, крім самого підпису авторизації витрачання, а вся обчислювально важка або вимоглива до даних робота (генерування доказів, прив’язка, складання) залишається на хості, якому не потрібно довіряти матеріал ключів.
Нативна екранована інтеграція Ledger; Ledger Wallet Desktop
Найновіша інтеграція Zcash від Ledger надає конкретний приклад того, як формування екранованої транзакції та критично важливе для безпеки підписання можуть бути розділені між супутнім програмним забезпеченням та апаратним гаманцем.
За допомогою Ledger Wallet Desktop 4.21+ і застосунку пристрою Zcash 3.9.4+ користувачі можуть надсилати та отримувати екрановані ZEC Ironwood безпосередньо через Ledger Wallet Desktop. Інтеграція підтримує приватні перекази між приватними адресами, екранування з прозорого пулу, деекранування до прозорого пулу, приватні адреси отримання та пам’ятки. Транзакції перевіряються й підписуються на пристрої Ledger, а не покладаються лише на інформацію, показану комп’ютером.
Ключовою частиною цієї архітектури є розділення можливостей перегляду та витрачання. Під час синхронізації приватного балансу Ledger експортує Unified Full Viewing Key (UFVK), який зберігається локально на комп’ютері. UFVK дозволяє Ledger Wallet Desktop виявляти релевантні екрановані транзакції та визначати баланс гаманця, але не надає повноважень витрачати кошти. Критично важливі для безпеки повноваження витрачання залишаються на пристрої Ledger, який виконує остаточну операцію підписання. Це створює чітку межу між комп’ютером, який керує станом гаманця та формує транзакції, і апаратним пристроєм, який захищає можливість, потрібну для авторизації витрачання.
Однак поточна інтеграція призначена лише для Ironwood. Вона не відображає та не керує коштами Orchard або Sapling через Ledger Wallet Desktop. Історично це суттєво, оскільки попередня розробка Zcash від Ledger була пов’язана з підтримкою екранованого Orchard до того, як реалізація еволюціонувала до протоколу Ironwood.
Цей перехід також підкреслює важливість сумісності ключів і облікових записів. Ledger має старіший застосунок «Zcash Shielded», розроблений Zondax та використаний інтеграціями на кшталт YWallet і zkool, який зараз виводять з експлуатації. Оскільки цей старіший застосунок використовував іншу схему виведення для екранованих облікових записів, його облікові записи Sapling не можна просто відтворити новим застосунком Ledger.
Таким чином, інтеграція ілюструє як прогрес, так і наявні обмеження підтримки екранованих апаратних гаманців. Ledger тепер може забезпечувати повний досвід Ironwood, у якому супутнє програмне забезпечення виконує синхронізацію гаманця та підготовку транзакцій, тоді як апаратний пристрій залишається межею безпеки для витрачання.
Водночас сумісність історичних облікових записів, підтримка лише певних екранованих пулів, обмеження розміру апаратних транзакцій, обмеження платформ, а також обчислювальні обмеження та обмеження прошивки, пов’язані з аналізом і перевіркою екранованих транзакцій, показують, що підтримка апаратних гаманців для Zcash залежить не лише від можливостей протоколу, а й від конструкції та ресурсів кожної окремої реалізації.
Zkool + Ledger — використання офіційного застосунку Zondax
Як наступник Ywallet, Zkool успадкував мету екранованого холодного підписання, але обрав інший шлях її досягнення — шлях, безпосередньо сформований тим фактом, що сама криптографія не робить інтеграцію придатною до використання, якщо застосунок підписання неможливо безпечно поширювати.
https://youtu.be/eagkCIv3BlQ?si=7w5YfLlRER77bASw
Використання Zondax застосунку Zkool
Zkool перейшов до використання офіційного застосунку Ledger Zcash, розробленого Zondax, замість покинутого пропрієтарного застосунку Ledger від Ywallet. Замість підтримки власного застосунку, який магазин Ledger не приймав, Zkool спирався на застосунок, уже прийнятий і поширюваний через власну екосистему Ledger.
Ця зміна означала, що користувачам більше не потрібно було покладатися на встановлення непідписаного власного застосунку Ledger для використання цієї інтеграції, оскільки застосунок Zondax офіційно поширювався через екосистему Ledger.
Однак ця інтеграція зазнає важливої зміни 5 листопада 2026 року, коли підтримка застарілого застосунку Zcash Shielded має завершитися, оскільки Ledger поступово відмовляється від нього. Оскільки інтеграція Ledger від Zkool покладається на цей застосунок, ця зміна порушує питання про майбутню доступність наявного з’єднання. Точний вплив на Zkool залежить від того, чи зможе він і надалі використовувати застарілий застосунок поза Ledger Wallet, або перейти на сумісну альтернативу.
Підтримувані екрановані пули
За словами розробника Ywallet, інтеграція Ledger від Zkool використовувала офіційний застосунок Ledger, розроблений Zondax, та підтримувала як прозорі, так і екрановані Zcash. Однак її екранована підтримка обмежувалася Sapling і не підтримувала Orchard, разом з іншими обмеженнями інтеграції, такими як максимум п’ять входів і виходів кожного типу та відсутність сумісності з Ledger Live.
Це обмеження відображало охоплення базової реалізації Zondax Ledger на той час. Раніша робота Zondax над Ledger забезпечила підтримку Sapling, а наступний випуск у 2024 році застосунку Zcash Shielded Ledger спочатку не включав Orchard та Unified Addresses. Тому інтеграція, побудована навколо цього застосунку, успадкувала можливості й обмеження реалізації апаратного гаманця, від якої вона залежала.
Ситуація згодом змінилася з випуском спеціалізованого застосунку Zcash Shielded Ledger у листопаді 2024 року. Zondax заявила, що застосунок було офіційно випущено через Ledger Live, а пізніше опублікувала рекомендації щодо інтеграції та пакети Rust і JavaScript, щоб інші гаманці могли інтегруватися з ним. Однак на момент запуску застосунок взаємодіяв виключно з Zecwallet Lite Desktop, тоді як ширші інтеграції з гаманцями все ще розроблялися.
Наступним етапом стала розробка нового застосунку Ledger на основі Rust Zcash. Станом на червень 2026 року Ledger повідомила, що обмін UFVK і створення Orchard Unified Address було реалізовано, тоді як підписання транзакцій Orchard і ClearSign все ще перебували в розробці. Ledger також заявила, що ця робота продовжиться у напрямку Ironwood у міру змін протоколу.
Ironwood згодом вимагав оновлень у всій екосистемі гаманців Zcash. Zkool додала підтримку міграції з Orchard до Ironwood, починаючи з версії 6.24.0, і продовжила вдосконалювати міграцію та конвеєр транзакцій у наступних випусках. Ledger окремо об’єднала підписання PCZT v2 у своєму новому застосунку 27 липня, хоча реалізація ще не завершила перевірку Ledger та розгортання через Ledger Live до 20 серпня — етап, який відтоді було випущено, і Ledger Wallet Desktop 4.21+ тепер безпосередньо пропонує нативну підтримку Ironwood.
https://forum.zcashcommunity.com/t/a-path-forward-for-ledger-and-zcash/50951/177
Отже, цю еволюцію краще розуміти не як єдине оновлення від Zondax до Ironwood, а як кілька пов’язаних розробок: початкову реалізацію Sapling, зосереджену на Zondax, застосунок Zcash Shielded Ledger 2024 року, новий застосунок Ledger Rust із підтримкою Orchard та PCZT, власну нативну інтеграцію Ledger у Ledger Wallet Desktop і паралельні оновлення гаманців, таких як Zkool, у міру переходу екосистеми до Ironwood.
Поточна підтримка пристроїв і платформ Ledger для Zcash
Підтримка Zcash на Ledger залежить від
- Моделі пристрою
- Встановленого застосунку
- Платформи, що використовується для керування ним, і
- Від того, чи є транзакція прозорою або shielded.
Станом на 21 липня 2026 року (останнє оновлення Ledger) застосунок Zcash Shielded підтримується на Nano S Plus, Stax і Flex, але ще не на Nano X або Nano Gen5.
Nano X та інші моделі, окрім оригінального Nano S, усе ще можуть використовувати класичний застосунок Zcash, який підтримує прозорі транзакції та витрачання shielded коштів на прозорі адреси (deshielding), але не підписання shielded-до-shielded. Оригінальний Nano S не підтримує жоден із застосунків, оскільки Ledger поступово припиняє підтримку пристрою, а його найновіший застосунок Zcash недоступний на ньому. Пристрої підключаються до Ledger Wallet (раніше Ledger Live), супутнього застосунку Ledger, доступного на настільних системах для Windows, macOS і Linux, а також на мобільних пристроях для iOS і Android.
Ledger додала нативну shielded Zcash до Ledger Wallet Desktop, побудованого на пулі Ironwood, що усуває потребу в окремому супутньому гаманці. Shielded ZEC ще не підтримується у мобільному застосунку Ledger для iOS і Android, хоча підтримка мобільних пристроїв запланована в майбутньому випуску.
Поза власним програмним забезпеченням Ledger shielded-використання залежить від сумісного супутнього гаманця та підтримуваних ним платформ. Оскільки Ledger продовжує розширювати підтримку Ironwood, сумісність залежить від моделі пристрою, прошивки, версії застосунку й операційної системи, тому загальна підтримка Zcash не обов’язково гарантує сумісність.
https://www.youtube.com/watch?v=VhkhfG0LCFs
Холодне підписання YWallet; ранній підхід
Ywallet — це супутній гаманець, окремий від Ledger та Zondax, який ішов власним шляхом до shielded холодного підписання.
Ywallet має історичне значення, оскільки досліджував холодне підписання для Zcash, тобто пристрій підписання можна було тримати окремо від онлайн-гаманця.
Щоб реалізувати цю архітектуру на апаратному забезпеченні Ledger, Ywallet створила власний застосунок Ledger — пропрієтарний застосунок, відмінний від застосунку Zondax, описаного в попередньому розділі. Це означало, що Ywallet не покладалася на наявну реалізацію Zondax Sapling; вона мала власну прошивку, що виконувала роль підписання у цьому зв’язку.
Чому інтеграція мала значення
Наявності криптографічного коду та коду підписання недостатньо. Інтеграція апаратного гаманця — це не суто криптографічна проблема, а й неминуча проблема поширення та платформи. Щонайменше вона охоплює:
- Схвалення/поширення застосунку — чи прийме та поширюватиме застосунок офіційний магазин застосунків виробника апаратного забезпечення
- Безпеку прошивки/застосунку — чи відповідає застосунок вимогам виробника щодо безпеки роботи з ключовим матеріалом
- Протоколи зв’язку — як супутній гаманець і пристрій фактично обмінюються даними транзакцій
- Сумісність із гаманцем — чи відповідають формати даних і потік застосунку підписання тому, чого очікує супутній гаманець
- Підтримувані shielded пули — для яких із Sapling, Orchard (і тепер Ironwood) застосунок фактично може підписувати
Пропрієтарний застосунок Ywallet Ledger задовольняв криптографічні та архітектурні вимоги; він міг підписувати shielded транзакції Zcash, але його не прийняли до офіційного магазину застосунків Ledger.
Перехід від пропрієтарного застосунку Ledger
Оскільки застосунок не був офіційно прийнятий, Ywallet довелося б просити користувачів установити непідписану прошивку, щоб ним скористатися; це є реальним компромісом безпеки для користувачів, і Ywallet вирішила не просити їх про це. Тому Ywallet зрештою відмовилася від цієї конкретної інтеграції, а не пішла цим шляхом.
Замість відновлення пропрієтарного застосунку пізніша розробка (через Zkool, наступника Ywallet) натомість перейшла до офіційного застосунку Zondax, створеного Ledger, замінивши власну відхилену реалізацію стандартизованою, уже прийнятою в екосистему поширення Ledger. Саме цей зсув зрештою знову уможливив робочу інтеграцію Ledger.
Спадщина Ywallet
Навіть після того, як сама Ywallet відійшла від активної розробки, її творець Hanh, який також є учасником ZCG, залишався помітним голосом в екосистемі, особливо коли міграція Ironwood виявила повідомлені проблеми щодо коштів, які, здавалося, зникли.
ZODL: реальний користувач зіткнувся з відсутніми коштами після міграції Orchard → Ironwood
Користувач Jmo0615 повідомив, що кошти, раніше видимі в його гаманці ZODL, більше не відображалися після міграції з Orchard до Ironwood. Він заявив, що відновив оригінальну seed-фразу, скинув і відновив гаманець, а також дозволив ZODL версії 3.14.1 (1) повністю синхронізуватися. Він також підтвердив, що апаратний гаманець Keystone не був залучений.
Не встановлено, що кошти справді були втрачені. Натомість підозрюється проблема, пов’язана з виявленням гаманцем або міграцією, коли раніше видимі кошти перестали відображатися після переходу на Ironwood. Кошти, які не виявляються або не відображаються, не слід автоматично описувати як кошти, втрачені назавжди, і це розрізнення важливе для розуміння проблем міграції.
https://forum.zcashcommunity.com/t/funds-not-showing-since-ironwood/57792
Zkool: «заблоковані нотатки» можуть пояснити кошти, які здаються недоступними
Ще один важливий аспект shielded гаманців полягає в тому, як стан гаманця може впливати на кошти, які користувач фактично може витратити. Hanh пояснив, що користувач може випадково заблокувати нотатку через контроль монет — функцію, яка дозволяє вручну обирати, які нотатки використовуються для витрачання. У такій ситуації нотатка може все ще існувати в гаманці, але бути позначеною як недоступна для витрачання.
Це підкреслює важливе розрізнення під час розслідування проблем із гаманцем. Обсяг ZEC, що існує в гаманці, не завжди дорівнює сумі, доступній для витрачання в цей момент. На відображуваний або доступний для витрачання баланс можуть впливати такі чинники, як вибір нотаток, синхронізація, стан міграції, відновлення гаманця та налаштування контролю монет. Тому повідомлення про «відсутні кошти» слід ретельно розрізняти між коштами, які не виявлено або не відображено, коштами, які виявлено, але вони недоступні для витрачання, та коштами, які справді втрачені.
https://youtube.com/shorts/eAOMRVYJFTA?si=xytBs-wZKn8hmu8D
2. Keystone
Що таке Keystone?
Keystone — це апаратний гаманець з повітряним зазором. Його пристрій підписання не має прямого дротового або бездротового з’єднання із супутнім застосунком під час самого процесу підписання, натомість він взаємодіє через QR-коди. Тут він поєднаний з Zashi (тепер перейменованим на Zodl), нативним супутнім гаманцем Zcash, і це поєднання робить принцип ізоляції ключів особливо явним та легким для відстеження.
Потік Keystone/Zashi
Інтеграція Keystone Zcash з Zashi робить це розділення особливо явним. Коли ви підключаєте Keystone до Zashi, Unified Full Viewing Key передається з Keystone до Zashi.
Отже, потік такий:
Що Zashi може робити з UFVK?
Zashi може використовувати його, щоб:
- виявляти вхідні shielded транзакції
- визначати баланси
- отримувати інформацію про shielded активність
Але він не може витратити кошти лише тому, що має UFVK.
UFVK — це «можливість перегляду», яка дозволяє дізнаватися баланси й транзакції, але не дозволяє витрачати кошти.
Що залишається всередині Keystone?
Seed-фраза/повноваження на витрачання залишаються на Keystone. Zashi не отримує seed-фразу, ключ витрачання чи приватний ключ авторизації витрачання. Він отримує UFVK, інформацію про адресу та інформацію, необхідну для режиму лише перегляду.
Разом ці дві частини завершують картину. Те, що залишає пристрій, наприклад UFVK, адреси та інформація лише для перегляду, є достатнім для Zashi, щоб відстежувати обліковий запис, але ніщо, що залишає пристрій, не є достатнім для виведення з нього коштів.
Ось чому інтеграція Zashi та Keystone може забезпечити shielded холодне зберігання. Застосунок гаманця може відстежувати обліковий запис, не маючи повноважень, необхідних для витрачання з нього. Інтеграцію було спеціально запущено, щоб уможливити холодне зберігання shielded ZEC.
Коли ви хочете витратити кошти:
3. Hito
Hito дотримується дуже подібної моделі ізоляції ключів до Keystone, але його реалізація новіша. Замість поєднання з наявним супутнім гаманцем, таким як Zashi, Hito постачається з власним гаманцем Android, а процес початкового налаштування між апаратним пристроєм і цим застосунком Android задокументовано в етапах розробки Hito.
Початкове налаштування: що отримує застосунок Hito
Гаманець Android використовує:
- Unified Full Viewing Key (UFVK)
- Unified Address
- Відбиток seed-фрази ZIP-32
- Інформацію про мережу
під час початкового налаштування апаратного облікового запису.
Зауважте, що застосунок Android ніколи не отримує seed-фразу апаратного гаманця чи приватні ключі витрачання.
Що отримує застосунок Hito?
Документована інформація початкового налаштування включає:
- UFVK
- Unified Address
- Відбиток seed-фрази ZIP-32
- Мережу
UFVK надає гаманцю Android інформацію, необхідну для роботи з обліковим записом як гаманцю з можливістю перегляду, без отримання seed-фрази. Відбиток seed-фрази — це ідентифікатор фіксованої довжини, похідний від seed-фрази, який використовується для розпізнавання відповідного облікового запису; це не сама seed-фраза й він не надає жодної можливості витрачання, тому його наявність не суперечить наведеному вище твердженню «ніколи не отримує seed-фразу».
Що залишається на Hito?
Фактична seed-фраза, приватні ключі витрачання та повноваження підписання залишаються на апаратному пристрої. Потім Hito виконує підписання офлайн.
Поточний етап Hito стверджує, що весь робочий процес створення, експорту, офлайн-підписання й імпорту працює, використовуючи BLE-транспорт і експорт BBQr QR підписаного PCZT.
Цей робочий процес варто назвати прямо, оскільки він є конкретним прикладом повного циклу, розглянутого раніше в цьому звіті: гаманець Android створює непідписаний PCZT, експортує його до Hito, Hito підписує його офлайн своїм ізольованим ключовим матеріалом, а підписаний PCZT імпортується назад до гаманця Android.
Ні в який момент seed-фраза або ключ витрачання не перетинає цю межу в жодному напрямку.
Orchard до Ironwood: Еволюція підтримки апаратних гаманців
Orchard — це захищений пул у протоколі Zcash, який дає користувачам змогу зберігати та здійснювати транзакції з ZEC із підвищеною конфіденційністю. Запроваджений у Network Upgrade 5 (NU5), Orchard використовує систему доведення Halo 2 і перероблену криптографічну архітектуру для підтримки захищених транзакцій без розкриття чутливої інформації про транзакцію, такої як відправник, одержувач або сума.
Ironwood — це захищений пул, запроваджений у мережевому оновленні Zcash NU6.3 як наступник пулу Orchard. Він використовує криптографічний протокол Orchard, водночас упроваджуючи зміни, покликані поліпшити довгострокову безпеку захищених коштів, зокрема можливість відновлення після квантової атаки та сильніші гарантії цілісності емісії.
На початку важливо уточнити, що Ironwood не замінив протокол Orchard цілком новою криптографічною системою. Ironwood було запроваджено як новий захищений пул, побудований на основі наявного протоколу Orchard. Це означає, що вони мають однакову структуру Action, ту саму систему доведення Halo 2, ті самі конструкції нот і ключів.
Ironwood має власне дерево зобов’язань нот, набір nullifier, anchor і пул вартості, тож на рівні консенсусу це справді окремий пул. Але криптографічно це розширення Orchard, а не перебудова.
Його було спроєктовано так, щоб:
- Цілісність емісії. 29 травня 2026 року дослідник безпеки Taylor Hornby приватно розкрив критичну ваду коректності в системі доказів нульового розголошення Orchard, яка могла дозволити створювати підроблені ZEC без сліду в блокчейні. Оскільки дані транзакцій Orchard є приватними, ніхто не може незалежно перевірити, що до виправлення не було створено підроблених ZEC. Закриття старого пулу та запуск нового з нульового значення вирішує цю проблему способом, який неможливо було б застосувати, виправивши Orchard на місці.
- Забезпечити можливість відновлення після квантової атаки. Ironwood було спроєктовано так, щоб його кошти могли брати участь у майбутньому механізмі відновлення, якщо базові припущення щодо дискретного логарифма коли-небудь буде зламано.
- Мінімізувати зміни реалізації. Замість проєктування цілком нового захищеного протоколу було повторно використано перевірену архітектуру Orchard. Це означало, що потрібно було написати з нуля значно менше нового коду для транзакцій, доказів, гаманців і апаратних гаманців.
Публічна хронологія
- 29 травня: розкрито вразливість Orchard.
- Червень: транзакції Orchard тимчасово обмежено, поки початкове виправлення надходить через NU6.2. 12 червня основний розробник визначає 21 липня як цільову дату повного оновлення; згодом її переносять на тиждень. У спільноті висловили занепокоєння, що власники Keystone мігруватимуть останніми; тоді основний розробник відповів, що Keystone підтримуватиме Ironwood з першого дня, а випуск мікропрограми заплановано на 3 липня за умови завершення констант підписання та змін API Orchard від ядра Zcash.
- Початок липня: NU6.3 досягає testnet; Zebra 6.0.0 виходить 10 липня.
- 27–28 липня: роботу з підписання Ledger Ironwood PCZT v2 зливають до інтеграційної гілки. Ironwood (NU6.3) активується 28 липня на блоці 3,428,143, закриваючи початковий пул Orchard за турнікетом, який обмежує обсяг ZEC, що може покинути Orchard, сумою, яка була законно внесена до нього, і запроваджує новий формат транзакцій.
Zebra стає обов’язковим вузлом, оскільки zcashd не підтримує нові правила консенсусу. Адреси не змінюються, адже Ironwood повторно використовує структуру одержувача Orchard, тому гаманці автоматично спрямовують наявні адреси до нового пулу. Однак гаманцям потрібна функціональність міграції, оскільки кошти Orchard зрештою мають бути переміщені їхніми власниками до Ironwood, а нові виходи, які отримують Orchard, тепер повністю заблоковані консенсусом.
Що змінилося технічно
Формати транзакцій перейшли з версії 5 на версію 6, тому одна транзакція може містити компонент Ironwood поряд із наявними компонентами Sapling/Orchard/прозорими. PCZT було відповідно розширено:
- Кодування перейшло з PCZT v1 на v2.
- Окремий пакет Ironwood тепер розташований поряд із пакетами Sapling та Orchard.
- Підтримуються транзакції v6 і новий sighash v6.
- Відкриті тексти нот отримали нову версію (V3).
Зміна sighash має найбільше значення саме для апаратних гаманців. У v6 anchors Orchard та Ironwood виключено з хешу підпису, і вони надходять лише до дайджесту авторизаційних даних. Це справжня зміна мікропрограми, а не просто підвищення версії. Пристрій має правильно реалізувати новий sighash і самостійно його перераховувати, а не довіряти тому, що супутня програма стверджує, ніби він схвалює.
Сам контракт ізоляції не змінився: пристрій, як і раніше, повертає лише підпис авторизації витрати, ніколи не повертає alpha і ніколи не створює binding signature; вузол так само обробляє створення доказів і все інше.
Проте з v6 змінилося одне правило для підписувача: фіктивні витрати для заповнення підписуються IO Finalizer, а не пристроєм, оскільки пристрій не має способу перевірити їх за реальними даними нот. Роль Signer пристрою пропускає їх замість того, щоб його просили підписати щось, що він не може перевірити. Відображувані комісії тепер також сумують баланси вартості Orchard та Ironwood, оскільки транзакція v6 може витрачати з обох пулів в одній транзакції.
Правильний облік пулів важливий на практиці, а не лише в теорії. Корисною ілюстрацією є нещодавня помилка у власному гаманці Brave Zcash: його розрахунок комісії припускав, що всі захищені входи належали застарілому пулу Orchard, що призводило до дублювання дій і неправильних оцінок комісії, коли транзакція насправді стосувалася Ironwood. Саме такий клас помилок покликаний виявляти принцип «перераховуй самостійно, не довіряй вузлу», що лежить в основі підписання апаратним гаманцем. Супутній гаманець неправильно врахував пул, і лише пристрій, який незалежно перевіряє власні обчислення, виявив би це до схвалення підпису.
Стан кожного підписувача
Ledger щойно повністю змінив ситуацію. 23 вересня 2026 року Ledger випустив нативну підтримку захищених Zcash безпосередньо в Ledger Wallet Desktop — окрема супутня програма більше не потрібна. Ваш ключ витрати залишається на пристрої, комп’ютер виконує обчислення транзакції, а ви схвалюєте все на екрані перед підписанням. Підтримується лише Ironwood, а не старі пули Orchard чи Sapling. Недолік у тому, що застаріла програма «Zcash Shielded», створена Zondax, яка для роботи вимагала супутнього гаманця на кшталт Zkool, припиняє підтримуватися. Ledger вилучає цю старішу програму з доступу 5 листопада, тож кожному, хто досі нею користується, потрібно перемістити кошти до того часу.
Keystone перебуває в хорошому стані. Мікропрограма 3.0.2 ще в липні додала повну підтримку Ironwood, і це досі актуальна стабільна вимога. Однак для підписання будь-чого потрібна саме ця або новіша версія.
Hito просунувся далі за початковий етап testnet. Він успішно підписав і надіслав свою першу справжню транзакцію Orchard-до-Ironwood на фізичному обладнанні (спочатку в testnet). Подальші оновлення підтвердили потоки mainnet (Ironwood→Ironwood, Ironwood→Transparent та інші) на виробничому обладнанні. Розробка стабільної мікропрограми та ширшого випуску триває.
Zondax та Zkool наразі перебувають у перехідному стані. Програма Zondax — це та, що припиняє підтримуватися на Ledger. Zkool, який покладався на цю програму для взаємодії з пристроями Ledger, не повідомив, що станеться з цією роллю, коли стара програма зникне. Незрозуміло, чи залишиться він актуальним для користувачів Ledger надалі, чи його майбутнє переважно пов’язане з іншими пристроями.
Сама міграція є найбільшим наслідком. Оскільки сума, що переходить між пулами, є публічною, гаманці розподіляють перекази між стандартними номіналами з часом, а не переміщують баланс одним видимим блоком, що означає багато транзакцій для підписання під час міграції і саме тому пакетне підписання PCZT було настільки важливим для апаратних гаманців.
Робота над мікропрограмою Ledger також зіткнулася з апаратними обмеженнями: реальна витрата ноти могла сягати десятків тисяч криптографічних системних викликів в одній команді, запускаючи watchdog пристрою. Виправлення перенесло арифметику полів до програмного забезпечення та вимагало спільного робочого стану, щоб уміститися в обмеження стека Nano X.
https://forum.zcashcommunity.com/t/ironwood-is-here-updated-wallets-libraries-aug-20/56557/40
Еволюція в одному зображенні
