#dusk $DUSK @Dusk
Я снова и снова возвращаюсь к тому, как Dusk решает вопрос соответствия требованиям, потому что это не так, как я ожидал. Большинство людей предполагают, что pitch «по умолчанию приватен» — и на этом останавливаются. Но когда я реально посмотрел документацию Dusk, меня больше всего поразило разделение на конфиденциальное состояние и раскрываемое состояние, встроенное в ту же самую модель транзакций. Это не приватность с надстроенным сверху слоем комплаенса — механизм селективного раскрытия является родным для того, как транзакция структурируется в принципе. То есть эмитент или аудитор могут получить ключи для просмотра, не требуя, чтобы базовый протокол разветвлял логику для «регулируемого режима» vs «обычного режима». Что я заметил, изучая активность в testnet, — что почти никто пока не использует этот путь раскрытия, поскольку нет работающего регуляторного контрагента, который бы требовал это в реальной жизни. В итоге механизм вроде бы на месте и теоретически корректный, но полностью не проверен реальным трением. Это напоминает создание пожарного выхода до того, как в здании появятся арендаторы. Не знаю, это дальновидность или просто отложенная сложность. $DUSK Настоящее испытание — не описание из whitepaper. Настоящее испытание — это первый раз, когда регулятор действительно просит селективное раскрытие, и кому-то приходится использовать эту функцию под давлением, а не в документации
Я снова и снова возвращаюсь к тому, как Dusk решает вопрос соответствия требованиям, потому что это не так, как я ожидал. Большинство людей предполагают, что pitch «по умолчанию приватен» — и на этом останавливаются. Но когда я реально посмотрел документацию Dusk, меня больше всего поразило разделение на конфиденциальное состояние и раскрываемое состояние, встроенное в ту же самую модель транзакций. Это не приватность с надстроенным сверху слоем комплаенса — механизм селективного раскрытия является родным для того, как транзакция структурируется в принципе. То есть эмитент или аудитор могут получить ключи для просмотра, не требуя, чтобы базовый протокол разветвлял логику для «регулируемого режима» vs «обычного режима». Что я заметил, изучая активность в testnet, — что почти никто пока не использует этот путь раскрытия, поскольку нет работающего регуляторного контрагента, который бы требовал это в реальной жизни. В итоге механизм вроде бы на месте и теоретически корректный, но полностью не проверен реальным трением. Это напоминает создание пожарного выхода до того, как в здании появятся арендаторы. Не знаю, это дальновидность или просто отложенная сложность. $DUSK Настоящее испытание — не описание из whitepaper. Настоящее испытание — это первый раз, когда регулятор действительно просит селективное раскрытие, и кому-то приходится использовать эту функцию под давлением, а не в документации
