Провёл на этой неделе какое-то время, разбираясь в том, как Dusk ($DUSK ) на самом деле обрабатывает «проверяемую» сторону своего заявления о приватности. #dusk @Dusk
Меня остановило вот что: откройте Phoenix-транзакцию на apps.dusk.network/explorer — и вы увидите по сути… только комиссию и использованный gas. Доказательство есть, помечено как валидное. Но отправитель, получатель, сумма — ничего. ZK-доказательство сообщает сети, что транзакция корректна, не сообщая сети, что именно в ней содержится. Вот реальный механизм. Проверяемость не живёт в публичной цепочке; она живёт у того, у кого есть ключ просмотра. Это совершенно разные поверхности.
Постойте — это на самом деле по-новому осмысливает инцидент с мостом 16 августа, в каком-то странном смысле. Подозрительную активность в том командном кошельке можно было поймать мониторингом именно потому, что операции моста проходят через публично видимый адрес, а не через защищённый поток Phoenix. Это всплыло. Операция, направленная через Phoenix с тем же поведением, была бы невидимой on-chain без ключа просмотра. Так что «приватное» и «проверяемое» здесь не противоречат друг другу; они просто относятся к разным слоям по замыслу. Доказательство удостоверяет валидность. Ключ управляет раскрытием.
Я заходил в ожидании инсайта про накладные расходы на генерацию доказательств. Но в итоге задержался на более спокойной мысли — что в регулируемом контексте «аудируемость» означает контролируемый доступ к ключу просмотра, а не прозрачность on-chain. Это подтверждается архитектурно… пока вы не начинаете спрашивать, кто управляет хранением ключей и фиксируется ли вообще где-то сам этот доступ.