Loading...
Подготовлено для ZecHub · Пересмотрено 27 сентября 2026 г. · Все утверждения снабжены источниками
ZecHub поднял этот вопрос после добавления экранированного DASH в качестве варианта пожертвований для вики: могут ли ключи просмотра в стиле Zcash или пороговые подписи FROST быть применены к Dash?
Исследование изменило постановку вопроса. Ключи просмотра — не открытый вопрос: Dash внедрил Zcash экранированный пул Orchard в свою цепочку Evolution, а иерархия ключей Orchard по своей структуре включает ключи просмотра. Собственная дорожная карта Dash предусматривает их для раскрытия информации аудиторам и соблюдения Travel Rule. Эта часть уже развёрнута, а не гипотетична.
FROST — вот где находится настоящий пробел. Dash уже использует пороговые подписи BLS через долгоживущие кворумы мастернод, но они служат консенсусу на уровне сети — ChainLocks и InstantSend. ZIP 312 нацелен на другое: пороговую авторизацию траты для одного экранированного счёта, которым владеет небольшая группа отдельных держателей ключей. Они не взаимозаменяемы. А поскольку ZIP 312 остаётся в статусе Draft, на обеих цепочках нет эталонной реализации, которую можно было бы портировать, поэтому это была бы новая работа независимо от того, какая сторона её выполнит.
В середине 2026 года с разницей в несколько недель произошли два события, связанных с экранированными пулами.
Zcash ушёл от Orchard. Исследователь Тейлор Хорнби раскрыл уязвимость схемы в Orchard, которую можно было использовать для незаметного раздувания эмиссии. Zcash ответил активацией Ironwood (NU6.3) 28 июля 2026 года, представив новый экранированный пул с механизмом миграции turnstile.
Dash перешёл на Orchard. Dash объявил план 19 февраля 2026 года — «Мы ожидаем, что вскоре сможем запустить экранированные переводы, разумеется, при условии проведения аудитов безопасности и дальнейшей проверки кода». дорожная карта Dash отмечает Shielded Balances как завершённые в июле 2026 года вместе с Dash Platform v4.0, а 4 августа 2026 года Dash опубликовал «Экранированные транзакции запущены в основной сети Dash Evolution».
Примечание о последовательности. Некоторые публикации датировали активацию в основной сети Dash 17 июля 2026 года, что поставило бы её раньше Ironwood. Похоже, эта дата восходит к сообщениям прессы об анонсе, а не к активации. Согласно собственным источникам Dash, функция была завершена в июле и объявлена запущенной 4 августа — после Ironwood. Пути двух цепочек пересеклись в пределах нескольких недель; точный порядок зависит от того, какой этап считать, и этот отчёт не утверждает один из них.
Критически важно, что Dash не унаследовал ошибку. В его объявлении прямо сказано: «мы реализовали версию Orchard без известной ошибки инфляции. Предыдущая версия содержала ошибку, которую можно было использовать для незаметного раздувания объёма Zcash в обращении».
Таким образом, Dash теперь использует исправленный форк криптографии, от которой сам Zcash уже отказался на базовом уровне, тогда как пул следующего поколения Zcash (Ironwood) и схема авторизации трат следующего поколения (FROST) соответственно только что запущены и всё ещё имеют статус Draft.
Экранированный пул Dash — это Orchard, построенный на Halo 2 zk-SNARKs и не требующий доверенной настройки. Иерархия ключей Orchard всегда включала Full Viewing Keys и Incoming Viewing Keys как часть своей конструкции, а не как дополнение — поэтому возможность появилась вместе с кодом, а не в результате порта, который должна была согласовать какая-либо из цепочек.
Дорожная карта Dash прямо формулирует намерение:
«В отличие от систем обязательной приватности, столкнувшихся с делистингами на биржах и регуляторными трудностями, Shielded Balances поддерживает избирательное раскрытие информации через ключи просмотра — позволяя пользователям и компаниям делиться деталями транзакций с аудиторами или выполнять требования Travel Rule при необходимости, не снижая приватность при повседневном использовании».
Стоит зафиксировать два наблюдения:
Dash позиционирует ключи просмотра вокруг более конкретного производственного сценария, чем тот, которого достигли собственные инструменты Zcash. Инструменты Zcash для раскрытия информации о платежах в основном оставались экспериментальными и подключаемыми пользователем в разных кошельках. Dash поставляет ключи просмотра как функцию соблюдения требований с названными сценариями использования, в сети, которая, согласно собственному объявлению, также обеспечивает детерминированный расчёт примерно за одну секунду и синхронизацию кошелька примерно за двадцать секунд.
Открытый вопрос — это расхождение совместимости, а не возможности. Стоит отслеживать, остаётся ли реализация ключей просмотра Dash совместимой на уровне формата данных с форматом ключей просмотра Zcash Orchard по мере независимого развития обеих цепочек. Это вопрос мониторинга, а не исследовательский проект.
Этот раздел непосредственно отвечает на вопрос рецензента. Короткий ответ: экранированные деревья ключей почти идентичны, поскольку код общий; значимые различия состоят в том, как каждая цепочка укореняет это дерево в пространстве ключей своего кошелька и что ещё занимает это пространство.
Zcash использует ZIP 32, экранированные иерархические детерминированные кошельки, со статусом Final. Вместо размещения экранированных ключей внутри одного дерева BIP 32, ZIP 32 выделяет каждому экранированному пулу собственный мастер-ключ и собственный путь:
m_Orchard / purpose' / coin_type' / account'
m_Sapling / purpose' / coin_type' / account'
purpose фиксирован на значении 32' (0x80000020) согласно BIP 43, а coin_type следует SLIP 44, причём все тестовые сети используют индекс 1.
Внутри учётной записи Orchard иерархия строго однонаправленна: каждый уровень может выводить всё, что находится ниже него, и ничего выше:
| Ключ | Что может делать | Выводит |
|---|---|---|
| Spending key | Тратить записи | ask, nk, rivk |
Spend authorizing key (ask) | Авторизовать траты | — |
Full Viewing Key (ak, nk, rivk) | Видеть входящие и исходящие платежи | IVK, OVK |
| Incoming Viewing Key | Видеть только входящие платежи | Диверсифицированные адреса |
| Outgoing Viewing Key | Восстанавливать сведения об исходящих платежах | — |
| Diversified address | Получать средства | — |
Orchard упростил это по сравнению с Sapling: согласно Orchard Book, закрытый ключ нуллификатора nsk был удалён, nk стал элементом поля, а не точкой кривой, и ovk теперь выводится из полного ключа просмотра, а не хранится отдельно.
Над этим находится ZIP 316, унифицированные адреса и унифицированные ключи просмотра — Revision 0 Active, Revision 1 Withdrawn, Revision 2 Draft, — объединяющий ключи для каждого пула в Unified Full Viewing Key («объединяет несколько элементов Full Viewing Key…») и Unified Incoming Viewing Key. Различие, которое должен учитывать разработчик кошелька: UFVK раскрывает как входящую, так и исходящую активность, тогда как UIVK — только входящую.
Dash укореняет всё в обычном дереве BIP 32 с типом монеты SLIP 44 5' и добавляет два собственных расширения вывода ключей.
DIP-0009, пути вывода ключей по функциям, добавляет уровень функции, разделяющий пространство ключей по специфичной для монеты функции:
m / purpose' / coin_type' / feature' / *
где purpose фиксирован на 9' (0x80000009), а coin_type — на 5' (0x80000005). Заявленная мотивация DIP — изоляция: «может быть желательно хранить смешанные средства по пути, изолированному от несмешанных средств».
DIP-0014, расширенный вывод ключей с использованием 256-битных беззнаковых целых чисел, идёт дальше, снимая 31-битное ограничение индекса BIP 32, чтобы компоненты пути могли содержать полные 256-битные значения. Это позволяет использовать пути, производные от идентичности, например:
m(userA)/9'/5'/15'/0'/(userA's unique id)/(userB's unique id)
где последние два компонента являются хешами идентичности пользователя. У Zcash нет аналога: ZIP 32 не предусматривает вывод пути ключа из идентичности другой стороны.
Экранированное поддерево одинаково. Экранированные ключи Dash — это ключи Orchard, поскольку экранированный пул Dash — Orchard. Разработчик кошелька, переходящий между двумя системами, работает с одинаковой структурой от ключа траты к ключу просмотра.
Различается укоренение. Zcash изолирует каждый экранированный пул под собственным мастер-ключом с назначением 32'. Dash размещает экранированную функцию в одном унифицированном дереве с назначением 9' вместе со всеми другими функциями. Разделение Zcash происходит по криптографическому пулу; у Dash — по функции продукта.
Пространство ключей Dash содержит то, чего нет у Zcash: отдельный домен BLS. Ключи операторов мастернод, ключи голосования и ключи кворумов, используемые LLMQ, являются ключами BLS, а не ключами семейства Schnorr, и полностью находятся за пределами описанного выше дерева BIP 32. Именно здесь используется существующая пороговая подпись Dash — и именно поэтому она не сочетается с авторизацией трат Orchard, как показано в следующем разделе.
Вывод, связанный с идентичностью, существует только в Dash. 256-битные пути DIP-0014 предназначены для вывода ключей из отношений между идентичностями. Это концепция Dash Platform без эквивалента в Zcash и наиболее наглядный случай, когда две схемы вывода ключей разошлись намеренно, а не случайно.
См. рисунок 1: две схемы укоренения сходятся на общем поддереве Orchard.
Dash располагает зрелой системой пороговых подписей в LLMQ на основе BLS (Long-Living Masternode Quorums), используемой для ChainLocks, InstantSend и консенсуса валидаторов Dash Platform.
ZIP 312, FROST для мультиподписей авторизации трат, со статусом Draft, делает другое. Он превращает в пороговые подписи авторизации трат на основе Schnorr, уже определённые Sapling и Orchard — соответственно RedJubjub и RedPallas, — так что, согласно формулировке самого ZIP, «пользователи и сторонние сервисы, совместно хранящие средства кошелька, или группа людей, управляющая общими средствами» могут требовать порогового одобрения, например 2 из 3, перед тратой. Он классифицируется как ZIP Wallet: он создаёт подписи, совместимые с существующей авторизацией трат, а не изменяет консенсус. В нём сохранена роль Координатора, от устранения которой ZIP явно отказывается, и рассматриваются как генерация ключей доверенным дилером, так и распределённая генерация ключей.
Существенное различие и причина, по которой это не взаимозаменяемые решения:
| Dash BLS / LLMQ | Zcash FROST (ZIP 312) | |
|---|---|---|
| Схема подписи | BLS | Schnorr — RedJubjub / RedPallas |
| Кто подписывает | Кворум мастернод | Небольшая группа отдельных держателей ключей |
| Что авторизуется | Факт сети: блокировка блока, блокировка транзакции | Трата с одного экранированного счёта |
| Уровень | Консенсус | Кошелёк |
| Пространство ключей | Отдельный домен BLS | Ключ авторизации трат Orchard/Sapling |
| Статус | Развёрнуто | Draft, без эталонной реализации |
Наличие у Dash пороговых подписей BLS не означает, что у него есть или нужны FROST. Но это означает, что инженеры Dash обладают внутренним опытом работы с пороговыми подписями, распределённой генерацией ключей и координацией кворумов — это действительно переносимый опыт, если они решат создать такую систему.
См. рисунок 2: что именно подписывает каждая схема.
Ключи просмотра — документировать, а не исследовать. Возможность уже поставлена в обеих цепочках. Краткая заметка в вики, фиксирующая, что экранированный пул Dash включает ключи просмотра, и ссылающаяся на дорожную карту Dash, не позволит аудитории ZecHub предполагать, что это всё ещё гипотеза. Отслеживайте совместимость форматов данных по мере развития обеих цепочек.
FROST — реальная возможность, заблокированная на верхнем уровне. Это зависит от появления эталонной реализации ZIP 312 или от решения Dash разрабатывать её параллельно. ZecHub не может напрямую ускорить этот процесс.
Следующий шаг с наибольшей ценностью — разговор, а не дальнейшее кабинетное исследование. Люди, которые могли бы это построить, доступны. Shielded Labs развивает ZIP 312; инженерная команда Dash уже положительно отреагировала на формулировку «заимствовано у Zcash» вокруг интеграции Orchard. Межсообщественная дискуссия, связывающая обе стороны, выявит больше, чем очередной раунд чтения, и этот отчёт достиг предела того, что могут разрешить открытые источники.
Рисунок 1 — Укоренение вывода ключей: Zcash ZIP 32 и Dash DIP-0009/0014, сходящиеся на общем поддереве Orchard.
assets/Zcash_Dash_Key_Derivation.svg
Рисунок 2 — Что подписывает каждая пороговая схема: кворум мастернод, подтверждающий факт сети, и группа держателей ключей, авторизующая одну экранированную трату.
assets/FROST_vs_BLS_LLMQ.svg
Zcash — протокол
Dash — протокол и объявления
Современные публикации
Источники проверены 27 сентября 2026 года. Dash Platform и ZIP 312 продолжают развиваться; перед повторной публикацией следует перепроверить рисунки и статусы.