#dusk $DUSK
Когда я просматривал документацию Dusk, я долго не мог разобраться в одном месте: механизм отзыва лицензии у Citadel — после отзыва лицензии, действительны ли документы/доказательства, подписанные этой лицензией ранее?
Citadel выдает организациям license, а в блокчейне можно проверить принадлежность, срок действия и статус отзыва.
Организация использует это, чтобы доказать контрагенту свою соответствие требованиям — не нужно предоставлять тонну материалов. Но допустим, сегодня организация получает license для квалифицированного инвестора, с его помощью она сгенерировала несколько доказательств, а завтра площадка/эмитент обнаруживает проблему и отзывает license.
Статус в блокчейне обновился — но уже выпущенные ранее доказательства всё ещё действительны?
Если доказательства нельзя отозвать, то отзыв сможет остановить только будущее, но не сможет перекрыть уже “утекшие” документы.
Контрагент может по-прежнему иметь пропускающие/разрешающие документы трехдневной давности — потому что при верификации он видит только то, что само доказательство действительно, но не видит, что license уже отозвана.
Если же доказательства можно отзывать, тогда каждое доказательство нужно будет отдельно привязывать к статусному флагу; при верификации потребуется дополнительно запрашивать, отозвано ли конкретное доказательство. Но в конструкции ZK-доказательств изначально заложена идея: при проверке не нужно делать дополнительных запросов — иначе при запросе становится очевиден интерес проверяющего, и приватность ухудшается.
В документации Dusk я не нашел конкретной логики, как это обработано. Чтобы соответствие можно было отзывать, а приватность — нельзя было связать/деанонимизировать, Citadel кладет эти две вещи в один и тот же контракт — как выбрать компромисс, пока не вижу ответа.
@Dusk
Когда я просматривал документацию Dusk, я долго не мог разобраться в одном месте: механизм отзыва лицензии у Citadel — после отзыва лицензии, действительны ли документы/доказательства, подписанные этой лицензией ранее?
Citadel выдает организациям license, а в блокчейне можно проверить принадлежность, срок действия и статус отзыва.
Организация использует это, чтобы доказать контрагенту свою соответствие требованиям — не нужно предоставлять тонну материалов. Но допустим, сегодня организация получает license для квалифицированного инвестора, с его помощью она сгенерировала несколько доказательств, а завтра площадка/эмитент обнаруживает проблему и отзывает license.
Статус в блокчейне обновился — но уже выпущенные ранее доказательства всё ещё действительны?
Если доказательства нельзя отозвать, то отзыв сможет остановить только будущее, но не сможет перекрыть уже “утекшие” документы.
Контрагент может по-прежнему иметь пропускающие/разрешающие документы трехдневной давности — потому что при верификации он видит только то, что само доказательство действительно, но не видит, что license уже отозвана.
Если же доказательства можно отзывать, тогда каждое доказательство нужно будет отдельно привязывать к статусному флагу; при верификации потребуется дополнительно запрашивать, отозвано ли конкретное доказательство. Но в конструкции ZK-доказательств изначально заложена идея: при проверке не нужно делать дополнительных запросов — иначе при запросе становится очевиден интерес проверяющего, и приватность ухудшается.
В документации Dusk я не нашел конкретной логики, как это обработано. Чтобы соответствие можно было отзывать, а приватность — нельзя было связать/деанонимизировать, Citadel кладет эти две вещи в один и тот же контракт — как выбрать компромисс, пока не вижу ответа.
@Dusk