#dusk $DUSK
На этой неделе я прошёлся по ключевой структуре Phoenix, потому что хотел понять, что именно даёт ключ вида человеку — и чем он отличается от простого предоставления доступа.
Ключи вида Phoenix: в whitepaper ключ вида определяется как (a, B) — частичный секрет, который позволяет третьей стороне сканировать сеть и определять, какие транзакции адресованы вам. Она может видеть, что входит. Она не может вычислить секретный ключ ноты, так что не может потратить ничего. Сканировать без расхода.
Генерация ZK-доказательств при этом делегируется отдельно. Для транзакции требуется доказательство с нулевым разглашением. Его генерация вычислительно затратна, и её можно отдать доверенной стороне с помощью подписей, не предоставляя ей доступ к вашему полному приватному ключу. Целостность транзакции не нарушается, потому что подпись привязывает её к вашему ключу, даже если доказательство было сгенерировано где-то ещё.
Эта часть надёжная. Два уровня делегирования — чётко разделены: один для доступа в духе аудита, другой для разгрузки вычислений.
Сложнее понять стоимость приватности для каждого. Делегат ключа вида знает, какие транзакции ваши. «Не может тратить» не означает «ничего не знает» — это значит, что он может составить картину всей вашей входящей истории. Для сценария комплаенса это может быть ровно тем, что нужно. Для обычного пользователя передача ключа вида сервису — значимое раскрытие, даже если средства не перемещаются.
Я на самом деле думаю, что делегирование доказательства с точки зрения приватности чище: генератор доказательства не узнаёт ничего о содержимом транзакции, если протокол корректно структурирован. Ключ вида — именно тот, который несёт реальную информацию.
То, что я пока не выяснил, — используют ли в Phoenix для задач аудита ключ вида напрямую, или существуют механизмы выборочного раскрытия, при которых раскрываются только определённые транзакции, а не вся входящая история. @Dusk
$DUSK #dusk
На этой неделе я прошёлся по ключевой структуре Phoenix, потому что хотел понять, что именно даёт ключ вида человеку — и чем он отличается от простого предоставления доступа.
Ключи вида Phoenix: в whitepaper ключ вида определяется как (a, B) — частичный секрет, который позволяет третьей стороне сканировать сеть и определять, какие транзакции адресованы вам. Она может видеть, что входит. Она не может вычислить секретный ключ ноты, так что не может потратить ничего. Сканировать без расхода.
Генерация ZK-доказательств при этом делегируется отдельно. Для транзакции требуется доказательство с нулевым разглашением. Его генерация вычислительно затратна, и её можно отдать доверенной стороне с помощью подписей, не предоставляя ей доступ к вашему полному приватному ключу. Целостность транзакции не нарушается, потому что подпись привязывает её к вашему ключу, даже если доказательство было сгенерировано где-то ещё.
Эта часть надёжная. Два уровня делегирования — чётко разделены: один для доступа в духе аудита, другой для разгрузки вычислений.
Сложнее понять стоимость приватности для каждого. Делегат ключа вида знает, какие транзакции ваши. «Не может тратить» не означает «ничего не знает» — это значит, что он может составить картину всей вашей входящей истории. Для сценария комплаенса это может быть ровно тем, что нужно. Для обычного пользователя передача ключа вида сервису — значимое раскрытие, даже если средства не перемещаются.
Я на самом деле думаю, что делегирование доказательства с точки зрения приватности чище: генератор доказательства не узнаёт ничего о содержимом транзакции, если протокол корректно структурирован. Ключ вида — именно тот, который несёт реальную информацию.
То, что я пока не выяснил, — используют ли в Phoenix для задач аудита ключ вида напрямую, или существуют механизмы выборочного раскрытия, при которых раскрываются только определённые транзакции, а не вся входящая история. @Dusk
$DUSK #dusk
