В пункте выдачи посылок каждый раз код для получения отличается; даже если получатель тот же самый, система не подскажет вам: «это два раза получал один и тот же человек».
Недавно помог соседу забрать посылку и обнаружил, что в системе ПВ есть интересная логика: один и тот же человек приходил дважды — коды выдачи были полностью разными. Кассир при сканировании видит только «у кого сейчас посылка», но не может понять, был ли этот человек у них в прошлый раз.
Потом, роясь в модели транзакций Dusk Phoenix, я понял: эта схема «каждый раз новый код, и посторонним невозможно связать» используется и в блокчейне — причём ещё более жестко.
Со стороны Phoenix: в каждой сделке адрес получателя, который получает сторона, принимающая перевод, — не фиксированный, а одноразовый «note public key» (обозначим как npk). Отправитель берёт долгосрочный публичный ключ получателя и добавляет случайное число — так вычисляется одноразовый npk. Получатель, используя свой view key, проверяет каждую транзакцию по отдельности: если он может вычислить npk, значит это перевод адресован ему.
Ключевое здесь — что этот npk каждый раз разный. Даже если один человек получил десять переводов, внешнему наблюдателю, который сканирует данные в цепочке, невозможно понять, эти десять переводов — от одного и того же получателя, потому что нет повторяющегося фиксированного адреса, который можно сопоставить.
Такой дизайн решает проблему «unlinkability» (неотвязываемости/невозможности связать записи): он защищает не от того, что «факт получения денег» будет виден, а от того, что «десять переводов — это один и тот же получатель» удастся собрать в связную цепочку. Более того, он поддерживает делегирование: пользователь может передать view key третьей стороне, чтобы та помогла определить, какие транзакции относятся к нему, но при этом у неё не будет права распоряжаться средствами — это довольно тонкое разделение.
Одноразовые адреса звучат безопасно, но это означает, что проверка/вычисления для каждой транзакции требуют больше вычислительных ресурсов, чем в модели с фиксированными адресами. После достижения больших масштабов будет ли этот показатель пропускной способности выдержан по скорости сканирования — зависит от фактических данных.
$DUSK
#dusk @Dusk
Недавно помог соседу забрать посылку и обнаружил, что в системе ПВ есть интересная логика: один и тот же человек приходил дважды — коды выдачи были полностью разными. Кассир при сканировании видит только «у кого сейчас посылка», но не может понять, был ли этот человек у них в прошлый раз.
Потом, роясь в модели транзакций Dusk Phoenix, я понял: эта схема «каждый раз новый код, и посторонним невозможно связать» используется и в блокчейне — причём ещё более жестко.
Со стороны Phoenix: в каждой сделке адрес получателя, который получает сторона, принимающая перевод, — не фиксированный, а одноразовый «note public key» (обозначим как npk). Отправитель берёт долгосрочный публичный ключ получателя и добавляет случайное число — так вычисляется одноразовый npk. Получатель, используя свой view key, проверяет каждую транзакцию по отдельности: если он может вычислить npk, значит это перевод адресован ему.
Ключевое здесь — что этот npk каждый раз разный. Даже если один человек получил десять переводов, внешнему наблюдателю, который сканирует данные в цепочке, невозможно понять, эти десять переводов — от одного и того же получателя, потому что нет повторяющегося фиксированного адреса, который можно сопоставить.
Такой дизайн решает проблему «unlinkability» (неотвязываемости/невозможности связать записи): он защищает не от того, что «факт получения денег» будет виден, а от того, что «десять переводов — это один и тот же получатель» удастся собрать в связную цепочку. Более того, он поддерживает делегирование: пользователь может передать view key третьей стороне, чтобы та помогла определить, какие транзакции относятся к нему, но при этом у неё не будет права распоряжаться средствами — это довольно тонкое разделение.
Одноразовые адреса звучат безопасно, но это означает, что проверка/вычисления для каждой транзакции требуют больше вычислительных ресурсов, чем в модели с фиксированными адресами. После достижения больших масштабов будет ли этот показатель пропускной способности выдержан по скорости сканирования — зависит от фактических данных.
$DUSK
#dusk @Dusk
