Loading...
Цю статтю передруковано з Proof Street, незалежного видання про обчислення зі збереженням конфіденційності: ZK, FHE, MPC, TEE та децентралізовану ідентичність. Початково опубліковано як "Як далеко Zcash просунувся у вибірковому розкритті, і що ще лишається" 7 вересня 2026 року. Передруковано з дозволу автора в межах Zcash Community Grant №339. Автор — Стівен Веббер.
У Zcash ключ перегляду дає власнику облікового запису змогу розкрити історію екранованих транзакцій обраній ним стороні. Ключі вже працюють і контролюються користувачами. Розробники та прихильники політичних змін і далі працюють над тим, щоб вони відповідали процедурам дотримання вимог, де могли б бути корисними.
17 серпня комітет Zcash Community Grants зібрався, щоб розглянути пропозицію під назвою Shielded Compliance Bridge. Дебора Олабойє, контриб'юторка з відкритим кодом, чия робота охоплює репозиторій execution-specs Ethereum, створила доказ концепції, що приймає уніфікований повний ключ перегляду, сканує компактні блоки через тестнет-індексатор і містить «посилання для дотримання вимог» у полі пам'ятки Zcash, яке пов'язує екранований переказ із позамережевим записом Travel Rule. Вона попросила грант для завершення роботи, але комітет відмовив.
Обґрунтування полягало в тому, що інтеграції для дотримання вимог формуються конкретною біржею чи установою, яка ними користуватиметься, що немає спільних стандартів, на які можна спиратися, і що без партнера, який просить такий інструмент, його впровадження малоймовірне. На тому самому засіданні було відхилено інші пропозиції з подібних причин: одну щодо віртуальної машини «програмованого вибіркового розкриття», а також рамкову архітектуру конфіденційності й довіри, що містила мапу правових питань США.
Звісно, ці рішення не означають, що це нікому не потрібно. У контексті решти року — навпаки. Binance подав запит на рівні протоколу в 2024 році й мав ZIP протягом того ж року. Gemini здійснює екрановані виведення коштів під регуляторним наглядом із 2020 року. Екосистема створила вашингтонську політичну організацію в червні та установу для інституційної інтеграції в серпні. Фактично комітет сказав, що потребу ще не було оформлено як вимогу, за якою хтось може розробляти рішення.
Екранована адреса Zcash контролюється ключем витрачання. Від нього похідними є ключі перегляду, які можуть читати дані транзакцій, не маючи змоги переміщувати кошти. Повний ключ перегляду бачить вхідні й вихідні транзакції облікового запису, вхідний ключ перегляду бачить лише отримані кошти, а вихідний ключ перегляду дає відправникові змогу відтворити надіслані ним дані. Починаючи з ZIP 316, їх об'єднано в уніфіковані ключі перегляду — один повний і один вхідний — обмежені обліковим записом, де обліковий запис є позицією в дереві ключів гаманця згідно з ZIP 32. Уніфікований повний ключ перегляду об'єднує компоненти для кожного пулу, які використовує обліковий запис, а також містить розширений відкритий ключ прозорого облікового запису, тож його передавання розкриває прозорий ланцюг поряд з екранованою історією.
У цьому сенсі ключ перегляду є ретроактивним. Він розшифровує всю історію облікового запису від моменту його створення, і після передавання його неможливо відкликати, хіба що перемістити кошти на новий обліковий запис. Не існує ключа перегляду для окремої транзакції або обмеженого в часі ключа. Josh Swihart, виконавчий директор ZODL, компанії, утвореної цього року колишньою інженерною командою ECC протоколу, підтвердив це, також зазначивши, що розкриття окремих платежів «ніде не реалізовано».
zcashd, початковий еталонний вузол, випустив два методи RPC, z_getpaymentdisclosure та z_validatepaymentdisclosure, які дають відправникові змогу підтвердити окремий платіж третій стороні. У документації RPC їх позначено як експериментальні, вимкнені, якщо оператор не встановив прапорець експериментальних функцій, і такі, що реалізують «незавершене Payment Disclosure ZIP». Той ZIP, 303, тепер позначено як відкликаний, а його наступник, ZIP 311, досі є чернеткою без реалізації. Методи охоплювали лише пул Sprout, початковий екранований пул 2016 року, і ніколи не були поширені на Sapling чи Orchard, тобто на пули, що містять кожну сучасну екрановану транзакцію. Сам zcashd досяг кінця життєвого циклу 18 липня 2026 року — це була запланована зупинка перед оновленням Ironwood. Ані Zebra, вузол консенсусу Zcash Foundation, ані Zallet, гаманець-наступник, не містить у списку методу розкриття. Для пулів, які мають значення, розкриття на рівні окремої транзакції залишається наміром проєктування.
Цей намір досі актуальний, але віддаленіший, ніж здавалося в липні. ZIP 231, пакети пам'яток, — це чернетка, що створить для нього простір: Свіхарт описав пакети пам'яток як майбутню основу для автентифікованої адреси відповіді, яка могла б слугувати доказом платежу, а залежна чернетка, автентифіковані адреси відповіді, потребує доказів, надто великих для поточного поля пам'ятки. Пакети пам'яток — це зміна формату транзакцій, і п'ять організацій, що координують голосування власників монет NU7, у серпні погодилися, що зміни формату не входять до сфери NU7, але входять до сфери наступного оновлення. Саме голосування, яке триває з 25 серпня до 14 вересня, винесло на розгляд власників емісію, політику комісій, інтервали між блоками та припинення Sprout; розкриття не було в бюлетені. Старіший шлях, ZIP 311, не потребує зміни консенсусу, але досі є чернеткою без реалізації та без охоплення Orchard.
Отже, сьогодні доступні ключі перегляду в межах облікового запису — повні або лише вхідні, ретроактивні, безвідкличні та передані з ініціативи власника облікового запису; водночас розкриття на рівні транзакцій залишається в дорожній карті.
Механізми розкриття в Zcash чи деінде можна визначити за такими параметрами: що розкривається (обсяг); кому (одержувач); коли надання доступу набуває чинності та наскільки далеко в минуле воно сягає (часові межі); чи можна його відкликати (відкличність); а також хто ініціює його — суб'єкт даних чи орган влади (ініціювання).
Режими дотримання вимог є наборами вимог до цих параметрів, а архітектури займають певні позиції щодо них. Ключі перегляду Zcash за задумом мають широкий обсяг, обраного власником одержувача, є цілком ретроактивними, безвідкличними та ініційованими користувачем. Вимоги, у тому вигляді, як їх застосовують біржі та наглядові органи, зазвичай обмежені відносинами або періодом, надаються названій установі чи її постачальнику аналітики, діють безперервно від моменту підключення, відкликаються після завершення відносин і ініціюються установою як умова надання послуги.
Обидва ці явища називають вибірковим розкриттям. У світі облікових даних вибіркове розкриття означає подання підмножини атрибутів із підписаних облікових даних без розкриття решти — саме для цього призначені SD-JWT, ISO mdoc та підписи BBS+. Одиницею розкриття є атрибут, моментом — час подання, а власник ухвалює рішення для кожної взаємодії.
У світі екранованих платежів цей вислів означає розкриття даних транзакцій обраній стороні, де одиницею є історія облікового запису, а моментом — будь-який час, коли передається ключ.
Свіхарт заявив, що єдиний запит щодо дотримання вимог на рівні протоколу, який інженерна команда будь-коли отримувала, надійшов від Binance, яка в січні 2024 року вимагала гарантії прозорого походження для депозитів. Відповіддю команди був ZIP 320, адреси лише з прозорим джерелом, а в тексті ZIP справді зазначено походження «як того вимагала Binance». Адреса TEX — це тимчасовий прозорий проміжний механізм, який гарантує біржі, що вона отримує кошти з прозорого джерела. Він надає біржі шлях повернення, не розкриваючи їй історію відправника. Єдина адаптація протоколу для біржі розкриває саме те, чого просила біржа, і нічого більше.
Після оновлення Sapling, на думку Свіхарта, не існує технічної причини, через яку біржа не могла б підтримувати екрановані транзакції, оскільки створення доказів відбувається швидко, клієнтів біржі вже ідентифікують під час підключення, а для випадків, які цього потребують, існує посилена належна перевірка. З такого погляду розрив між механізмами та процедурою дотримання вимог насправді є не відсутньою примітивною функцією, а відсутньою розмовою.
Дівідж Панд'я працює на іншому кінці цієї розмови. Він є виконавчим директором Pretty Good Policy для Zcash, вашингтонської політичної організації, створеної в червні як продовження попередньої ініціативи під керівництвом ECC, і мета його організації — домогтися визнання розкриття через ключі перегляду прийнятним механізмом дотримання вимог у документі, на який може послатися фахівець із комплаєнсу. Наскільки йому відомо, жоден регулятор ще не розглядав ключі перегляду як інструмент. Сфера діяльності PGPZ, природно, полягає у визнанні, а не в рекомендаціях для розробників. Інструмент не можна визначити відповідно до вимоги, доки хтось, наділений повноваженнями, не ухвалить рішення щодо цього інструмента, тож визнання є попереднім кроком. Документи організації підписані Полом Брігнером як засновником PGPZ і як головним директором із політики та регулювання ZODL, тож політичні та інженерні зусилля мають спільного посадовця, а також спільну тезу.
У заяві від 21 липня, поданій до підкомітету Палати представників з нагляду за FinCEN, Zcash описано як такий, що має «можливості вибіркового розкриття, які дають користувачам змогу добровільно ділитися деталями транзакцій за допомогою ключів перегляду з аудиторами, податковими органами або фахівцями з комплаєнсу», а також згадано докази з нульовим розголошенням, «поєднані з вибірковими ключами перегляду», для доведення визначених фактів. У листі з коментарем у реєстрі FinCEN, FINCEN-2026-0101-0050, стверджується, за словами Панд'ї, що ключі перегляду та вибіркове розкриття мають бути прийнятними механізмами дотримання вимог. Відкрите питання, яке вони ставлять регулятору, стосується деталізації: чи достатньо розкриття в межах облікового запису за всю історію для «цільової інформації про транзакції», чи відповідь очікує на ZIP 231.
Доки це не буде вирішено, команди з дотримання вимог стикаються з обмеженням, яке псевдонімний дописувач форуму strahncryptography описав під час обговорення пропозиції Олабойє: вони дотримуються правила буквально й не приймуть невизнаний шлях без підтвердження регулятора або юридичної фірми, хоч би якою надійною була криптографія. Будь-який дизайн розкриття, що прив'язує посилання до транзакції, доводить лише останній перехід, а ним може бути сам вкладник. Ключ перегляду має те саме обмеження. Він розкриває транзакції власника облікового запису, але не походження коштів контрагентів — саме це перевіряє санкційний скринінг.
Ключі перегляду відповідають вимозі всюди, де потрібен доказ від суб'єкта даних того, що сталося: наприклад, походження депозиту, яке вкладник вирішив пояснити, добровільний аудит, податкова декларація або доказ здійснення конкретного платежу. Це одноразові розкриття, ініційовані користувачем і ретроактивні. Вони не відповідають вимозі там, де необхідні безперервний моніторинг від моменту підключення, санкційний скринінг контрагентів, яких власник облікового запису не контролює, обмеження періодом чи відносинами або відкликання під час припинення обслуговування.
Gemini приймає виведення на екрановані адреси з вересня 2020 року, коли представник компанії пояснив це тривалими розмовами з регуляторами; у листопаді 2025 року це було поширено на пул Orchard, а через два дні після активації в липні 2026 року — на після-Ironwood пул. Вона приймає депозити, надіслані з екранованих адрес до прозорого зберігання. У списку адрес для виведення коштів Kraken підтримуються лише прозорі адреси ZEC, Coinbase також підтримує лише прозорі адреси, а Binance вимагає TEX. Жодна велика регульована біржа поки не пропонує екранованого зберігання, екранованої адреси для депозиту чи процедури, до якої можна було б додати ключ перегляду клієнта.
Приймання даних розробляється на один рівень нижче. Серед пропозицій у раунді ретроактивних грантів, спрямованих власниками монет, що розглядаються цього вересня, є ZecBooks — інструмент бухгалтерського обліку для Mac, який імпортує ключ лише для перегляду, класифікує нотатки та експортує обмежений пакет рядків для бухгалтера, не надаючи тривалого доступу до гаманця; ZecLedger — інструмент лише для читання для розрахунку собівартості та звірки, побудований навколо уніфікованого повного ключа перегляду й протестований на mainnet-гаманці; а також seer-sync — механізм синхронізації ланцюга, який приймає ключ перегляду, щоб платіжний процесор або бухгалтерська система могли спостерігати екрановану активність, не зберігаючи ключі витрачання. Жоден із них не є процедурою для біржі, і жоден не привернув уваги регулятора. Кожен є бухгалтерською половиною тієї самої проблеми, створеною однією чи двома людьми без партнера, який про це просить, а обмежений експорт ZecBooks є вибірковим розкриттям на інтерфейсі, де воно найчастіше потрібне насамперед: між користувачем екранованих транзакцій і людиною, яка веде його облік.
Розробники Zcash працюють над проблемою, спільною для кожної архітектури конфіденційності.
У дизайні конфіденційного EVM від Zama список контролю доступу визначає, які адреси можуть запитувати розшифрування шифротексту, а порогова мережа операторів керування ключами виконує розшифрування на запит. Це переміщує вісь одержувача від ключа, який передає користувач, до дозволу, зафіксованого контрактом, і робить ініціювання програмованим, оскільки контракт може надати аудиторові права на розшифрування як умову використання. Це не робить розкриття відкличним у тому сенсі, який має на увазі фахівець із комплаєнсу, бо вже розшифрований шифротекст залишається розшифрованим, і замінює зберігання ключа користувачем на чесність операторів як основу довіри. Ключі аудитора на рівні активу, як у розширенні конфіденційних переказів Solana та дизайні зашифрованого ERC Avalanche, фіксують одержувача на рівні токена: емітент або призначений аудитор може читати баланси та перекази цього активу.
Inco опублікував рамкову модель для попередньо визначеного перегляду, де доступ фіксується в ключовому матеріалі під час транзакції, на противагу програмованому доступу до перегляду, де права перегляду є станом контракту, який можна згодом надати, обмежити та відкликати.
Що відрізняє ключ перегляду від процедури дотримання вимог?
Ключ перегляду розкриває власну історію власника облікового запису. Санкційний скринінг і безперервний моніторинг ставлять питання про контрагентів, тобто звідки надійшли кошти з іншого боку кожної транзакції, а саме цю інформацію екранований пул і має приховувати. Ніхто ще не продемонстрував дизайн, що відповідає на питання про контрагента без прозорого реєстру або довіреної третьої сторони.
Якщо пакети пам'яток буде впроваджено в оновленні після NU7, а за ними з'явиться чернетка адреси відповіді, «цільова інформація про транзакції» в документах PGPZ набуде буквального значення. До цього щонайменше два оновлення, а регуляторна відповідь надійде за графіком регулятора.
Попит легко побачити за кількістю людей, які розробляють рішення для цього. Бракує фіксованої вимоги до розкриття зі збереженням конфіденційності. Zcash — це екосистема, у якій це рішення відкрито обговорюють інженери, прихильники змін, розробники, біржа та грантовий комітет, які, схоже, погоджуються щодо мети й сперечаються про порядок кроків. Над цим також працюють самостійні розробники, які почали з бухгалтерського рівня, не чекаючи, доки вимогу буде сформульовано.
Розкриття: цей матеріал був підтриманий Zcash Community Grant. ZCG не переглядав і не схвалював цей матеріал до публікації.
Пов’язані сторінки: Ключі перегляду · Порівняння конфіденційності