Что запустилось, где слабые места в модели и почему этот паттерн важен далеко за пределами платежей.

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 для опционов означало бы:

  1. Опционные ордера попадают в шифрованный пул с zkSNARK‑доказательством корректного формата (валидный страйк, сумма, экспирация).

  2. Маркетмейкеры видят только статистические агрегаты (например, совокупный номинал на одном страйк‑уровне), но не индивидуальные ордера.

  3. Регулятор по запросу получает просматривающий ключ конкретного участника и проверяет его активность.

Узкое место — ZK‑схема, которая проверяет соответствие котируемой цены и размера ордера, не раскрывая ни того, ни другого. Это нетривиальная задача: текущие приватные платежи такой проверки не делают, для опционов её придётся проектировать с нуля.

Открытые вопросы

  1. Какая ZK‑система используется в продакшен‑версии Hinkal? От этого зависит газ‑стоимость и время генерации доказательства.

  2. Какой KYT‑провайдер в стеке Polygon × Hinkal и в какой точке работает проверка (пре‑пул / ин‑пул / пост‑пул)?

  3. Задержка. Сколько секунд занимает приватная транзакция против обычной, учитывая ретранслятор и генерацию доказательства?

  4. Газ‑экономика. Кто платит за он‑чейн‑верификацию доказательства — пользователь, ретранслятор, грантовая программа Polygon?

  5. Объёмы. Какая доля стейблкоин‑объёма на Polygon уходит в приватный пул через 30 / 90 дней — это лучший лидирующий индикатор реального соответствия продукта рынку (product‑market fit).

Что забрать из этого запуска

Для платёжного слоя архитектура близка к оптимальной: приватность от рынка плюс опциональный аудит для регулятора. Главное непокрытое место — KYT‑оракул, через который проходит достаточно метаданных, чтобы при определённой модели доверия нивелировать гарантии шифрованного пула. Какая именно модель используется в Polygon × Hinkal, публично не зафиксировано.

Для разработчиков RFQ и опционных протоколов главный практический вывод — связка «шифрованный пул + селективное раскрытие» собрана и работает на стейблкоинах. Перенос на исполнение деривативов упирается не в идею, а в одно конкретное место: ZK‑схему сравнения цены и размера ордера без раскрытия ни того, ни другого.

Об авторе

Alcor Insights — делимся интересными статьями по DeFi и web3 — от обзорных и практических материалов до глубинных разборов — в телеграм канале.

Источники

Комментарии (0)