Холодная подпись защищённых транзакций
Ключевая идея: Сопутствующий кошелёк видит всё необходимое для создания и отслеживания защищённой транзакции. Только аппаратный кошелёк обладает полномочиями для авторизации траты. Именно в этом заключается смысл холодной подписи защищённых транзакций.
Экранирование в 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 означает Partially Created Zcash Transaction. Это пакет, который переносит транзакцию Zcash и информацию, необходимую для её завершения при переходе с одного этапа на другой.
Это стандартизированный формат для транзакции Zcash, пока она ещё создаётся. Он позволяет разным участникам или устройствам выполнять различные части процесса создания транзакции и передавать между ними частично завершённую транзакцию.
Формирование транзакции значительно сложнее, чем подписание простого публичного перевода в криптовалютных протоколах с нулевым разглашением, таких как Zcash. Защищённые транзакции требуют вычислительно интенсивных доказательств с нулевым разглашением, таких как создаваемые с использованием Halo 2 или Groth16. В результате маломощные устройства, такие как аппаратные кошельки, могут не обладать памятью и вычислительной мощностью для обработки всего рабочего процесса транзакции.
Введение PCZT решает несколько ключевых проблем архитектуры защищённых криптовалют. PCZT — это стандартизированный промежуточный формат данных, разбивающий создание транзакции на модульные, независимые роли. Он позволяет мощному сопутствующему компьютеру выполнять сборку транзакции и генерацию доказательств, ограничивая офлайн-аппаратный кошелёк строго авторизацией и подписью.
Ограничения аппаратных кошельков и холодного хранения
Хотя аппаратные кошельки предоставляют защищённую среду для хранения приватных ключей траты, они обычно имеют ограниченные объём RAM, вычислительную мощность и возможности передачи данных по сравнению с сопутствующими компьютерами. Эти ограничения делают непрактичным выполнение ими вычислительно интенсивной генерации доказательств с нулевым разглашением или поддержание полного состояния транзакции, требуемого в ходе процесса её формирования.
В результате сопутствующий кошелёк может выполнять вычислительно сложные задачи, тогда как аппаратный кошелёк остаётся сосредоточенным на критической для безопасности операции авторизации транзакции своими защищёнными ключами траты.
Это заставляет задуматься: если устройство настолько ограничено, как оно всё же выполняет достаточную проверку, чтобы быть заслуживающим доверия?
Проще говоря, аппаратный кошелёк не может принять произвольное значение от сопутствующего компьютера и подписать его. Ему нужна достаточная информация, чтобы установить, что подписываемое значение соответствует транзакции, которую пользователь намерен авторизовать. Это создаёт сложный баланс, поскольку устройство должно выполнять достаточно разбора и проверки для защиты процесса подписи, работая в строгих ограничениях памяти, вычислений, размера прошивки и сложности реализации.
Обработка Ledger Orchard PCZT является примером этой задачи: специализированный, зависящий от схемы разбор может сделать реализацию более управляемой на устройствах с ограниченными ресурсами, но также может потребовать изменений прошивки при развитии поддерживаемых структур транзакций или схем.
Два текущих направления демонстрируют разные ответы на это ограничение.
Исследовательское предложение о полностью конвейере доказательств с постоянным временем, подходящем для аппаратных кошельков с открытым исходным кодом и обычных компьютеров, было выдвинуто в гранте №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 обеспечивает разделённую архитектуру
Стандарт Partially Created Zcash Transaction (PCZT) является формальной структурой данных, соединяющей сопутствующий кошелёк и аппаратный кошелёк.
Сопутствующий кошелёк способен самостоятельно выбирать записи, вычислять нуллификаторы и генерировать доказательство с нулевым разглашением. Это возможно, поскольку информация, необходимая для этих шагов, включая ключ, используемый для вывода нуллификаторов, поступает из ключа просмотра, а не из чего-либо, связанного с полномочиями траты. Затем сопутствующий кошелёк упаковывает эти элементы в контейнер PCZT.
PCZT передаётся аппаратному кошельку, который считывает контекст транзакции (например, суммы и адреса получателей), применяет подпись, используя свои защищённые ключи траты, и возвращает обновлённый PCZT сопутствующему устройству.
Эта конструкция устанавливает строгую границу безопасности: мощное оборудование хоста может выполнять сложную математику нулевого разглашения без доступа к ключам траты, тогда как маломощные устройства холодного хранения могут обеспечивать финансовую безопасность без необходимости вычислять тяжёлую криптографию.
Компромиссы конфиденциальности доказывающего участника
Хотя делегирование генерации доказательства с нулевым разглашением сопутствующему кошельку или другому доказывающему участнику сохраняет ключи траты изолированными, оно всё же требует от доказывающего участника доступа к чувствительной информации транзакции, такой как значения записей, адреса получателей и обязательства.
PCZT сохраняет архитектурное разделение, гарантируя, что эта информация может быть предоставлена для доказательства без передачи приватных ключей траты, необходимых для авторизации.
Это гарантирует разделение полномочий доказательства и полномочий траты. Доказывающий участник может выполнять вычислительно интенсивную генерацию доказательств, не получая криптографических полномочий тратить средства пользователя.
Взаимодействие PCZT
Поскольку PCZT становится важной частью рабочих процессов аппаратных кошельков, мультиподписи и подписи с воздушным зазором Zcash, взаимодействие между независимыми реализациями приобретает всё большее значение.
В предложении от июня 2026 года AngryDavee отмечалось, что реализации 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 | Создатель | Инициализирует PCZT глобальными метаданными транзакции, включая версии транзакции, идентификаторы ветвей консенсуса и флаги пулов. |
| 2 | Конструктор | Заполняет транзакцию предполагаемыми входами и выходами в прозрачном, Sapling, Orchard или Ironwood пулах. |
| 3 | Финализатор ввода-вывода | Объявляет набор входов и выходов завершённым, вычисляет ключи связывающей подписи и подписывает фиктивные траты там, где это необходимо. |
| 4 | Обновляющий участник | Добавляет необходимые контекстные данные для последующих участников, такие как полные ключи просмотра, якоря и свидетели Меркла. |
| 5 | Доказывающий участник и подписант | Выполняет генерацию доказательств с нулевым разглашением и криптографическую подпись. В современных версиях PCZT эти две задачи полностью независимы и могут происходить последовательно или параллельно. |
| 6 | Объединитель | Детерминированно объединяет несколько экземпляров PCZT, если разные устройства одновременно работают над аспектами одной транзакции. Правила объединения требуют строгого разрешения конфликтов, чтобы предотвратить случайную потерю данных. |
| 7 | Финализатор траты и извлекатель | Проверяет все необходимые криптографические элементы, удаляет промежуточные контекстные метаданные и создаёт завершённую транзакцию 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?
Программное обеспечение Ledger Zcash включает специальную функцию для экспорта ключа просмотра кошелька — ключа, который позволяет программному обеспечению видеть балансы и транзакции, не позволяя тратить что-либо.
Эта функция может вернуть одну из двух вещей:
- Unified Full Viewing Key (UFVK), полный ключ просмотра, одновременно охватывающий все защищённые пулы Zcash, или
- Orchard Full Viewing Key (FVK)
В любом случае наружу выходит только ключ просмотра. Какую бы версию вы ни запросили, эта функция никак не может вернуть единственный элемент информации, который действительно позволил бы кому-то переместить средства, — ключ траты.
Именно в этом смысл её конструкции: она спроектирована так, что единственное, что она способна экспортировать, — это нечто безопасное для передачи сопутствующему приложению.
Иерархия ключей Zcash структурирована так, что для каждого защищённого пула ключ траты выводит две отдельные вещи:
- Ключ авторизации траты и
- Полный ключ просмотра
Затем FVK может выводить дополнительные возможности, связанные с просмотром, но ни в один момент этот путь вывода не возвращается к полномочиям траты. Как только ключ переходит в ветвь просмотра иерархии, он остаётся там и не может использоваться для восстановления исходного ключа полномочий траты.
Ironwood следует тому же шаблону, поскольку повторно использует базовую конструкцию ключей и записей Orchard. Однако на уровне консенсуса это отдельный пул со своим деревом обязательств и набором нуллификаторов. Это означает, что UFVK в действительности является набором ключей просмотра для каждого пула (прозрачного, Sapling, Orchard и теперь Ironwood), а не одним плоским ключом.
UFVK, экспортированный до активации Ironwood, не будет включать ключ просмотра Ironwood, поскольку такого пула тогда ещё не существовало. Именно поэтому кошелькам пришлось обновиться, чтобы распознавать и выводить UFVK с поддержкой Ironwood после обновления NU6.3.
Что остаётся на Ledger?
Полномочия траты остаются на устройстве.
Подписант 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
Репозиторий приложения Zondax Ledger Zcash — это программное обеспечение, работающее на устройстве 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
Последняя интеграция Ledger Zcash предоставляет конкретный пример того, как формирование защищённой транзакции и критическая для безопасности подпись могут быть разделены между сопутствующим программным обеспечением и аппаратным кошельком.
С Ledger Wallet Desktop 4.21+ и приложением устройства Zcash 3.9.4+ пользователи могут отправлять и получать экранированные Ironwood ZEC непосредственно через Ledger Wallet Desktop. Интеграция поддерживает приватные переводы между защищёнными адресами, экранирование из прозрачного пула, деэкранирование в прозрачный пул, приватные адреса получения и заметки. Транзакции проверяются и подписываются на устройстве Ledger, а не полагаются исключительно на информацию, представленную компьютером.
Ключевая часть этой архитектуры — разделение возможностей просмотра и траты. Во время синхронизации приватного баланса Ledger экспортирует Unified Full Viewing Key (UFVK), который хранится локально на компьютере. UFVK позволяет Ledger Wallet Desktop обнаруживать релевантные защищённые транзакции и определять баланс кошелька, но не предоставляет полномочий тратить средства. Критические для безопасности полномочия траты остаются на устройстве Ledger, выполняющем окончательную операцию подписи. Это создаёт чёткую границу между компьютером, который управляет состоянием кошелька и формирует транзакции, и аппаратным устройством, которое защищает возможность, необходимую для авторизации траты.
Однако текущая интеграция предназначена только для Ironwood. Она не отображает и не управляет средствами Orchard или Sapling через Ledger Wallet Desktop. Исторически это существенно, потому что ранняя разработка Ledger Zcash была связана с поддержкой защищённых Orchard до того, как реализация развилась в сторону протокола Ironwood.
Переход также подчёркивает важность совместимости ключей и учётных записей. У Ledger есть старое приложение «Zcash Shielded», разработанное Zondax и используемое такими интеграциями, как YWallet и zkool, которое сейчас выводится из эксплуатации. Поскольку это старое приложение использовало другую схему вывода для защищённых учётных записей, его учётные записи Sapling нельзя просто воспроизвести новым приложением Ledger.
Таким образом, интеграция иллюстрирует как прогресс, так и сохраняющиеся ограничения поддержки защищённых аппаратных кошельков. Теперь Ledger может предоставить полный опыт Ironwood, в котором сопутствующее программное обеспечение занимается синхронизацией кошелька и подготовкой транзакций, тогда как аппаратное устройство остаётся границей безопасности для траты.
В то же время историческая совместимость учётных записей, поддержка только определённых защищённых пулов, ограничения размера аппаратных транзакций, ограничения платформ, а также вычислительные ограничения и ограничения прошивки, связанные с разбором и проверкой защищённых транзакций, показывают, что поддержка аппаратных кошельков для Zcash зависит не только от возможностей протокола, но и от конструкции и ресурсов каждой отдельной реализации.
Zkool + Ledger — использование официального приложения Zondax
Будучи преемником Ywallet, Zkool унаследовал цель холодной подписи защищённых транзакций, но выбрал иной путь её достижения, сформированный непосредственно тем фактом, что одной криптографии недостаточно для удобства интеграции, если приложение подписи нельзя безопасно распространить.
https://youtu.be/eagkCIv3BlQ?si=7w5YfLlRER77bASw
Использование Zkool приложения Zondax
Zkool перешёл к использованию официального приложения Ledger Zcash, разработанного Zondax, вместо заброшенного проприетарного приложения Ywallet Ledger. Вместо поддержки пользовательского приложения, которое магазин Ledger не принял бы, Zkool опирался на приложение, уже принятое и распространяемое через собственную экосистему Ledger.
Этот переход означал, что пользователям больше не нужно было полагаться на установку неподписанного пользовательского приложения Ledger для использования этой интеграции, поскольку приложение Zondax официально распространялось через экосистему Ledger.
Однако эта интеграция сталкивается с важным изменением 5 ноября 2026 года, когда поддержка устаревшего приложения Zcash Shielded должна закончиться, поскольку Ledger выводит его из эксплуатации. Поскольку интеграция Zkool Ledger зависит от этого приложения, это изменение поднимает вопросы о будущей доступности существующего подключения. Точное влияние на Zkool зависит от того, сможет ли он продолжать использовать устаревшее приложение вне Ledger Wallet или перейдёт на совместимую альтернативу.
Поддерживаемые защищённые пулы
По словам разработчика Ywallet, интеграция Zkool Ledger использовала официальное приложение Ledger, разработанное Zondax, и поддерживала как прозрачные, так и защищённые Zcash. Однако её защищённая поддержка была ограничена Sapling и не поддерживала Orchard, наряду с другими ограничениями интеграции, такими как максимум пять входов и выходов каждого типа и отсутствие совместимости с Ledger Live.
Это ограничение отражало область действия базовой реализации Zondax Ledger на тот момент. Ранняя работа Zondax Ledger обеспечивала поддержку Sapling, а последующий выпуск в 2024 году приложения Zcash Shielded Ledger изначально исключал Orchard и Unified Addresses. Поэтому интеграция, построенная вокруг этого приложения, наследовала возможности и ограничения реализации аппаратного кошелька, от которой зависела.
Ситуация впоследствии изменилась с выпуском специализированного приложения Zcash Shielded Ledger App в ноябре 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 App 2024 года, более новое приложение Ledger Rust с поддержкой Orchard и PCZT, собственную нативную интеграцию Ledger в Ledger Wallet Desktop и параллельные обновления кошельков, таких как Zkool, по мере перехода экосистемы к Ironwood.
Текущая поддержка устройств и платформ Ledger для Zcash
Поддержка Zcash на Ledger зависит от
- Модели устройства
- Установленного приложения
- Платформы, используемой для управления им, и
- От того, является ли транзакция прозрачной или защищённой.
По состоянию на 21 июля 2026 года (последнее обновление Ledger) приложение Zcash Shielded поддерживается на Nano S Plus, Stax и Flex, но пока не поддерживается на Nano X или Nano Gen5.
Nano X и другие модели, кроме исходного Nano S, всё ещё могут использовать классическое приложение Zcash, поддерживающее прозрачные транзакции и трату защищённых средств на прозрачные адреса (деэкранирование), но не подпись защищённых переводов между защищёнными адресами. Исходный Nano S не поддерживает ни одно приложение, поскольку Ledger прекращает поддержку устройства, а его последнее приложение Zcash на нём недоступно. Устройства подключаются к Ledger Wallet (ранее Ledger Live), сопутствующему приложению Ledger, доступному на компьютерах для Windows, macOS и Linux, а также на мобильных устройствах для iOS и Android.
Ledger добавил нативные защищённые Zcash в Ledger Wallet Desktop, построенные на пуле Ironwood, что устраняет необходимость в отдельном сопутствующем кошельке. Защищённые ZEC пока не поддерживаются в мобильном приложении Ledger для iOS и Android, хотя мобильная поддержка запланирована в будущем выпуске.
Вне собственного программного обеспечения Ledger защищённое использование зависит от совместимого сопутствующего кошелька и поддерживаемых им платформ. Поскольку Ledger продолжает расширять поддержку Ironwood, совместимость зависит от модели устройства, прошивки, версии приложения и операционной системы, поэтому общая поддержка Zcash не обязательно гарантирует совместимость.
https://www.youtube.com/watch?v=VhkhfG0LCFs
Холодная подпись YWallet; ранний подход
Ywallet — сопутствующий кошелёк, отдельный как от Ledger, так и от Zondax, который шёл собственным путём к холодной подписи защищённых транзакций.
Ywallet важен исторически, поскольку изучал холодную подпись для Zcash, то есть устройство подписи могло оставаться отдельным от онлайн-кошелька.
Чтобы реализовать такую архитектуру на оборудовании Ledger, Ywallet создал собственное приложение Ledger — проприетарное приложение, отличное от приложения Zondax, рассмотренного в предыдущем разделе. Это означало, что Ywallet не полагался на существующую реализацию Zondax Sapling; у него была собственная прошивка, выполняющая сторону подписи этих отношений.
Почему интеграция была важна
Наличия криптографии и кода подписи недостаточно. Интеграция аппаратного кошелька — не только криптографическая проблема, но и неизбежная проблема распространения и платформы. Как минимум, она включает:
- Одобрение/распространение приложения — примет ли официальный магазин приложений производителя аппаратного устройства и будет ли распространять приложение
- Безопасность прошивки/приложения — соответствует ли приложение требованиям производителя к безопасности при обработке ключевого материала
- Протоколы связи — как сопутствующий кошелёк и устройство фактически обмениваются данными транзакции
- Совместимость с кошельком — соответствуют ли форматы данных и поток приложения подписи ожиданиям сопутствующего кошелька
- Поддерживаемые защищённые пулы — для каких из Sapling, Orchard (и теперь Ironwood) приложение действительно может подписывать
Проприетарное приложение Ywallet Ledger удовлетворяло криптографическим и архитектурным требованиям; оно могло подписывать защищённые транзакции 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: «заблокированные записи» могут объяснить кажущуюся недоступность средств
Ещё один важный аспект защищённых кошельков заключается в том, как состояние кошелька может влиять на средства, которые пользователь действительно может потратить. 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 может использовать его для:
- идентификации входящих защищённых транзакций
- определения балансов
- получения информации о защищённой активности
Но он не может потратить средства только потому, что имеет UFVK.
UFVK — это «возможность просмотра», которая позволяет узнавать балансы и транзакции, но не позволяет тратить.
Что остаётся внутри Keystone?
Seed-фраза/полномочия траты остаются на Keystone. Zashi не получает seed-фразу, ключ траты или приватный ключ авторизации траты. Он получает UFVK, информацию об адресе и информацию, необходимую для работы только в режиме просмотра.
Вместе эти две части завершают картину. То, что покидает устройство — например, UFVK, адреса и информация режима только просмотра, — достаточно для Zashi, чтобы отслеживать учётную запись, но ничто из покидающего устройство не достаточно для вывода из него средств.
Именно поэтому интеграция Zashi и Keystone может обеспечивать защищённое холодное хранение. Приложение кошелька может отслеживать учётную запись, не обладая полномочиями, необходимыми для траты с неё. Интеграция была специально запущена для обеспечения холодного хранения защищённых 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 и экспорт подписанного PCZT через QR BBQr.
Этот рабочий процесс стоит назвать явно, поскольку он является конкретным примером полного цикла, рассмотренного ранее в этом отчёте: кошелёк 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 есть собственные дерево обязательств записей, набор нуллификаторов, якорь и пул стоимости, поэтому на уровне консенсуса это действительно отдельный пул. Но криптографически это расширение 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 якоря Orchard и Ironwood исключены из хэша подписи и передаются только в дайджест авторизующих данных. Это реальное изменение прошивки, а не просто повышение версии. Устройство должно корректно реализовать новый sighash и вычислять его самостоятельно, а не доверять заявлению сопутствующего приложения о том, что оно одобряет.
Сам контракт изоляции не изменился: устройство всё так же возвращает только подпись авторизации траты, никогда не alpha, и никогда не создаёт связывающую подпись; хост также продолжает выполнять доказательство и всё остальное.
Однако одно правило подписанта изменилось с v6: фиктивные заполняющие траты подписываются финализатором ввода-вывода, а не устройством, поскольку устройство не может проверить их по реальным данным записей. Роль 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→прозрачный и другие) на серийном оборудовании. Стабильная прошивка и более широкий выпуск всё ещё находятся в процессе.
Zondax и Zkool сейчас находятся в переходном состоянии. Приложение Zondax — то, которое выводится из эксплуатации на Ledger. Zkool, который полагался на это приложение для связи с устройствами Ledger, не указал, что произойдёт с этой ролью после исчезновения старого приложения. Неясно, останется ли он релевантным для пользователей Ledger в будущем или его будущее главным образом связано с другими устройствами.
Сама миграция — крупнейший эффект. Поскольку объём, пересекающий пулы, публичен, кошельки распределяют переводы по стандартным номиналам с течением времени, а не перемещают баланс одним видимым блоком, что означает множество транзакций для подписи при миграции и именно поэтому пакетная подпись PCZT была так важна для аппаратных кошельков.
Работа над прошивкой Ledger также столкнулась с аппаратными ограничениями: реальная трата записи могла достигать десятков тысяч криптографических системных вызовов в одной команде, запуская сторожевой таймер устройства. Исправление перенесло арифметику полей в программное обеспечение и потребовало общего состояния рабочей области, чтобы уложиться в ограничения стека Nano X.
https://forum.zcashcommunity.com/t/ironwood-is-here-updated-wallets-libraries-aug-20/56557/40
Эволюция на одной картине
