На прошлой неделе я рылся в документации модуля соблюдения требований Dusk и почти проскочил мимо того места, которое действительно имеет значение. Dusk ($DUSK , #dusk , @Dusk ) подают как «приватность, которая сочетается с соблюдением требований», будто это маркетинговый пункт, но самое интересное — это механизм, с помощью которого они до этого доходят.
Большинство цепочек, ориентированных на приватность, рассматривают соответствие требованиям как «надстройку»: вы получаете ключ для просмотра, передаёте его регулятору — и всё. В модели передачи Zedger у Dusk проверки лицензирования встроены непосредственно в саму валидность транзакции, а не как внешний слой аудита. Это означает, что передача может быть криптографически корректной в ончейне и при этом завершиться неудачей, если контрагент не соответствует условиям лицензирования, «зашитым» в сам актив. Это не «доказывайте соответствие постфактум», это «соблюдение требований — часть того, что делает переход состояния корректным в принципе».
Меня больше всего удерживает одна дилемма, которую никто честно не формулирует: это работает только в том случае, если эмитенты действительно корректно настраивают эти условия при создании актива, а значит, гарантия приватности столь же хороша, как тщательно кто-то настроил смарт-контракт — и большинство пользователей никогда на это не смотрит. Ранние инструменты вокруг этого всё ещё довольно скудные. Поэтому реальный вопрос не в том, держится ли криптография, а в том, будут ли эмитенты реально использовать доступную им гранулярность или по умолчанию выберут самые «мягкие» настройки, которые проходят по чек-листу.