Loading...
Підготовлено для ZecHub · Оновлено 27 вересня 2026 року · Усі твердження мають вбудовані посилання на джерела
ZecHub порушив це питання після додавання захищеного DASH як варіанту пожертв для вікі: чи можуть ключі перегляду в стилі Zcash або порогові підписи FROST бути застосовані до Dash?
Дослідження переосмислило питання. Ключі перегляду — не відкрите питання: Dash інтегрував Zcash Orchard захищений пул у свій ланцюг Evolution, а ієрархія ключів Orchard за задумом містить ключі перегляду. Власна дорожня карта Dash передбачає їх для розкриття даних аудиторам і дотримання Travel Rule. Ця частина вже розгорнута, а не гіпотетична.
FROST — це місце, де існує справжня прогалина. Dash уже використовує порогові підписи BLS через Long-Living Masternode Quorums, але вони призначені для консенсусу на рівні мережі — ChainLocks та InstantSend. ZIP 312 спрямований на щось інше: порогову авторизацію витрат з одного захищеного облікового запису, яким володіє невелика група окремих власників ключів. Це не взаємозамінні речі. А оскільки ZIP 312 досі має статус Draft, референтної реалізації для перенесення немає в жодному з ланцюгів, тож робота була б новою незалежно від того, яка сторона її виконає.
Дві події, пов’язані із захищеними пулами, відбулися з різницею в кілька тижнів у середині 2026 року.
Zcash відійшов від Orchard. Дослідник Taylor Hornby повідомив про вразливість схеми в Orchard, яку можна було використати для непомітного збільшення пропозиції. Zcash відповів активацією Ironwood (NU6.3) 28 липня 2026 року, представивши новий захищений пул із механізмом міграції через турнікет.
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, Shielded Hierarchical Deterministic Wallets, який має статус 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 ієрархія є строго односпрямованою — кожен рівень може виводити все нижче за нього й нічого вище:
| Ключ | Може робити | Виводить |
|---|---|---|
| Ключ витрат | Витрачати ноти | ask, nk, rivk |
Ключ авторизації витрат (ask) | Авторизувати витрати | — |
Full Viewing Key (ak, nk, rivk) | Бачити вхідні та вихідні платежі | IVK, OVK |
| Incoming Viewing Key | Бачити лише вхідні платежі | Диверсифіковані адреси |
| Вихідний Viewing Key | Відновлювати відомості про вихідні платежі | — |
| Диверсифікована адреса | Отримувати кошти | — |
Orchard спростив це порівняно з Sapling: згідно з Orchard Book, приватний ключ нуліфікатора nsk було вилучено, nk став елементом поля замість точки кривої, а ovk тепер виводиться з повного ключа перегляду, а не зберігається окремо.
Над цим розташований ZIP 316, Unified Addresses and Unified Viewing Keys — Revision 0 Active, Revision 1 Withdrawn, Revision 2 Draft — який об’єднує ключі окремих пулів у Unified Full Viewing Key («поєднує кілька Full Viewing Key… Items») і Unified Incoming Viewing Key. Відмінність, яку повинен враховувати розробник гаманця: UFVK розкриває як вхідну, так і вихідну активність, тоді як UIVK — лише вхідну.
Dash укорінює все у звичайному дереві BIP 32, із типом монети SLIP 44 5', і додає два власні розширення виведення.
DIP-0009, Feature Derivation Paths додає рівень функції, який розділяє простір ключів за специфічною для монети функцією:
m / purpose' / coin_type' / feature' / *
де purpose фіксований на 9' (0x80000009), а coin_type — на 5' (0x80000005). Заявлена мотивація DIP — ізоляція: «може бути бажаним зберігати змішані кошти у шляху, ізольованому від незмішаних коштів.»
DIP-0014, Extended Key Derivation using 256-bit Unsigned Integers йде далі, усуваючи 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 for Spend Authorization Multisignatures, зі статусом Draft, робить дещо інше. Він перетворює на порогові підписи авторизації витрат на основі Schnorr, уже визначені в Sapling та Orchard — RedJubjub і RedPallas відповідно, — щоб, за власним формулюванням ZIP, «користувачі та сторонні сервіси, які спільно зберігають гаманець, або група людей, які керують спільними коштами» могли вимагати порогового схвалення, наприклад 2 із 3, перед витратою. Його віднесено до Wallet ZIP: він створює підписи, сумісні з наявною авторизацією витрат, а не змінює консенсус. Він зберігає роль Coordinator, яку 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 обидва розвиваються; перед повторною публікацією слід повторно перевірити рисунки та статуси.