Что запустилось, где слабые места в модели и почему этот паттерн важен далеко за пределами платежей.
TL;DR
4 мая 2026 Polygon Labs объявил, что в Polygon Wallet добавлен пункт «Приватная отправка» (Privately Send) — отправка USDC и USDT с сокрытием отправителя, получателя и суммы транзакции. Технологический партнёр — Hinkal, протокол шифрованных пулов с верификацией через протокол доказательств с нулевым разглашением (ZK, zero-knowledge протоколы, см википедию). На момент запуска совокупная капитализация стейблкоинов на Polygon составляет $3,6 млрд (по данным Polygon Labs на 10 апреля 2026).
Главное отличие от Tornado Cash и аналогичных решений — встроенный комплайенс-уровень: KYC-аттестации через соулбаунд-токены (soul-bound tokens, SBT) и KYT-проверка (Know Your Transaction) перед исполнением каждой транзакции. По запросу пользователя генерируется аудиторский файл — селективное раскрытие через просматривающие ключи (viewing keys).
Polygon позиционирует это для бизнес-сценариев: казначейские переводы, B2B-расчёты, приватные перемещения средств. Цитата комьюнити-лида Polygon (Smokey): «Бизнесу нужна операционная приватность, а не инструменты обхода регуляции».
Архитектура: шифрованный пул + ретранслятор + zkSNARK
Hinkal-протокол построен на классической схеме шифрованного пула со следующими компонентами:
1. Смарт-контрактный пул. Пользователь депонирует токены и получает «коммитмент» (commitment) — криптографическую запись о принадлежности средств. На выходе из пула старый коммитмент гасится через «нуллифайер» (nullifier), новый — фиксирует получателя. Это стандартный UTXO-подобный паттерн, известный по Zcash и его наследникам.
2. zkSNARK-доказательства. В материалах Hinkal явно указано использование zkSNARK; конкретная разновидность системы доказательств (Groth16, PLONK, Halo2) в публичных публикациях не названа. Доказательства применяются в двух контекстах: (а) подтверждение владения KYC-аттестацией без раскрытия её содержимого; (б) валидация наличия средств и корректности пересчёта коммитментов без раскрытия сумм. Учитывая он-чейн-верификацию и стоимость газа, наиболее вероятен Groth16 либо одна из вариаций PLONK.
3. Ретранслятор (relayer). Транзакции пользователя проходят не напрямую с его кошелька, а через ретранслятор, который оплачивает газ и публикует транзакцию в блокчейн. Публичный адрес отправителя в логах не появляется. По заявлению Hinkal, ретранслятор не получает кастоди средств — ZK-доказательство удостоверяет владение без раскрытия владельца.
4. Стелс-адреса (stealth addresses). Временные адреса, генерируемые для каждой транзакции, скрывают сумму в случае, например, возврата сдачи при свопе или произвольного покрытия комиссий.
Где комплайенс: SBT + KYT, и где доверенная точка
Комплайенс-уровень реализован через два независимых механизма:
KYC-аттестации (SBT)
Чтобы попасть в шифрованный пул, пользователь должен подтвердить прохождение KYC у одного из аккредитованных провайдеров (среди примеров — Coinbase, Binance). Аттестация выпускается как соулбаунд-токен — непередаваемый NFT, привязанный к адресу. ZK-доказательство затем подтверждает «у меня есть валидный SBT» без раскрытия конкретного токена или провайдера.
KYT-проверка
Перед исполнением каждой приватной транзакции запускается проверка по реестрам подозрительных адресов (санкционные, миксеро-смежные, незаконные и т.п.). В индустрии этим занимаются TRM Labs, Chainalysis, Elliptic. Для запуска Polygon × Hinkal конкретный провайдер публично не назван.
Селективное раскрытие
По запросу пользователь может выгрузить аудиторский файл — историю своих приватных транзакций, расшифрованную локально с помощью просматривающего ключа. Файл шарится с регулятором или налоговой; третьи стороны без просматривающего ключа читать его не могут.
Самая хрупкая часть архитектуры — KYT-оракул. Проверка адресов на «грязность» требует:
-
доступа к графу транзакций (стандартный он-чейн-анализ);
-
но также к идентичности участника шифрованной транзакции — иначе как провайдер поймёт, что отправитель не из санкционного списка?
Если KYT работает «по адресу пользователя» до того, как он депонирует в пул, — это деанонимизация на входе. Если работает «по адресу-получателю» — это раскрытие на выходе. Если работает посредине — возможно только при доступе к зашифрованным метаданным транзакции, что эквивалентно компрометации приватности самого пула.
В публичных материалах Polygon × Hinkal не описано, как именно решена эта дилемма. Возможные варианты:
Пре-пул-проверка (pre-pool). KYT прогоняется на адресе при выдаче KYC-аттестации (то есть один раз), а внутри пула всё анонимно. Сильная приватность, но санкционный список меняется ежедневно — устаревший SBT может работать дольше, чем должен.
Ин-пул с раскрытием получателя (in-pool). При каждой транзакции KYT-оракул получает адрес получателя из пула. Это означает, что оракул — наблюдатель потоков, и приватность сужается до «приватность от рынка, но не от оракула».
MPC / TEE. KYT внутри многосторонних вычислений (multi-party computation, MPC) или доверенной среды исполнения (trusted execution environment, TEE), которая видит данные только под защитой железа или криптографического протокола. Снижает требование доверия, но не убирает.
Точная модель в публичных материалах не описана. Прежде чем подключать архитектуру в институциональный поток, у Polygon Labs нужно выяснять именно это.
Почему этот паттерн важен далеко за пределами платежей
В мире опционов и RFQ-исполнения существует та же дилемма: участник хочет, чтобы его поток ордеров (номинал, страйк, экспирация) не был виден рынку до исполнения, иначе его опередят или маркетмейкеры выставят худшую цену. Но при этом регулятор / комплайенс должен иметь возможность аудита — особенно для институциональных торговцев.
Текущие интент-протоколы (1inch Limit Order Protocol, CoW Swap) решают это частично: интент попадает в приватный мемпул солверов, в блокчейн публикуется только финальное исполнение (fill). Но сам ордер и идентичность ордеродателя видны солверам.
В архитектуре Polygon × Hinkal раскладка такая:
-
Публично: факт исполнения, но не параметры.
-
Селективно (просматривающий ключ): полный детал — для аудитора.
-
Никогда: идентичность участника без его согласия.
Перенести эту модель на RFQ для опционов означало бы:
-
Опционные ордера попадают в шифрованный пул с zkSNARK-доказательством корректного формата (валидный страйк, сумма, экспирация).
-
Маркетмейкеры видят только статистические агрегаты (например, совокупный номинал на одном страйк-уровне), но не индивидуальные ордера.
-
Регулятор по запросу получает просматривающий ключ конкретного участника и проверяет его активность.
Узкое место — ZK-схема, которая проверяет соответствие котируемой цены и размера ордера, не раскрывая ни того, ни другого. Это нетривиальная задача: текущие приватные платежи такой проверки не делают, для опционов её придётся проектировать с нуля.
Открытые вопросы
-
Какая ZK-система используется в продакшен-версии Hinkal? От этого зависит газ-стоимость и время генерации доказательства.
-
Какой KYT-провайдер в стеке Polygon × Hinkal и в какой точке работает проверка (пре-пул / ин-пул / пост-пул)?
-
Задержка. Сколько секунд занимает приватная транзакция против обычной, учитывая ретранслятор и генерацию доказательства?
-
Газ-экономика. Кто платит за он-чейн-верификацию доказательства — пользователь, ретранслятор, грантовая программа Polygon?
-
Объёмы. Какая доля стейблкоин-объёма на Polygon уходит в приватный пул через 30 / 90 дней — это лучший лидирующий индикатор реального соответствия продукта рынку (product-market fit).
Что забрать из этого запуска
Для платёжного слоя архитектура близка к оптимальной: приватность от рынка плюс опциональный аудит для регулятора. Главное непокрытое место — KYT-оракул, через который проходит достаточно метаданных, чтобы при определённой модели доверия нивелировать гарантии шифрованного пула. Какая именно модель используется в Polygon × Hinkal, публично не зафиксировано.
Для разработчиков RFQ и опционных протоколов главный практический вывод — связка «шифрованный пул + селективное раскрытие» собрана и работает на стейблкоинах. Перенос на исполнение деривативов упирается не в идею, а в одно конкретное место: ZK-схему сравнения цены и размера ордера без раскрытия ни того, ни другого.
Об авторе
Alcor Insights – делимся интересными статьями по DeFi и web3 — от обзорных и практических материалов до глубинных разборов – в телеграм канале.
Источники
ссылка на оригинал статьи https://habr.com/ru/articles/1031754/