Сегодня днём я разбирал протокол Citadel номер @Dusk — долго застрял именно на слове «license». Сначала я думал: ну это же просто напрямую вносить идентификацию в блокчейн, так что всё понятно. Но я перевернул несколько раз документацию, пока наконец не понял — дело совсем не в этом.

Суть в том, что после офлайн-проверки со стороны провайдера прав вам выдают зашифрованную лицензию, а затем регистрируют её в контракте. Пользователь в реальности отправляет не саму лицензию, а доказательство с нулевым разглашением (zero-knowledge proof): оно доказывает, что у меня на руках есть действительная license. Со стороны сервиса проверяют только публичные session, и уже от этого зависит, пропустят вас или нет. Во всём процессе три категории ролей максимально ясны: пользователь, License Provider и Service Provider.

Впечатление такое, будто это не «каждый раз заходишь в новое здание — предъявляй копию удостоверения». Скорее как в больнице: один раз вас проверяют, выдают справку «осмотр пройден/годен», спортзал смотрит только на действительность этой справки и пускает, не имея доступа к вашей истории болезни и адресу. Но меньше раскрытий не означает нулевое доверие: важно, кто именно является уполномоченным на выдачу, как можно отозвать, как долго действует лицензия, и будет ли провайдер на стороне сервиса собирать дополнительные данные вне цепочки — именно это и формирует границу приватности.

Ещё я видел, что официально сказано: полный JS SDK пока не готов, и это действительно две разные вещи — сам протокол и удобство разработки. Если приглядеться к модели транзакций: Moonlight — это публичные аккаунты, адреса балансов и суммы полностью прозрачны; Phoenix использует скрывающие механизмы с nullifier, суммы при этом не раскрываются участникам, и ещё можно выборочно раскрывать данные через viewing key. Оба варианта работают в рамках одного и того же чейна — пользователи выбирают под задачу.

Но при подключении бирж приватность «чем больше — тем лучше» тоже не всегда верно. Нужно, чтобы под это были подстроены кастоди, атрибуция и аудит. В итоге самый частый сценарий пополнений/выводов всё равно идёт по публичному пути. Если пользователю хочется что-то спрятать, ему придётся пройти больше конвертаций — а это недёшево.

Например, при выводе в Moonlight транзакция ждёт в нодах около получаса, а затем исчезает из mempool. Официально сказано довольно прямо: время истечения не указывается прямо в транзакции — у каждой ноды своя политика. Rusk по умолчанию — трое суток, иногда конфигурируют в 30 минут. Нода A не увидит, и нода B может не успеть синхронизироваться. transactions/removed означает только уход из локального пула; причиной могут быть попадание в блок, замена или конфликт. 202 Accepted лишь говорит, что нода приняла запрос — не стоит считать это окончательным состоянием. Перед ретраями нужно сверить nonce и результат выполнения: наблюдения одной ноды точно не могут считаться выводом для всей сети. #dusk

Что вы думаете о текущем варианте с двумя путями, под номером $DUSK — какой сценарий вам ближе по использованию?